{"id":5878,"date":"2026-10-08T02:11:27","date_gmt":"2026-10-08T05:11:27","guid":{"rendered":"https:\/\/tucumandevelopers.com\/index.php\/2026\/10\/08\/faster-developers-dont-make-a-faster-team\/"},"modified":"2026-10-08T02:11:27","modified_gmt":"2026-10-08T05:11:27","slug":"faster-developers-dont-make-a-faster-team","status":"publish","type":"post","link":"https:\/\/tucumandevelopers.com\/index.php\/2026\/10\/08\/faster-developers-dont-make-a-faster-team\/","title":{"rendered":"Faster Developers Don\u2019t Make a Faster Team"},"content":{"rendered":"
\n
\n
\n
\n

Agentic AI<\/a> AI<\/a> JetBrains<\/a> JetBrains AI<\/a><\/p>\n

What engineering teams tell us about working with AI agents. Part 1 in the series<\/em>.<\/p>\n

\n

Over the past few months, I\u2019ve spent a lot of time on discovery calls with engineering organizations, from a 16-developer software agency to telcos, game studios, and consultancies with thousands of developers. Almost none of them are asking whether to use AI agents. At one financial data provider, a survey showed that roughly 80% of engineers use them daily.<\/p>\n

When I sort what I hear into three levels \u2013 the individual developer, the team, and the organization \u2013 a pattern appears. Individual developers can now move much faster with agents, but the gains are uneven. The organization level is about visibility, cost, and control. The team level is where the gains stall. A few people get much faster, but even teams that are redesigning their workflows struggle to turn faster implementation into faster delivery.<\/p>\n<\/div>\n

Here are the three scenarios I hear most often.<\/p>\n

1. Everyone has an agent. Nobody shares the setup.<\/strong><\/h2>\n

When I ask whether developers share prompts, rules, or instruction files, the honest answer is usually a version of what an architect at an IT services company told me: \u201cWe are not there yet. We are just sharing knowledge around coffee in the morning.\u201d<\/p>\n

Even where teams have started to formalize their practices, it spreads by osmosis. A head of engineering at a legal-tech company said, \u201cThere are no standards. We\u2019ll set it in the [AI team\u2019s] repo, and then it slowly creeps into the older .NET ones as well, just through sharing what\u2019s working.\u201d<\/p>\n

Where sharing is systematic, it is fragile. A platform lead at a mobility company with over a hundred repositories who keeps base rules in one repo and copies them into every service explains, \u201cIf we update the base, we need to update all repos, which people may have customized.\u201d <\/p>\n

A solution architect at a consultancy who watches more than fifty client teams adds that shared configuration is often theatre: <\/p>\n

\n

People eagerly create agents, skills, CLAUDE.md files, everything. But they may find that they actually make quality worse. Some of them are not working at all.\u201d<\/p>\n<\/blockquote>\n

The result is a widening gap inside the team. An engineering manager at a mapping company illustrates, \u201c20% of the engineers are generating 80% of the code or consuming 80% of the tokens. We do not really know if the other 80% are smarter, just not using it well, or need training.\u201d <\/p>\n

A staff engineer at the financial data provider says, \u201cThere\u2019s a big gap in proficiency. If you make a bad prompt, the codebase is read three times.\u201d <\/p>\n

The CEO of a cloud consultancy asked the question behind all of this: \u201cIn my team, there is one superstar developer who is like 10x better than anyone else. How can I capture his behavior patterns and spread them across the team?\u201d<\/p>\n

Knowledge about how to work with agents lives in personal configs, Slack threads, and wikis. Agents start every task cold; everyone re-explains the same conventions, and output quality depends on who is prompting rather than on what the team decided. As a senior engineer at a large consultancy put it, \u201cNo one is mature. This is too new to be mature.\u201d<\/p>\n

2. Implementation got cheap. Review didn\u2019t.<\/strong><\/h2>\n

\u201cAs we do more of this, we see the bottlenecks move to the code review and planning stage. Implementation\u2019s quite quick these days,\u201d says the legal-tech head of engineering, and they already run an AI review gate before any human looks at a pull request.<\/p>\n

The mapping company measured it: \u201cIf we looked at the pure numbers, PR time actually increased. It\u2019s probably the human in the loop, or low confidence in the quality, which leads people to check everything. But we do not know the answer yet.\u201d<\/p>\n

A platform group at a large networking vendor, where everyone uses agents daily, identified the same ceiling: \u201cWe\u2019re basically trying to apply non-agent-based processes to very, very rapidly changing work.<\/p>\n

\n

Just because you can build 100 things doesn\u2019t mean you should. People can\u2019t consume that much.\u201d<\/p>\n<\/blockquote>\n

A principal engineer at a gaming company summed up the distance between a demo and a team\u2019s real workflow: \u201cExperimenting is one thing, but putting stuff into production \u2013 with all the flows, the good and the bad, reviews, and all the things people have to deal with in 2026 \u2013 is another thing.\u201d<\/p>\n

The bottleneck also moves upstream. With one product manager per five or six developers, the developers are getting through the work so fast that getting backlog items into a state where they\u2019re ready to be picked up by a person or an agent is challenging.<\/p>\n

Review processes were designed for human-paced change. If verifying the output costs more than the savings it generated, the team has actually regressed.<\/p>\n

3. Automating the boring work creates a new operational burden.<\/strong><\/h2>\n

Teams know exactly what they would hand to agents. A head of engineering at a gaming company shares, \u201cEvery time somebody creates an MR [merge request], we want to run specific things. Every night, we run a documentation updater that goes through all the repos and makes sure that everything is aligned.\u201d <\/p>\n

Next on his list? \u201cUpgrading libraries, upgrading frameworks, tackling identified security vulnerabilities in a more autonomous way.\u201d Yet for many teams, simply getting these background automations off the ground remains a hurdle due to a lack of time and dedicated infrastructure.<\/p>\n

Some have proven it by hand. An agency took a vague customer ticket and had the pull request ready within 10 minutes. Now they want the loop to run without them, envisioning that \u201cWhen we\u2019re done with the workday, we come back the next day and it has completed all the tasks we asked of it.\u201d<\/p>\n

For teams that do manage to build operational pipelines, what stops them from scaling is not ideas, but where the automation runs, who owns it, and how it reaches every project. A senior engineer at a consultancy built exactly this \u2013 an agent in a Docker container on a VM, reacting to webhooks \u2013 and hit a wall:<\/p>\n

\n

The main issue is that we have to maintain it. If we deploy on one customer, we also have to figure out how to distribute updates to another project.\u201d<\/p>\n<\/blockquote>\n

Meanwhile, the platform lead turns into a human API. From the mobility company: \u201cToday, the backend team asked, \u2018Can you give us a key in CI inside GitHub and a secret to auto-generate tests?’\u201d And when every team automates on its own, coordination breaks. The gaming company had: \u201ca very heated discussion about how to contain the situation where everybody wants to create an agent, and we have no way to govern it.\u201d<\/p>\n

What these have in common<\/strong><\/h2>\n

Giving every developer a capable agent does not solve these problems on its own. Some teams lack shared infrastructure, while others are already building it and discovering the ongoing work required to maintain it. That gap is what we are building Air Teams<\/a> around. <\/p>\n

In the coming posts, I will address three scenarios one at a time \u2013 shared context and skills, reviews built for agent output, and automations a team owns together. Based on real customer stories, I will show how sharing intent, decisions, impact, and verification results helps the next person understand changes independently and reduces review effort.<\/p>\n

Stay tuned. <\/p>\n<\/p><\/div>\n

<\/a> <\/section>\n

\n

Discover more<\/h2>\n<\/p><\/div>\n<\/p><\/div>\n<\/div>\n<\/div>\n<\/div>\n

Fuente: Art\u00edculo original<\/a><\/p>\n","protected":false},"excerpt":{"rendered":"

Agentic AI AI JetBrains JetBrains AI What engineering teams tell us about working with AI agents. Part 1 in the series. Over the past few months, I\u2019ve spent a lot of time on discovery calls with engineering organizations, from a 16-developer software agency to telcos, game studios, and consultancies with thousands of developers. Almost none […]<\/p>\n","protected":false},"author":1,"featured_media":5877,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":"","jetpack_publicize_message":"","jetpack_publicize_feature_enabled":true,"jetpack_social_post_already_shared":true,"jetpack_social_options":{"image_generator_settings":{"template":"highway","default_image_id":0,"font":"","enabled":false},"version":2},"webixso_pending_account_ids":""},"categories":[46],"tags":[],"class_list":["post-5878","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-jetbrain"],"jetpack_publicize_connections":[],"_links":{"self":[{"href":"https:\/\/tucumandevelopers.com\/index.php\/wp-json\/wp\/v2\/posts\/5878","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/tucumandevelopers.com\/index.php\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/tucumandevelopers.com\/index.php\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/tucumandevelopers.com\/index.php\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/tucumandevelopers.com\/index.php\/wp-json\/wp\/v2\/comments?post=5878"}],"version-history":[{"count":0,"href":"https:\/\/tucumandevelopers.com\/index.php\/wp-json\/wp\/v2\/posts\/5878\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/tucumandevelopers.com\/index.php\/wp-json\/wp\/v2\/media\/5877"}],"wp:attachment":[{"href":"https:\/\/tucumandevelopers.com\/index.php\/wp-json\/wp\/v2\/media?parent=5878"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/tucumandevelopers.com\/index.php\/wp-json\/wp\/v2\/categories?post=5878"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/tucumandevelopers.com\/index.php\/wp-json\/wp\/v2\/tags?post=5878"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}