You won't find a dev team's productivity on a dashboard. You see it in what reaches production without bouncing back for fixes three times. That's the heart of the problem when you assess a development partner or your own team: the metrics people watch say nothing about the team's real ability to deliver. A Stanford study covering more than 100,000 developers at 600 companies has just taken that illusion apart.
- 📊 The usual metrics are misleading, lines of code and AI quotas tell you nothing useful about a team.
- ⚡ AI helps, but not always, with average gains of 16 to 30% and up to 150% for the best teams.
- ⚠️ AI isn't the real risk, multitasking and reliance on a single dev quietly wreck productivity.
- 🎯 A checklist for judging a partner, 5 concrete questions to ask before signing a development contract.
The topic is hot again because AI has changed how tech teams work, but not the question you need to ask. Before you choose a partner or judge your in-house team, you need to understand what "productive" actually means.
What dev team productivity really means
Developer productivity is rarely well defined, and that's where bad decisions start. INSEE, France's national statistics office, defines productivity as the ratio between output and the resources used to produce it. It's a simple formula that gets complicated the moment you apply it to code.
ClickUp tells a textbook story in an article on the subject. Michael writes 100 lines of code a day, Dwight writes 70. On paper, Michael wins. Except his code is riddled with bugs and keeps coming back for rework, while Dwight's ships to production without a hitch. Counting lines rewards the wrong behaviour.
That's exactly the point OCTO Talks makes in its Lean take on productivity: you track the team's productivity, never the individual's, because monitoring one developer's lines of code encourages output for its own sake, not delivering value. Clients regularly come to GoLive with dashboards inherited from an IT services firm that tracked billed hours, not shipped features. The contract protected the vendor, not the outcome.
Why doesn't measuring individual developers work?
On a real product, no developer works alone. They depend on specs, code reviews, a colleague's tests and architecture decisions made six months earlier. Reducing their contribution to lines of code or closed tickets ignores all that collective work, and it pushes some people to close easy tickets instead of the ones that matter. The right unit of measurement is the team and what it ships to production, not the individual and what they type.
AI changed the numbers, not the question
Asking "does AI make my team more productive?" without any nuance means you're already asking the wrong question. Yegor Denisov-Blanch, a Stanford researcher, spent three years studying that question using real Git data from more than 600 companies, from large enterprises to startups. His conclusion, presented at an AI Engineer conference, is that AI boosts productivity in some cases and reduces it in others. It isn't a silver bullet.
The figures IBM Technology cites in a study published in 2026 back up this two-sided picture. AI wrote 41% of the code deployed in 2026, and according to McKinsey, the software companies getting the most out of AI see productivity gains of 16 to 30%, and up to 45% on code quality. Meanwhile, developers reject 70% of the suggestions AI gives them, and a study by the MER research institute found that some devs spend 19% more time when they use AI tools, because they then have to fix the mistakes it makes.
I see it on the projects we take over at GoLive. A senior dev who knows how to review, fix and reject an AI suggestion saves real time. A junior left alone with Copilot or Claude piles up invisible technical debt for weeks, until a bug in production brings it to light. That's exactly the argument of our article on the 5 reasons AI still can't replace a developer: the tool amplifies existing skill, it doesn't create it.
Why does AI help some teams and slow others down?
It has nothing to do with which AI vendor you pick. It comes down to what the team protects and what it hands off. A team that lets AI handle syntax and boilerplate while keeping control of architecture, security and design decisions gets real value from it. A team that hands off everything, including the big structural choices, piles up fixes without noticing.
Why the best teams gain twice as much as the average
The gap between teams that succeed with AI and teams that fail isn't marginal. It's huge. IBM Technology puts the productivity gain of average teams using AI at a few tens of percent, compared with 100 to 150% for the best. Same tools, radically different practices.
The difference isn't about choosing an AI vendor. It's about restructuring the team around the tool. Atlassian reaches the same conclusion. The company has about 1,500 engineers worldwide and uses the DX platform to track their productivity. Before DX, the team would gather in a room and draw up priority lists on gut feel, with no idea which ones really mattered. With unified data, it can finally use a shared productivity vocabulary across platform teams, leadership and product teams.
I think this measurement discipline is precisely what most poorly managed offshore teams lack. It's also why a well-organised senior Vietnamese team can compete with a far more expensive European one: it's not about the hourly rate, it's about how the team is structured around the tool. On the projects we've taken over from IT services firms at GoLive over the past two years, the same pattern shows up almost every time: money spent on AI, and no method for checking what it actually delivers.
What kills productivity before AI even enters the picture
Before blaming or crediting AI, look at an older, quieter problem: constant context switching. The Serious CTO puts it bluntly in a recent analysis: true multitasking is practically non-existent for 97.5% of people. A dev who says they're working on three projects in parallel is really unloading one complex mental model and loading another, over and over, with every Slack notification or urgent Jira ticket.
This hidden cost explains some of what developers themselves describe on Reddit. On r/developpeurs, one developer says management has imposed a quota for AI prompt usage, even though 80% of their work involves cross-checking information across websites, APIs and databases, context that AI can't guess. Their lead dev, meanwhile, has switched to full-time vibe coding and admits they no longer know how to code without prompts. The technical debt keeps growing, and nobody fixes it.
On r/ColombiaDevs, another post describes a team with no working rules at all, where AI is literally driving the technical decisions rather than the other way round: nobody takes a critical look at what the tool suggests. And on r/developersIndia, a tech lead explains that their entire team ran out of work because AI was producing faster than QA could keep up, breaking the whole delivery pipeline.
None of these three stories has anything to do with the quality of the AI being used. They describe organisations that didn't see the change coming and never redefined who is responsible for what. It's a team governance problem, not a tooling problem.
What does the crisis of purpose some engineering leaders face tell us?
On r/ClaudeAI, a software development director describes a morale crisis in their team of 40 developers. Devs who took pride in clean, maintainable code now wonder what they still bring to the table when AI writes code so fast. I think the answer is clear: architecture, edge cases, security and understanding the business need can't be automated. A product built quickly without technical oversight often costs more to repair than it would have cost to build properly from the start.
How to assess a development partner's real productivity before signing
Everything above leads to one practical question when you're choosing a partner: how do you check that they're genuinely productive, rather than taking their word for it? A simple checklist lets you decide in a meeting, before any contractual commitment.
| Criterion | Good sign | Red flag | Question to ask |
|---|---|---|---|
| Productivity measurement | Team velocity, features shipped | Lines of code, billed hours | How do you measure the team's productivity? |
| Use of AI | Built into the workflow, code reviewed | Imposed quota, vibe coding without review | Who reviews AI-generated code before it's merged? |
| Work organisation | Little context switching | Devs juggling 3 projects in parallel | How many projects does each developer handle at once? |
| Technical ownership | A senior owns the architecture | Nobody makes the structural calls | Who is accountable if something breaks in production? |
| Team continuity | Documentation, fast onboarding | Reliance on one or two key devs | What happens if your lead dev leaves the project? |
SOURCE: cited transcripts · UPDATED 09/2026
Full disclosure: I run an offshore software development company in Vietnam, so I have a direct interest in defending this model. That's also why I know which questions sting in a meeting, the ones a poorly organised partner avoids answering precisely. A structured offshore model, with senior devs who use AI without handing it the decisions, answers all five questions without hesitation. I've explained how this model works in a dedicated article if you want to dig into why working with an offshore agency makes a real difference, and how AI-augmented teams ship three times faster without sacrificing quality.
The ai-first.fr blog covers the same topic from the angle of non-tech companies adopting AI in their day-to-day work, a useful complement if you're looking to equip your own teams rather than outsource.
A dev team's productivity doesn't boil down to lines of code, an AI quota or a "we use Claude Code" badge. You verify it through the answers to the five questions above, and through what actually reaches production without coming back for fixes. Those answers, not the marketing promise on a slide, should decide which partner you choose.
Frequently asked questions
How do you measure a development team's productivity?
Measure team velocity and the number of features shipped to production without rollbacks, never lines of code or hours billed per developer. INSEE, France's national statistics office, defines productivity as the ratio between output and the resources used, a logic that applies to the whole team rather than to one person in isolation. Tools like DX, which Atlassian uses across its 1,500 engineers, standardise this measurement across teams.
Does AI really increase developer productivity?
Yes, but unevenly. According to McKinsey, as cited by IBM Technology, the software companies getting the most out of AI gain 16 to 30% in productivity, compared with 100 to 150% for the best teams that have restructured around the tool. A Stanford study of more than 100,000 developers also shows cases where AI wastes time, particularly when developers spend longer fixing its mistakes than they would have spent writing the code themselves.
Why does multitasking reduce a dev team's productivity?
The human brain almost never truly multitasks: for 97.5% of people, it's just constant context switching, and every jump between projects, Slack and Jira tickets carries a real cognitive cost. A developer juggling three projects has to rebuild a complex mental model each time, which slows delivery far more than the choice of AI tool.
Should you impose an AI usage quota on your developers?
No. A quota with no connection to the actual work pushes developers to pad their numbers with pointless prompts instead of shipping, as one developer describes on r/developpeurs. It's better to build AI into the existing workflow, let senior developers keep control of architecture and structural decisions, and measure what gets delivered rather than how many prompts get used.
How can you tell whether an IT services provider is genuinely productive?
Ask them the five questions from the checklist in this article: how they measure productivity, how they review AI-generated code, how many projects each developer handles in parallel, who owns technical accountability, and what happens if a key developer leaves the project. A serious provider gives a precise answer to each one, without falling back on vague marketing promises.
Vidéos YouTube
- Does AI Actually Boost Developer Productivity? (100k Devs Study) - Yegor Denisov-Blanch, Stanford — AI Engineer
- Adyen utilizza DX per ottimizzare la produttività degli sviluppatori — DX
- 6 Ways to Enhance Developer Productivity with AI — IBM Technology and IBM Developer
- Multitasking Is Quietly Killing Your Engineering Team — The Serious CTO
Discussions Reddit
- Rant: Quota de prompt IA — r/developpeurs
- Software dev director, struggling with team morale. — r/ClaudeAI
- Contraté un líder para dirigir el equipo, pero el que propone y supervisa todo es el dev de 3M. — r/ColombiaDevs
- All devs in my team ran out of work : AI broke the productivity pipeline — r/developersIndia
