The New Role of the Tech Lead in the AI Era

The tech lead used to be the person who could write the hardest part of the system. That was the source of their credibility and, often, the source of their bottleneck. They reviewed the critical diff, unblocked the tricky bug, and set the pattern everyone else copied.

Then the agent arrived and produced a plausible version of the critical diff in forty seconds.

The job did not become less technical. It became technical in a different place. When code is cheap to produce, the scarce work is deciding what should exist, defining the boundary it must respect, designing the check that proves it works, and growing the judgment of the people who approve it. I think of that as four ownership layers: architecture, verification, context, and capability.

A tech lead who only produces code competes with the tool. A tech lead who owns those four layers makes the tool useful.

What actually changed for the tech lead in the AI era?

The cost of producing a first draft collapsed. The cost of deciding whether the draft is correct did not. If anything, it rose, because the draft is plausible, arrives fast, and often comes without the reasoning that produced it.

The data shows the shift clearly. An October 2026 Harvard analysis using Jellyfish data from more than 700 firms found that AI coding agents correlated with 30% more lines of code, 20% more commits, and 23% more pull requests, while issue and epic resolution did not change significantly. The time from pull request to merge rose 49%, the share of pull requests with changes requested nearly doubled, and comments per pull request rose 35%. (Harvard/Jellyfish study)

DORA's 2025 research adds the organisational frame: AI is an amplifier. It magnifies the strengths and dysfunctions already present in the system. (DORA) A team with clear boundaries and strong tests gets more leverage. A team with ambiguous ownership and weak verification gets more expensive mistakes.

Experience is not a shield either. METR's randomised trial found experienced open-source developers took 19% longer with early-2025 AI tools on mature repositories, while believing the tools had made them 20% faster. (METR) That was early 2025; METR has since published newer data, and the perception gap is the durable finding, not the number. The lesson is not that AI is useless. It is that the feeling of speed is a poor instrument, and the tech lead has to build the instrument.

That is the tech lead's problem in one sentence. The tool amplifies whatever technical system you already have. Your job is to make the system worth amplifying.

What stays the same for the tech lead, and what does the EM still own?

You still own technical direction. You still make the calls on architecture, standards, and technical risk. You still carry credibility with the team, which means you still need to understand the code at a level that lets you challenge it.

What changes is the ratio. Less time producing first drafts, more time defining constraints, reviewing risk, and teaching. The tech lead becomes a reviewer of systems and a designer of the checks, not the fastest pair of hands.

The boundary with the engineering manager stays where it was, even if the work looks more similar. The EM owns people, performance, hiring, budget, and the operating rhythm. The tech lead owns technical direction and standards. The engineering manager role covers that split in detail; the AI-era addition is that the tech lead now owns the technical controls that keep agents safe, while the EM owns the policy that authorises them.

My rule for the boundary is simple: if the decision changes what people are allowed to do, the EM owns it; if it changes how the system enforces it, the tech lead owns it. That keeps the policy and the control from drifting apart.

In small teams one person may hold both roles. That is fine, but the decisions should still be separated. A policy that says agents may not touch production is an EM decision with a security owner. The mechanism that enforces it, a deny rule or a sandbox, is a tech lead deliverable.

What should a tech lead own now?

Four layers, each with a concrete artifact you can point to.

Architecture and boundaries

You own the answer to what is allowed to change, and what must not. That means module boundaries, service contracts, data ownership, and trust boundaries. It also means the decision about where an agent is allowed to operate: which repositories, which environments, which tools.

The artifact is a decision record or a short architecture note, not a diagram in someone's head. How to make better architecture decisions covers the process; the AI-era requirement is that the boundary is explicit enough for a model to respect and a reviewer to enforce.

Verification

You own the definition of done and the independent check behind it. A test suite, a schema, a policy check, an eval set, a manual verification step for the cases code cannot check. If the only proof that the work is correct is the agent said so, you do not have verification.

This is the layer most tech leads underinvest in, because it is less fun than designing the system. It is also the layer that determines whether the team can adopt a better model next quarter without re-litigating every change.

Context

You own the written context the team and the agents work from: specs, decision records, conventions, tool descriptions, and the short memory file that tells an agent what it cannot infer from the repository. Anthropic's guidance is blunt about this: write down what the agent cannot find by reading the code, and keep the file short. (Anthropic)

The artifact is a small, current AGENTS.md or CLAUDE.md, plus specs that state the outcome and the constraints. Not a wiki. Not a 3,000-line prompt.

Capability

