The most common framing I encounter about AI and engineering is individual: how does a developer use AI tools to write code faster? That framing is not wrong. It is just incomplete. The more consequential question is organizational: when AI tools become part of the normal workflow for an engineering team, what changes about how that team should be led?
The answer is not obvious, and the wrong answers are confidently popular. This is my attempt at a clearer one.
What has actually changed
Let me start with what the data suggests rather than what is rhetorically convenient.
AI coding tools have measurably compressed the time to write first-pass code for well-defined, bounded tasks. GitHub’s research on Copilot, early studies from commercial tool vendors, and the reported experience from practitioners converge on something in the range of 20-55% faster for tasks where the problem is clear and the code is greenfield.
That is a real change. But it is narrower than most of the headlines suggest.
What has not changed: The distribution of work in an engineering team. Implementation — writing the first version of working code — has never been the bottleneck in a mature engineering organization. The bottlenecks have consistently been:
- Understanding what to build (requirements clarity, problem framing)
- Integration with existing systems (the actual complexity of a real codebase)
- Testing, review, and the work of making code production-ready
- Coordination across teams and functions
- Debugging and incident response
AI tools help with some of these, meaningfully, in some situations. They do not make the full list shorter.
Where the leverage has shifted
Given this, what should a technical leader actually focus on in an AI-accelerated team?
Problem framing is now the most differentiated skill
Before AI tools, a senior engineer’s value was partly in implementation fluency — the ability to translate a fuzzy requirement into working code faster and more correctly than someone with less experience. That advantage has compressed. The gap between a junior engineer with AI assistance and a senior engineer on a well-defined task is smaller than it was.
What has not compressed: the ability to recognize when the problem is being framed incorrectly before significant code is written.
AI tools are very good at answering questions. They are not good at identifying which question deserved to be asked. An engineer who prompts an AI with a flawed problem specification gets a fast, confident, incorrect implementation. The tool cannot tell them that the problem was misdefined. This is now a more visible and more expensive failure mode than it was when the cost of writing incorrect code was higher.
The technical leader’s role includes protecting the team from this: ensuring that what is being built is the right thing before the team accelerates into building it.
Code review is changing shape
Code produced with AI assistance has a characteristic texture. It tends to be: syntactically correct, structurally reasonable, locally clean, and occasionally systemically wrong in ways that are not visible from the immediate context.
The systemically wrong cases are the ones to watch. An AI that generates a caching strategy, a data model, or an auth pattern may produce something that works in isolation and causes problems in the context of the larger system — because the AI does not have the context of the larger system.
Code review in an AI-accelerated team needs to shift emphasis. Less time on syntax and pattern correctness (the AI handles that reasonably well). More time on: does this integrate correctly with the systems it touches? Does it introduce coupling we will regret? Does the design decision embedded in this implementation match the decision the team actually wants to make?
This requires reviewers with system-level context, not just implementation familiarity. It is a more senior skill mix, not a less senior one.
Output velocity creates new coordination requirements
When one engineer or team can produce more code faster, the downstream functions that consume that code — product review, QA, deployment, and maintenance — face proportionally higher load. Teams that increase their feature output without increasing their test coverage, monitoring, and incident-response maturity accumulate risk faster than they realize.
A technical leader running an AI-accelerated team needs to watch the full system, not just the output rate. Shipping faster is only valuable if what ships holds up.
What this means for team structure
The traditional engineering team structure was designed around the assumption that writing code was the hard, slow thing. Senior engineers wrote complex code. Junior engineers wrote simpler code and learned to write complex code by watching.
That assumption is in flux.
Some teams are experimenting with smaller headcounts at higher leverage — fewer engineers producing more output by pairing AI tools with senior engineering judgment. The model prioritizes judgment density over headcount.
Others are finding that AI tools shift their bottleneck to non-engineering functions — design, product clarity, and the capacity of other teams to consume what engineering ships — and are investing accordingly.
What I do not think works: adding junior headcount to “scale” output without recognizing that the new bottleneck is judgment, not typing.
The case for investing in context
One underappreciated implication: AI tools increase the return on organizational context.
An engineer with deep knowledge of a codebase, a production history, and the reasoning behind past architectural decisions can use AI tools much more effectively than an engineer without that context. The context determines which AI outputs are safe to trust and which require scrutiny. Without context, the engineer cannot distinguish.
This is a direct argument for reducing churn, for mentoring that emphasizes system understanding over skill transfer, and for the kind of documentation (ADRs, architecture records, decision rationale) that distributes context beyond the people who were in the room.
Technical leaders who invest in organizational context now are building a more durable leverage advantage than those who invest only in tooling adoption.
Where I am uncertain
I want to be honest about the limits of this analysis.
The pace of AI capability improvement makes some of what I have written here temporary. If AI models develop significantly better long-context reasoning and codebase-level understanding in the next 18 months, the framing shifts. The bottlenecks I described as durable may compress.
What I am more confident about: the importance of judgment, context, and the ability to frame problems correctly does not compress. These are not skills that improve because AI improves at generating code. If anything, as the commodity value of implementation decreases, the non-commodity value of good judgment increases.
The technical leader’s job has always been to apply judgment in service of outcomes. That job description is not changing. But the surface area where that judgment is needed — and the places where it is most easy to avoid exercising it — is shifting. Noticing that shift, and adjusting accordingly, is the work.