What happens to engineers when AI writes all the code?

We are plausibly coming to a moment where AI will write all the code. This is a reality for many developers already. Over the last 4 months at PostHog, we moved from around 20% of our monorepo PRs being opened by agents to 70%.

This breaks the definition of engineer as “someone who writes code.” But no one thinks engineers will go extinct as soon as this happens. Anthropic has claimed “coding is largely solved,” yet it has 208 open roles with “engineer” in the title.

So what will engineers be doing?

1. Monitoring the situation

Engineers spend a lot of time monitoring running agents, fixing errors, responding to customer requests, evaluating competitors, checking dashboards, strategizing on their role in company priorities, learning new workflows, and babysitting outstanding PRs.

I sum this up as “monitoring the situation.” The result of it is ideas and observations of how they can improve.

Engineers did a lot of this before, especially product engineers, but AI has amplified it. AI increased the amount of information an engineer can process, but it also increased expectations from managers and customers about productivity and polish.

This means engineers can’t be waiting for the right information to come to them. The best ones now create systems to get the information they need at the right time. This is part loop engineering and part context engineering. Engineers at PostHog have standup bots, repo summary scouts, custom setups for monitoring in-progress PRs, feedback surveys, changelog automations, anomaly alerts, and more.

Why is doing all this important? Because without this information, you will likely end up working on the wrong thing and not know it. Knowing all the possible things you could be working on enables you to prioritize and pick the right one.

2. Setting direction

Software might be increasingly driving itself, but you still need to say where you want it to go. This requires synthesizing and analyzing what you observed to figure out what is valuable and worth acting on.

Based on the input an engineer receives, there will be hundreds of potential paths. In the past, product managers or execs might have been responsible for picking the best ones, but it’s now increasingly up to engineers.

Our requests for comments repos are an example of what this looks like. They contain nearly 1,000 direction-setting decisions on topics like dashboard MCP improvements, environments, and picking programming languages. We can look at an RFC for a unified health page as a specific example. It filters information through:

Without a clear direction, you can feel productive without actually making progress. AI makes this worse by enabling you to add anything you can think of easily. The direction and experience of your entire product can become clouded by features that aren’t what users actually want or you can be quickly led down the wrong path that’s hard to reverse.

3. Deciding how to build and implement

Engineers might not be writing code, but they are still deciding what code gets written. A direction leads to many smaller decisions. Each decision is a hypothesis of what can be built to make progress towards the direction you're going.

What this often looks like is deciding on scope. This requires knowing the codebase, what’s possible, what agents are capable of, and their blind spots.

The importance of this is made clear when I compare myself against real engineers. As a marketer, I monitor the situation and think about the direction products should be going in. I make feature requests and can use agents to implement them, but just the ability to generate code, even in the right direction, is not necessarily good engineering.

For example, I wanted the ability to send AI user interviews as a link rather than an email. Although I could have asked an agent to build it, Paul’s reply shows the knowledge I lacked for making a good implementation decision.

I wouldn't have known to accept distinct_id and session_id as query parameters, to throttle requests, or to look at hosted surveys for inspiration like Paul did. At best, my agents would have taken many more tokens to get to the same solution. At worst, they would have introduced bugs and attack vectors.

It’s this understanding of the problem area, implementation details, and structure that enables engineers to ask the right questions and follow up to get a solution shipped.

4. Evaluating the work of your agents

This is the point where engineers would have been writing the code. Now, they just tell the agent to do it and that’s it, right?

Sadly, not yet. Engineers still need to evaluate whether it was built right.

This is done through code reviews and asking questions like:

With the volume of changes coming from agents, this quickly becomes a bottleneck. If you are generating 20 PRs per day, reading every line and running them by hand is unrealistic. You need new systems, like review and testing agents, to keep up while ensuring the code you ship is good.

For example, many of our engineers have their own custom-built code review and PR management setups. Tom on our warehouse sources team built Talyn as a “mission control” for his PRs, our DevEx team built speedy virtual machines to preview changes, and we’ve already written about Paul’s code review setup.

Systems like these are necessary when engineers are seeing a dramatic increase in the amount of pull requests they need to review. At PostHog, we went from 1,441 PRs merged in January to 4,869 in August while only growing engineering headcount 10%.

5. Improving the entire loop

This process doesn't just end. It loops repeatedly. What you build and ship leads to new observations like “are people using what we built?”

The loop isn’t just linear either. Stages feed back on each other:

It’s not just one big loop, but many smaller loops as well. The consequence of this is engineers doing more work on the system that builds the product than the product itself. They build the software factory rather than the software.

The growing capability of agents means there are cases where you can skip much of the loop too. Agents often only really need direction and the right tools to ship a valuable fix. With these, they can then figure out what to build, how to build it, and evaluate whether it actually worked. Here’s a real example from PostHog:

In this case, the monitoring, deciding, and evaluation were all handled by the agent, the direction to improve the MCP server was implicitly guiding it, and our product improved without us needing to do anything. We call this making your product self-driving.

But even this case is reliant on your skills and knowledge as an engineer. Writing code might be cheap, but your system for building a product isn’t. All your sources of information, your way of setting direction, your implementation knowledge, the way you evaluate what was built, and the connections between these stages becomes what makes you and your product unique.

This is all still engineering work. It just doesn’t look like it once did.

Words by Ian Vanagas, OODA loop respecter. Graphics by Lottie and Daniel. Originally published in build mode, a free newsletter by PostHog.