You own the growth of the engineers who will replace you on the hard problems. That means review coaching, deliberate practice, and giving people ownership of something end to end. AI makes this easier to neglect because the agent can fill the gap. Neglecting it is how a team ends up with ten people who can prompt and nobody who can debug the payment flow at 2 a.m.

How do you set review standards when code is cheap?

I would stop reviewing everything the same way. Risk-tier the change, cap the size, and require the author to carry the context into the review.

You can make that workable with four rules:

1. Tier by blast radius. A dependency bump, a docs change, and a payment-flow change do not need the same reviewers. Define the tiers and the required approvers.
2. Cap the size of agent-generated changes. Split by logical unit. If a reviewer cannot explain the intent and risk after one focused pass, the change is too large or too poorly framed.
3. Require a review packet. Intent, scope, risk, evidence, and the files that deserve the closest read. This is the context the agent did not carry.
4. Use AI review as a first pass. It is good at consistency, missing tests, and obvious defects. It is not the sign-off, and it should not be the only reviewer of its own output.

The review question that replaces line-by-line reading

The old default was read every line. That does not scale and it was never a great use of a senior engineer's attention. The better question is:

What would have to be true for this change to be safe, and which of those things has an independent check?

For a schema migration, the answer might be a backward-compatibility test and a rollback plan. For an authorization change, it might be a threat model and a negative test. For a UI change, it might be a screenshot and a manual check. The reviewer spends attention on the claims that are not independently verified.

This is also how you avoid rubber-stamping. A diff that arrives with evidence is easier to challenge than a diff that arrives with a confident summary. Ask for the evidence, not the narrative. Trust becomes concrete here: Stack Overflow's 2025 survey found 46% of developers distrust AI accuracy and only 33% trust it, with two-thirds citing almost right, but not quite as their top frustration. (Stack Overflow) Review standards are how you convert that distrust into a check instead of a bottleneck.

You also need to instrument the queue itself. If review pickup time or review latency is rising, the problem is capacity or batch size, not reviewer effort. The delivery job and the flow metrics work cover the queue mechanics; the tech lead owns the standards that keep the queue from filling with unreviewable changes.

How do you design the context an agent needs?

I write down what the agent cannot discover by reading the repository, and keep it close to the work.

You need four artifacts, and they carry most of the value:

• A short memory file. The test, typecheck, and lint commands; the conventions that are not obvious from the code; the directories that look unused but are not; the decisions that live in meetings. Keep it under a couple of hundred lines and delete anything the agent can infer.
• A spec per non-trivial change. The outcome, the constraints, the edge cases, and what is out of scope. A spec turns build something into a checkable task.
• Decision records. Why the boundary exists, what alternatives were rejected, and what would trigger a revisit. This is the context that stops an agent from improving a deliberate trade-off.
• Tool descriptions that state when not to use the tool. A model choosing between two similar tools needs the negative case as much as the positive one.

Write for the next engineer, not the model

The temptation is to write a giant prompt that encodes everything. It does not work. Long instruction files get lost, contradict themselves, and consume context on every task. The durable version is the same documentation you would write for a new engineer: short, specific, and maintained. Team Topologies frames team cognitive load as a limiting factor on what a team can own. (Team Topologies) AI adds to that load: every tool, policy, and review surface costs attention. A context file that grows without limit is not just a prompt problem; it is a cognitive-load problem for the humans who have to keep it true.

The test is simple. If a competent new hire could not act on the document without asking three follow-up questions, it is not ready. If the agent keeps missing a rule that must always hold, move it from the document into a deterministic control such as a hook or a deny rule. Documents guide judgment. Controls enforce invariants.

How do you keep architecture judgment sharp?

I keep making decisions, and I keep the reasoning visible. The risk is not that the tech lead forgets how to code. It is that they stop exercising the judgment that made them a tech lead, because the agent always has an answer ready.

You can protect it with three habits:

Run design reviews on the hard calls. Not a status meeting. A short session where someone presents the boundary, the alternatives, and the failure modes, and the team tries to break it. The agent can prepare the options; the humans own the trade-off.

Keep a decision log with the rejected options. The rejected option is where the judgment lives. Six months later, it is the difference between a deliberate constraint and an accident.

Prototype with the agent, then decide without it. Use the agent to build the throwaway version that makes the trade-off concrete. Then close the laptop and reason about the consequences: operational cost, failure modes, team cognitive load, and the cost of changing your mind.

The technical debt vs architectural debt distinction matters here. Agents are very good at adding local code and very bad at noticing that the local code is increasing architectural debt. The tech lead is the person who notices.

