Every Developer Should Be The Tech Lead

The question people keep asking about AI and software is: will AI replace developers?

It is an understandable question, but I think it is too crude. It imagines the developer as a single execution unit: someone who receives a requirement, writes code, fixes bugs, and ships a feature. If that is the definition, then yes, AI will keep compressing the value of a lot of development work. A function, a component, a test file, a migration, a first-pass refactor — all of these are becoming cheaper to produce.

But execution has never been the whole value of a developer.

The value of a strong tech lead has always been broader: understanding the system, decomposing ambiguous problems, making technical judgments, coordinating work, spotting risk, and moving a group toward delivery. Code matters, of course. But the scarce skill is turning a fuzzy pile of work into a technical system that other people can execute reliably.

The agent era changes who needs that skill.

When executable capacity becomes cheap, every individual contributor has to learn how to lead a small engineering system. That system may include themselves, a coding agent, a research agent, a testing agent, a documentation agent, a design or product reasoning agent, and other human collaborators.

So I keep coming back to this:

Every developer should be the tech lead.

Not in the traditional title sense. Not necessarily as a manager, not necessarily as the senior engineer who owns a team roadmap, and not necessarily as the person who leads people.

I mean something more specific: every developer needs to become the technical lead of their own agent-powered system of work.

The Old Role Was Execution-Heavy

Much of software development has historically been execution-heavy.

You read the ticket, open a branch, write code, look up documentation, wire an API, run tests, fix lint, write the PR description, respond to review, and update the docs. A lot of the difference between developers showed up in who could do those things faster, more reliably, and with fewer mistakes.

That still matters. Deep technical understanding still matters. Debugging still matters. Code taste still matters.

But the economics of those execution steps have changed.

An agent can draft an implementation, search a codebase, generate tests, explain an error, refactor repetition, and summarize a release note in minutes. It will not always be right. It will not always be good. But it is already good enough to change the division of labor.

If you still define your role as the person who personally performs every execution step, you are competing with increasingly cheap execution.

That is not a good place to stand.

The Unit of Execution Changed

The old unit of execution was often one person.

The new unit of execution is increasingly a small system.

You can ask one agent to read the codebase, another to inspect the docs, another to propose an implementation, and another to review the result from a testing or security angle. Your job is not to sit in the middle and passively wait for outputs. Your job is to define the goal, narrow the scope, assign the work, review the results, and integrate the judgment.

This sounds like management.

But the better word is technical leadership.

Management is about people, incentives, performance, organizational health, and long-term growth. The new tech-lead-shaped IC is focused on the work system: Is the goal clear? Was the task decomposed correctly? Did the agent get enough context? Is the output verifiable? Can multiple outputs be merged into one clean technical decision?

This does not turn every IC into a manager.

It turns the IC into the technical lead of their own agent-powered engineering team.

The Bottleneck Moves Upward

When execution gets cheaper, the scarce work moves upward.

The scarce work is no longer simply: can you produce a version of the code? Many systems can produce a version of the code. The scarce work becomes:

• What problem is worth solving?
• How should the work be decomposed?
• Which parts should an agent handle, and which parts require human judgment?
• Did the agent misunderstand the system?
• Which outputs should be kept, rejected, or merged?
• How do you reconcile conflicting recommendations from multiple agents?
• When should you keep exploring, and when should you converge?

These are tech lead questions.

The difference is that a tech lead used to coordinate a few people. A strong IC may now coordinate agents, tools, test harnesses, documentation artifacts, and a smaller number of human collaborators every day.

That is the role shift.

The future developer hierarchy may not be as simple as junior, mid, senior, tech lead. A more useful split may be:

• Execution workers replaced by agents
• Engineers who use agents to accelerate themselves
• Tech-lead-shaped ICs who direct agents through complex work

The third group is not better because they write fancier prompts.

They are better because they can make a system move in the right direction.

The New Tech Lead Is Not a Manager

The easiest way to misunderstand this idea is to hear “tech lead” as a title.

I am not saying every developer should manage people, run meetings, own roadmaps, or become an organizational coordinator. Many developers are most valuable as deep ICs.

But deep IC work also changes in the agent era.

The old deep IC often cut through complexity with personal technical force. They could read the system, write the critical path, make the architectural call, and carry a hard problem themselves.

The new deep IC still needs that ability. But they also need one layer above it: the ability to externalize technical judgment into a work system that is executable, reviewable, and iterative.

They write code, but also briefs, task breakdowns, review criteria, eval checklists, and handoff notes. They care not only whether the diff runs, but why the agent made its choices, what it missed, and whether it violated the existing taste of the system.

