From Doers to Directors

Automation is eating the boring parts of engineering, and what’s left is judgment. If AI writes most of the code, the work that still matters is deciding what’s worth building, designing the system it lives in, and being able to tell whether the thing you shipped actually works. I read that as a job change. People get promoted from doers to directors: fewer of them working through ticket queues, more of them owning systems and running incidents.

What gets automated first

The first work to go is the work that was already the most specified. Add a column and backfill it. Bump a dependency. Rename a config key across forty files. Write the CRUD endpoint that looks like the other twelve. These tickets arrive with the answer mostly attached, which is exactly why an agent can close them.

Plenty of engineering careers have been built on working through that queue quickly and well. It was honest work, and a reasonable way to learn a codebase. It’s also the part of the job that needs the least judgment, so it automates first.

I’ve felt this shift in my own setup. Running several agents in parallel in tmux, my role moved from writing code to something closer to a tech lead: steering the agents and reviewing what they produce.

The judgment that’s left

Take the code away and two questions remain.

The first is whether something is worth building at all. An agent will build whatever you describe. It usually won’t tell you the feature duplicates one you already have, or that a config flag would solve the problem in an afternoon. Speed without direction gets you to the wrong place sooner.

The second is whether the thing you shipped actually works: in production, for real users, under real load. That’s a higher bar than a passing test suite. It’s outcome review, and it takes knowing the system well enough to tell a healthy graph from a sick one.

System design sits between those two questions. Where the boundaries go, and which failure modes you’re willing to live with. An agent can propose a design. Choosing one means living with it, and that choice belongs to whoever is accountable for the system. That’s always been the core of the craft; as I put it in Code Was Never the Goal, the value was in the judgment, and the code was the medium.

Owning systems instead of tickets

A ticket ends when the PR merges. A system doesn’t end. Owning one means you answer for how it behaves in production, long after your diff went in. You know its SLOs and notice when it drifts toward them. You know which dashboard to open at 2 a.m. When it breaks, you run the incident.

Incidents are a good picture of what directing looks like. An agent can pull logs, line up deploys against the error spike, and draft the status update. Someone still has to decide whether to roll back or fix forward, who else to page, and what to tell customers. Those calls carry consequences, and the person making them has to understand the system well enough to be wrong in a recoverable way.

Thinking in feedback loops

The unit of work changes too. A doer thinks in functions: this ticket, this method, this test. A director thinks in feedback loops: what signal says the system is healthy, what happens when that signal goes red, and how fast anyone finds out.

Agents already depend on this. They do their best work inside a fast feedback loop that tells them within seconds whether a change is right. The director builds and owns those loops at every level. Lint and tests around the agent. A canary around the deploy. Alerts on production, and graded evals around the parts of the system that won’t answer the same way twice. Get the loops right and a lot of the individual functions can be written by something else.

Nobody hands you the promotion

I said promoted, and I mean it, but a promotion comes with a new job description. The skills that make a good director are learnable now: writing a spec clear enough that an agent can’t misread it, reading a system you didn’t build, and saying no to the feature that isn’t worth it.

The cheapest way to build those skills is with the same tools that are taking over the boring work. Ask the agent why the system is shaped the way it is before you ask it to change anything. Shadow the next incident. Pick something small and own it end to end, including the pager.

The ticket queue is shrinking. Owning systems, deciding what to build, and knowing whether it works is a bigger job than the one it replaces, and I think it’s a better one.