The tech lead role when agents write most of the code

Stefan-Iulian Tesoi · 13 October 2026 · 7 min read

The tech lead role shifts from writing the hardest code to deciding what correct looks like before work starts and judging it when it returns. Unless review is shared and conventions live where agents read them, the lead becomes the team's throughput limit: reviewing all day and shipping nothing of their own for a month.

What does the tech lead role become?

It becomes the job of setting the standard work is held to, rather than producing the work that meets it. The classic tech lead responsibilities were three: write the hardest code, make the technical decisions, and unblock everyone else. A coding agent absorbs most of the first and makes the other two larger.

Ask an agent to add a field and it will add the field. It will not ask whether the field belongs on that model, whether the migration can run during business hours, or whether the module it touched is being retired next quarter. Someone has to have answered those questions before the item was handed over, or has to catch them in the pull request afterwards. On most teams that someone is the lead.

Engineering team structure changes less than the headlines suggest. This role changes more than most, because it sits on both sides of the agent: specification before the build, review after it.

Why does every agent's output route through one person?

Because the lead is usually the only person trusted to approve changes to the parts of the system that matter, and agents multiply the changes without multiplying the trust.

Four engineers running two agents each, with each agent finishing three items a day, produce 24 pull requests a day. At 10 to 20 minutes per item, the range worked through in AI code review, that is four to eight hours of reading every day. If the lead approves all of it, review is the whole job. That is the tech lead code review bottleneck: not a slow reviewer, but a single approval path.

The decline is gradual. In week one the lead keeps up by reviewing in the evening. By week three reviews are faster, which means shallower: the agent's summary gets read and the diff gets skimmed. By week six the lead is approving work on the strength of a description written by the thing being reviewed, and has designed nothing since the agents arrived. How many coding agents one team can run is set by this queue long before it is set by the agents.

A lead who reviews everything has become a rate limiter with a title. The fix is fewer reviews that need the lead, not a lead who reads faster.

Writing conventions where agents will read them

Every judgement a lead makes twice belongs in a file an agent reads before it starts. A review comment that explains a rule teaches one pull request. The same rule in CLAUDE.md, AGENTS.md or .cursor/rules reaches every run that follows, and what belongs in an AGENTS.md file is mostly rules that began as repeated review comments.

Decisions with a longer life belong in an architecture decision record. Michael Nygard's original 2011 format has four parts: context, decision, status and consequences. A record that size is short enough for an agent to read whole and specific enough for a reviewer to cite. "This breaks ADR 14" closes a review thread in one line, where re-arguing the decision takes twenty.

Our own repositories show the pattern. Piping the build gate through tail once let a failed run read as green, because a pipe reports the exit code of its last command; the conventions file now says the gate's exit code is the answer, and why. On 30 September an agent chained a worktree cleanup onto a piped merge. The merge failed, the pipe reported success, the worktree was deleted, and the commits survived only because git refused to delete an unmerged branch. Each mistake became one paragraph that every later session reads.

Some rules matter too much to leave to reading. The rule that every agent works in its own git worktree is written down and also enforced by a hook that refuses edits in the shared checkout, because several agent sessions share that checkout and one branch between them.

Laimonade hands the same rule files to every agent connected over MCP through its get_project_rules tool, so a rule written once reaches Claude Code and Cursor alike.

What should a tech lead stop doing?

Stop being the only approver, stop writing code an agent can build from a good item, and stop answering the same question in review twice. Five habits to drop:

1. Reviewing every pull request personally. Tier by risk. Payments, authentication, data migrations and public APIs go to the lead; the rest go to a rotation that checks against criteria written before the work began.
2. Writing routine code to stay sharp. It takes an item from an agent that could have built it while the review queue grows.
3. Re-explaining decisions in comments. The second explanation is the signal to write the rule down.
4. Accepting a summary as evidence. The diff and the test run are the evidence. The summary is a claim made by the author.
5. Rescuing a bad item at review time. When work returns wrong because the item was wrong, fix the item and send it back rather than patching the diff.

In Laimonade, a coding agent can carry an item as far as In Review and no further: the sprint workflow gives connected agents no tool that marks work Done. That keeps the verdict away from the author. It does not say who gives the verdict, and the answer should not always be the lead.

How does a lead stay close to the code without writing it all?

By owning the hardest item each sprint end to end, reading diffs rather than summaries, and debugging agent failures personally. A hands-on tech lead with agents is hands-on in different places:

• One item per sprint, start to finish. Pick the one with the most unknowns. Write the item, run the agent, review the result, and be the person who discovers what the item missed.
• Diffs in the risk tier. Read every change in the tier the lead owns, line by line, with the criteria open beside it.
• Failed runs. An agent that went wrong shows where the codebase is confusing, and that is architecture information nobody else is collecting.
• Spikes. Exploratory code exists to teach whoever writes it, so a spike delegated to an agent teaches the lead nothing.

The test is the date of the lead's last merged change. When it is more than a month old, the role has drifted into review only, and the reviews drift after it, because judgement about code decays when it stops being exercised.

Frequently asked questions

Should a tech lead still write production code?

Yes, but less of it, and chosen deliberately. The hardest item of a sprint, a spike, or a fix for a failure the agents keep repeating is worth a lead's hours. Routine features an agent can build from a well-written item are not. A lead who writes nothing loses the feel for the code that makes their reviews worth having.

How many reviewers does a team running agents need?

At least two people who can approve, and review hours that match output. At 10 to 20 minutes an item, every ten items a day needs 100 to 200 minutes of review. Split it by risk: the lead takes the risky tier, a rotation takes the rest, and nobody spends more than half of their day reviewing.

Who decides when an agent's approach is wrong?

The person who owns that part of the system, usually the tech lead for anything architectural. The useful question is whether the approach broke a written rule or an unwritten one. If it broke a decision record or a line in CLAUDE.md, reject it and cite the rule. If the rule was never written, the item was underspecified: write the rule, then send the work back.