They are not throwing work over the wall to AI.

They are leading the work.

The New Skill Stack

I would break the new skill stack into seven parts.

Intent definition. Define the goal before asking an agent to start. Good intent names the user, the problem, the boundaries, the success criteria, and what should not be done.

Task decomposition. Turn a vague objective into smaller pieces that can be executed, reviewed, parallelized, and rolled back. If you decompose the work badly, the agents will waste effort faster.

Agent orchestration. Know when to ask an agent to research, when to ask it to implement, when to keep it read-only, and when to have multiple agents produce independent views.

Review. Treat agent output as candidate material, not as the result. Strong developers review assumptions, boundaries, failure paths, security implications, and maintenance cost.

Eval. Build a way to tell whether the result is good. Tests, lint, benchmarks, human review, product judgment, and taste review are all part of eval. This is the same loop I wrote about in Taste, Intent, and Eval.

System thinking. Understand that a codebase is not a pile of files. It is a system with history, constraints, and inertia. Agents can generate local answers, but humans own system consequences.

Taste. The last layer is still taste: knowing what is simple in the right way, what is over-designed, what merely looks complete, and what will actually age well.

These sound abstract, but they change ordinary work in very concrete ways.

What Daily Work Starts To Look Like

A tech-lead-shaped IC does not start a task with: “implement this feature.”

They may start with a brief: what we are trying to solve, why now, what the first version includes, which files are probably relevant, and which behaviors must not break.

Then they ask an agent to do a read-only inventory. Not to edit yet. To understand the system first.

Then they decompose the work. One agent studies the existing implementation. One drafts a plan. One looks for risks. One proposes tests. When the material comes back, the developer does not average the answers. They make a technical judgment: keep this, reject that, merge these two, ignore this distraction.

During implementation, they keep the change scoped. They let agents handle mechanical work and personally review the critical path. During verification, they demand evidence: what ran, what was covered, what remains unproven.

At the end, they leave an artifact. Not because process is virtuous on its own, but because the next human, the next agent, or their future self needs a way to resume the work with context intact.

This can look slower than simply asking AI to write the code.

On complex work, it is faster. The slow part is rarely generating the first version of the code. The slow part is discovering that the first version solved the wrong problem or introduced complexity you did not notice.

The Biggest Risk Is Abdicating Judgment

The most dangerous developer in the agent era is not the person who refuses to use AI. That person will be slow.

The more dangerous developer is the one who uses AI heavily but stops owning technical judgment.

They throw vague requirements at agents. They treat agent output as done. They treat passing tests as correctness. They treat generated documentation as understanding. They treat a polished demo as product quality.

This style of work can look highly productive for a while.

Then the system starts accumulating invisible debt: more abstractions, softer boundaries, tests that cover only the happy path, documentation that explains the wrong assumptions, and a codebase that looks more complete but is harder to understand.

AI amplifies ability, but it also amplifies bad habits.

If a developer lacks taste, agents help them produce mediocrity faster. If a developer lacks eval, agents help them believe wrong answers faster. If a developer lacks intent, agents help them run in the wrong direction faster.

So the new tech lead skill is not about controlling more agents.

It is about owning more judgment.

Personal Productivity Becomes Organizational Capacity

This is why I think the shift matters.

Historically, organizational capacity mostly lived at the team and company level. One person could only do so much. Complex projects required multiple people, process, managers, and tech leads.

Agents move some organizational capacity down to the individual.

A strong IC can now have their own research capacity, implementation capacity, testing capacity, documentation capacity, and review capacity. These are not equivalent to a real team, and they do not replace all human collaboration. But they change the scale of work one person can responsibly take on.

The best developers of the next era will not necessarily be the fastest typists or the people who memorize the most APIs.

They will look more like operators of small technical organizations.

They know when to write the code themselves and when to have an agent write it. They know when to explore in parallel and when to stop exploring. They know when to trust a test and when to doubt it. They know when to accept a rough but correct solution and when to reject a polished but fragile one.

That is tech lead work.

It is moving from a formal role held by a few people to a basic capability of every AI-native developer.

Conclusion

AI will not simply make developers disappear. It will redefine which developers are valuable.

If your value is mostly executing fixed tasks, agents will keep moving closer to you. If your value is turning ambiguity into intent, decomposing complex work, reviewing outputs, integrating judgment, and owning the final quality, agents will amplify you.

This is why I like the phrase:

In the AI era, every developer becomes the tech lead of their own agent-powered engineering team.

That is not title inflation.

It is a change in the center of gravity of software work.

Code is becoming cheaper. Executable capacity is becoming cheaper. The expensive thing is the person who can lead it.