Developer Productivity for Humans: four tensions of AI

In my review of “All Models Are Wrong But Some Are Useful”, I discussed why measuring developer productivity requires balancing speed, ease, and quality. A convenient model can simply leave part of the work out and show an impressive speedup. I then collected other studies from the Developer Productivity for Humans series in two posts, 1 and 2: developer goals, quality, technical debt, onboarding, and more.

I have now read a continuation, “Navigating the Tensions of AI in the Software Development Lifecycle,” published on September 4, 2026. The Google researchers examine what happens to this framework when AI enters the workflow. They analyzed 1110 open-ended responses from Google developers about AI's impact on their work over the previous three months. This is a qualitative analysis of experience within one company: it cannot provide a universal speedup percentage, but it reveals four tensions.

1️⃣ Work saved and work shifted Code arrives faster, but developers still need to clarify instructions, verify output, and fix errors. Some of the burden can move to another person entirely: the author submits a change quickly, and the reviewer has to understand all that generated code. One engineer's speedup still needs to be weighed against the effort of the whole team.

2️⃣ Rapid output and accumulating debt Developers describe verbose code and documentation that reads well but explains decisions poorly. The authors connect this to technical, cognitive, and intent debt: the system works, while understanding of its structure and rationale gradually erodes. AI can also help reduce debt; the tasks assigned to it matter.

3️⃣ An easy start and a difficult last mile AI helps build a prototype quickly, but edge cases, security, and integration with internal infrastructure remain. Some responses even described tools reporting successful tests without running them. The speed at which a demo appears can make it easy to overestimate product readiness :)

4️⃣ The ability to produce and the expertise to verify AI makes unfamiliar languages or systems more approachable. Yet developers may lack the knowledge to validate a solution. The authors discuss the risk of skipping the independent exploration through which expertise develops and losing skills over time. This is a risk, not a long-term effect established by this survey.

The authors then suggest concrete measures:

• Validate throughout the work: integrate tests and automated validation into the agent's loop, assign small tasks, and reduce switching between disconnected AI tools.
• Manage debt: remove duplication and poor abstractions, review documentation for substance, and preserve architectural rationale.
• Plan production readiness separately: account for validation and integration, and provide tools with context from internal APIs, code, and architecture.
• Protect learning: use AI as a tutor that explains, preserve mentorship, and keep independent work where the team needs deep expertise.

They close with team dynamics: clear processes, alignment with long-term goals, psychological safety, and balanced workloads. Engineers need to be able to say they are tired of auditing generated output or do not trust a result without fearing criticism for being too slow. A useful continuation of the discussion about productivity models: account for the people checking the output today and those who will have to evolve the system tomorrow.

P.S. I attached my annotated version of the article to the post, with passages I found interesting marked up (this is how I usually read whitepapers).

#AI4SDLC #AI #Engineering #Management #Productivity #Research