Faster Developers Don’t Make a Faster Team

Gleb Malkov

What engineering teams tell us about working with AI agents. Part 1 in the series.

Over the past few months, I’ve 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.

When I sort what I hear into three levels – the individual developer, the team, and the organization – 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.

Here are the three scenarios I hear most often.

1. Everyone has an agent. Nobody shares the setup.

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: “We are not there yet. We are just sharing knowledge around coffee in the morning.”

Even where teams have started to formalize their practices, it spreads by osmosis. A head of engineering at a legal-tech company said, “There are no standards. We’ll set it in the [AI team’s] repo, and then it slowly creeps into the older .NET ones as well, just through sharing what’s working.”

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, “If we update the base, we need to update all repos, which people may have customized.” 

A solution architect at a consultancy who watches more than fifty client teams adds that shared configuration is often theatre:

“

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.”

The result is a widening gap inside the team. An engineering manager at a mapping company illustrates, “20% 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.” 

A staff engineer at the financial data provider says, “There’s a big gap in proficiency. If you make a bad prompt, the codebase is read three times.” 

The CEO of a cloud consultancy asked the question behind all of this: “In 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?”

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, “No one is mature. This is too new to be mature.”

2. Implementation got cheap. Review didn’t.

“As we do more of this, we see the bottlenecks move to the code review and planning stage. Implementation’s quite quick these days,” says the legal-tech head of engineering, and they already run an AI review gate before any human looks at a pull request.

The mapping company measured it: “If we looked at the pure numbers, PR time actually increased. It’s 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.”

A platform group at a large networking vendor, where everyone uses agents daily, identified the same ceiling: “We’re basically trying to apply non-agent-based processes to very, very rapidly changing work.

“

Just because you can build 100 things doesn’t mean you should. People can’t consume that much.”

A principal engineer at a gaming company summed up the distance between a demo and a team’s real workflow: “Experimenting is one thing, but putting stuff into production – with all the flows, the good and the bad, reviews, and all the things people have to deal with in 2026 – is another thing.”

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’re ready to be picked up by a person or an agent is challenging.

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

3. Automating the boring work creates a new operational burden.

Teams know exactly what they would hand to agents. A head of engineering at a gaming company shares, “Every 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.” 

Next on his list? “Upgrading libraries, upgrading frameworks, tackling identified security vulnerabilities in a more autonomous way.” Yet for many teams, simply getting these background automations off the ground remains a hurdle due to a lack of time and dedicated infrastructure.

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 “When we’re done with the workday, we come back the next day and it has completed all the tasks we asked of it.”

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 – an agent in a Docker container on a VM, reacting to webhooks – and hit a wall:

“

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.”

Meanwhile, the platform lead turns into a human API. From the mobility company: “Today, the backend team asked, ‘Can you give us a key in CI inside GitHub and a secret to auto-generate tests?'” And when every team automates on its own, coordination breaks. The gaming company had: “a very heated discussion about how to contain the situation where everybody wants to create an agent, and we have no way to govern it.”

What these have in common

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 around. 

In the coming posts, I will address three scenarios one at a time – 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.

Stay tuned.