How do you grow engineers' judgment?

I give them decisions to make, with a safety net, and make them explain the reasoning.

The risk in an AI-assisted team is that juniors get the output without the reps. They can generate a working feature without understanding why it works, and they can review a diff without being able to write it. That produces engineers who are fluent in the tool and fragile in the system.

I use four practices:

• No-agent reps. Small tasks where the point is the practice: a bug fix, a test, a refactor. The output matters less than the reasoning.
• Explain-back reviews. After a junior reviews an agent-generated change, ask them to justify each acceptance and rejection. If they cannot, the review was a vibe check.
• Pair on the hard part. Let the agent do the scaffolding, then have the junior implement the tricky function and walk through it.
• Ownership. Give them a component end to end, including its tests, its on-call, and its incident history. Ownership is the fastest way to build judgment because the consequences are real.

The people job covers the coaching mechanics. The tech lead's specific contribution is technical feedback: naming the trade-off, explaining the failure mode, and showing the alternative.

How do you evaluate AI tools as a tech lead?

Evaluate them on your tasks, not the vendor's benchmark. A model that tops a coding leaderboard may be mediocre on your legacy codebase, your conventions, and your review process.

You can run a practical evaluation in four parts:

1. A task set from your own backlog. Ten to twenty real tasks, including the boring ones. Measure completion, review effort, and rework, not just speed.
2. A security review. What data leaves the environment, what the tool can read, what it can execute, and how credentials are handled. The LLM skills guide gives the management view; the tech lead owns the technical verification.
3. An integration check. Does it work with your version control, CI, identity provider, and review workflow? A tool that adds a parallel workflow creates more coordination cost than it removes.
4. An exit cost. How hard is it to remove? Proprietary prompt formats, vendor-specific agent configs, and data locked in a proprietary index are switching costs. Prefer portable artifacts: plain Markdown, standard protocols, and scripts you can run yourself.

I would also test the tool's failure behaviour, not only its success behaviour. How does it respond when the tests fail, when the repository is huge, when the dependency is private, and when the network is slow? A tool that is brilliant on the happy path and opaque on failure will cost the team more than it saves.

Do not evaluate on a demo. A demo is a curated task with a curated reviewer. Your backlog is the only benchmark that matters, and the review effort is part of the result. A tool that doubles the speed of writing but doubles the review time has not improved the system; it has moved the queue.

What do you own when an agent causes an incident?

You own the missing control, not the model's mistake. That framing matters because it turns a blame conversation into a systems conversation.

You should answer four questions in the review:

• What did the agent do, with which permissions, on whose authority?
• Which check should have caught it, and why did that check not exist or not run?
• Was the change reviewed by someone who understood the risk?
• What is the smallest control that prevents the same class of failure: a deny rule, a test, a review tier, a sandbox change?

I would also separate two questions in the review: was the task appropriate for an agent, and was the control adequate for the task? A missing control on a suitable task is a system fix. An unsuitable task is a judgment fix. Treating every incident as a model problem hides both.

The model may have produced the defect, but the system approved it. Fix the approval path. Add the regression case to the eval set or the test suite. Then decide whether the task was appropriate for an agent at all. Some tasks are not, and the tech lead is the person who should say so before the incident rather than after.

What does the week look like now?

You will not find a universal allocation, but the shape I aim for is roughly:

• A third on design and review. Architecture, specs, decision records, and the review of high-risk changes.
• A quarter on hands-on work. Prototypes, hard bugs, and the parts that keep technical credibility sharp.
• A quarter on context and platform. Memory files, tool descriptions, test infrastructure, evaluation harnesses, and the small tools that make the safe path easy.
• The rest on people. Review coaching, pairing, and the unglamorous conversations that grow judgment.

The exact percentages matter less than the direction, and you should treat them as a starting point rather than a policy. A tech lead with a large migration may spend two months at 60% hands-on; a tech lead running three teams may spend two months at 10%. The question is whether the mix matches the constraint the team has right now, not whether it matches a template. If your week is still 80% producing code, you are optimizing the part that got cheaper. If it is 0% producing code, you will lose the judgment that makes the other three quarters credible.

I would rather have a tech lead who spends an hour designing the check than one who spends the same hour polishing a diff the agent will regenerate tomorrow. The tech lead's leverage in the AI era is not in writing more code than the agent. It is in making the system legible enough that the agent's output can be checked, bounded, and improved. Own the boundaries, the verification, the context, and the capability. The code will follow.