Every engineer is a team lead now

AI has massively accelerated the writing of code. Code is being produced at a rate we've never seen before. But does software actually ship any faster?

We've accelerated one stage of the pipeline but also need to address the other stages as well.

The job changed without anyone telling us

Ask an engineer what they do and most will still say "I write code". But is that answer still correct with AI in the mix?

The engineer's job is no longer to write code with the AI's help. It's to help the AI write the code. That sounds like a nuance, but it inverts the whole working day. Instead of producing the output, you're producing the input: you set the context, define the constraints, check the results and unblock. Every engineer becomes, in effect, a team lead, with models and agents as team members.

And like any team lead, you're responsible for the team getting better. If an agent keeps failing at the same thing, the failure isn't what you fix. The failure is the signal. Patch the symptom and you've fixed it for yourself, once. The real fix lives somewhere else entirely: a repo-level context file, a shared skill or a shared prompt. Fix it once in the right place and it stops happening for everyone.

The bottleneck just moved

The reason the gains stall is mechanical. Remove one bottleneck and the bottleneck moves. Once coding stops being the slowest part, the constraint shifts downstream: CI capacity, specification quality, approval chains, review, testing. You've unblocked one stretch of road and the congestion now sits at the next junction.

You can see it in any team that has adopted agents enthusiastically. A pull request that used to take a day to write now takes twenty minutes to generate. It then sits in the review queue for the same two days it always did, behind a CI pipeline that was sized for the old volume. More code arrived. The same amount shipped.

Accelerate or redesign

This is the real dividing line. Some teams use AI to accelerate the work they were already doing, in the workflow they already had. That gives genuine gains: faster boilerplate, quicker scaffolding, cleaner diffs. But it caps what the model can do for you, because you're optimising individual steps of a system you never questioned.

Other teams go further and redesign the lifecycle around the new economics. They ask where the work actually sits, why each step exists, and what it would take to eliminate it rather than speed it up. That's a harder question, and it's the only one that moves overall throughput.

Why your team's throughput hasn't changed

Any engineer can improve their prompts, write better context files and give cleaner agent instructions. That's a real improvement, and it's entirely a solo endeavour. Retooling the CI, renegotiating the review policy, provisioning infrastructure, changing what "done" means: that takes an organised investment, a budget and someone accountable for the outcome.

At that point it stops being a personal productivity story and becomes an engineering management problem. That distinction explains a lot of the quiet frustration out there. The person who has genuinely levelled up often finds their team's throughput hasn't changed at all. Their effort wasn't wasted. The constraint was simply never theirs to move.

What stays yours

Judgement and accountability. A model can produce the output, but it can't own it. As agents produce more of the code, human attention concentrates on exactly the places where the machine is weakest: understanding what the people using the software actually need, knowing the domain it has to work in, spotting when a plausible answer is wrong, and standing behind the result. That's not a consolation prize. It's the part that determines whether anything ships responsibly. The question was never who types the code. It's who does the thinking.

Sound engineering. Architecture, documentation and testing are still the foundation. What changes is the reasoning behind the best practices, because the cost structure has changed. Testing is the clearest example. End-to-end suites used to be rationed because they were expensive to write and painful to maintain. If generating and maintaining them becomes cheap, a far larger suite may well be worth having. Today's best practices were born of yesterday's economics. When the economics change, the practices are due a rethink, even if the fundamentals still hold.

Own how the work gets done

The role is moving in one direction: engineers now own how the work gets done, not just that it gets done. What that means depends on where you sit.

If you're an engineer:

• Automate the machinery of development instead of tolerating the repetition. Every manual step you do twice is a candidate.
• Put what the agent needs to know in the repo: a context file, conventions, the commands to build and test. Fix failures at the source, not in the chat.
• Share what you improve. A prompt or skill that only lives on your machine helps nobody but you.
• Escalate what you can't fix alone. Swallowing the friction quietly means the people who can change it never hear about it.

If you lead a team:

• Size CI for the new volume. If the queue is the bottleneck, no amount of prompt engineering will help.
• Revisit the review policy. Ask what each review is actually for, and whether a spec, a test or an agent could carry part of that load.
• Redefine "done". A clear specification is now the input that determines quality, so treat it as part of the work, not a formality before it.
• Fund it. CI capacity, process redesign and shared tooling are organisation-wide changes that no individual can authorise.

Skilled individual effort is essential and nowhere near sufficient on its own. Without the structural backing, the best you get is a lot of well-written code waiting in a queue.

In short

Code generation got dramatically faster. The delivery process around it didn't, so the bottleneck moved downstream and overall throughput barely changed. Speeding up individual coding tasks won't fix that; redesigning the end-to-end workflow will.

The fundamentals still apply: judgement, accountability, architecture, documentation and automated testing. They just need recalibrating for a world where code is cheap and attention isn't.

The engineer's job is now the whole system, not just the typing.

Have fun!