From Writing Code to Directing Agents

From writing code to directing agents

Examples of tasks in these circles are of course not clear-cut, and the boundaries are blurry and connection points are numerous. Roughly speaking, you could think of it like this:

An alternative way to think about this is that the outer circle was what you did in meetings, or what the tech lead handled, or what happened before and after the "real work.". And the inner circle began when those guys split and you got back to coding.

AI-assisted development adds a new abstraction level to our work. Getting serious about this means you need to actually make that leap. Now, even though AI might very well handle most of the typing, the inner circle doesn't disappear, but it shrinks, and more of your efforts will be in the outer circle: deciding what to build, specifying it precisely enough for an agent to build it correctly, reviewing whether the result meets the standard, and governing the process that connects these activities.

Naturally, this is a "shift left" in a much deeper sense than the DevOps community originally meant. Originally we shifted testing left, with the idea that writing tests earlier catches defects sooner (this of course still holds). Now the new shift left moves the developer left: from production to direction, from writing to specifying, from building to guiding.

Everything that follows in this chapter — what the daily work looks like, why senior engineers struggle, where junior developers go, how complacency creeps in, why the identity shift is hard — is a consequence of this inversion.

What actually changes Day-to-Day

Now that we're convinced this shift is inevitable, it's a good time to say what it really means. I'll throw in examples by role, and my assessment of what the future holds for us.

Architects

Designers

Developers

Testers

Cloud engineers, SREs

Project managers

What's left for junior developers?

In traditional software engineering, junior developers learn by doing progressively harder work. They start with simple bug fixes, graduate to small features, and over several years build the pattern library and system intuition that makes a senior developer effective. The work is sometimes tedious, but the tedium is where learning happens.

AI-assisted development threatens this pipeline directly. If agents handle the pattern work that juniors learned on, how do they build judgment? If they never write a service adapter from scratch, how do they learn to recognize when an agent has written one incorrectly? If they never debug their own logic errors, how do they develop the diagnostic instincts that make review effective?

My point here is that in order to validate a plan or outcome, which is the supposed new role, you need to have an idea what it should look like, know what the correct answer is. You cannot tell what it is without experience. Failing to do so, as will be the case, we will have a problem. If you let a number of inexperienced juniors go AWOL with agents for a week, with all certainty they'll end up generating a month's worth of technical debt, dozens of hard-to-find subtle bugs, and a codebase that nobody understands. The senior engineers will be left with the task of cleaning up the mess, and the juniors will have learned nothing but how to make a mess. Actually, this kind of roles ('openings for Senior Slop Fixers') seem to have already emerged.

I'm not making an argument against AI-assisted development here. It is an argument for deliberate investment in junior developer training programs that use governed AI development as a teaching tool and insisting on knowing the old way as well. In this program, or whatever, juniors should learn specification writing, review technique, and system design explicitly, rather than absorbing them implicitly through years of code production.

The automation complacency trap

This applies directly to governed AI development. A plan approval gate is only as good as the human's willingness to read the plan critically. A review gate is only as good as the human's attention to code they didn't write. If the AI's output is good 90% of the time, the human reviewer will learn, perhaps unconsciously, over weeks, to expect correctness and skim rather than scrutinize. The 10% of the time the output is subtly wrong is exactly when the human's attention is most likely to have lapsed.

And the output looks and feels good, down to the wording like 'Your code is now ready for production.'. It's entirely understandable to skip the hard part of verifying the work and just approve, as the literal quote from a generally used LLM already said we're done.

The literature suggests several mitigations that translate to software governance. Rotation of review responsibility prevents any single person from becoming complacent with a particular agent's output style. Varying the level of AI autonomy on purpose, like running agents with deliberate constraints that require more human input could keep reviewers engaged. Surprise audits of gate approvals, where a second reviewer evaluates whether the first reviewer caught issues that were present, keep the reviewers honest too. Perhaps this might feel like overkill, but it is something you'll need to address to mitigate this trap of trusting the automation too much.

None of these are magic bullets. Automation complacency is a deep feature of human cognition, not a process deficiency. Acknowledging the facts on the ground, rather than assuming that "mandatory human checkpoints" will automatically produce careful human review is the difference between governance and governance theatre.

The new role nobody planned for

This worked to some extent when the commercial cloud offering was simple, but it grew complex enough that it couldn't remain a side responsibility. You've heard it all: dozens of certifications, consoles, IaC formats, well-architected pillars, the N Rs of cloud transformation, and so forth. The "cloud engineer" emerged not because anyone planned the role, but because the work demanded it.

AI-assisted development requires something similar. Whether we call this new job description the AI Agent Engineer, or the AI Governor, or the Agent Orchestrator does not make much difference. The point is that someone needs to own the responsibility of maintaining the agentic development environment, and that responsibility is not optional. This role includes but is not limited to:

And this is iterative and continuous. I think it's unreasonable to expect this to be everybody's job or a shared responsibility. It requires a level of attention and care that is hard to maintain when it's not owned by anyone. Whether this is a full-time job remains to be seen and is obviously dependent on the project.

In small teams, this easily falls on whoever cares most. Usually this falls to a senior developer who has developed intuitions about what makes agents effective, and perhaps was an early adopter of AI in the first place. But as teams grow, the "whoever cares most" approach breaks down the same way "whoever manages the servers" did. The work requires dedicated attention, systematic maintenance, and a skill set that combines understanding of the development process, agent capabilities, and the project's evolving needs.

The identity shift might be the hardest part

Many software developers chose this career because they enjoy building things. Myself included. Also quite a few of us began programming long before entering the job market. The satisfaction of solving a puzzle, of seeing your code work, of creating something from nothing can be lost forever when delegating that part to AI.

And this shift is a matter of identity. Many take pride (often well deserved) in their craftsmanship of writing good code, clean architecture, or beautiful design, if it wasn't really you doing it. You know the scene: you meet a fellow developer and the first question is "what do you code in?", not "what do you govern in?".

Working with an AI agent is more like managing a team than writing code. Or sometimes like working as a kindergarten teacher. You set direction, review output, make judgment calls, and accept responsibility for results you didn't directly produce. Some developers find this deeply satisfying: the power you can unleash is intoxicating, and the problems are harder. You can build tools and make refactoring decisions you would have dismissed outright before as too laborious or risky. For others it feels like a demotion: instead of engineer or builder, you become some kind of "orchestrator" or "curator" or "governor." The work is more about people and process than about code, and that can be a hard shift to make.

Anecdotally, the long-timers seem to be the ones who get on with it more naturally. Perhaps they've already typed enough code for a lifetime, and they're generally more comfortable with character-based UIs and the back-and-forth of a terminal session. The CLI-first workflow of modern AI coding tools feels familiar to someone who grew up with vi and grep, less so to someone whose entire career has been in graphical IDEs with drag-and-drop scaffolding.

Sunk cost fallacy and the willingness to start over

Especially early in the lifespan of a project, a lot of the work is basically throwaway. It's been like that forever, but the things you ought to have thrown away will haunt you for the rest of your lifetime. How it usually turns out is that the next sprint brings new features, not rewrites of the old ones or the long-awaited pause to think things through properly.

So what usually happens is this:

Often it is hard to admit that we need to start over. You know, the sunk cost fallacy and the reluctance to admit we went wrong are both very much human nature.

I'd argue that this time it's different: regenerating major parts is a viable strategy, especially if you have good specs and know what you're doing and you can manage it. At least it's possible much later in the project than before; the attempt that produced 40,000 lines of throwaway slop might not be the disaster it would've been in the old days. Refine the architecture and your designs, and let the agents take another shot at it. At least it should be; you didn't write it yourself, did you, so what's the harm in trying again?

A word of caution though: this applies best to bounded components and early-stage work. Once the system is in production, integrated with other services, and storing real data, the window for wholesale regeneration closes fast. Chapter 11 explores that "point of no return" in detail. But within bounded scope, the willingness to throw away and redo is a genuine advantage of this way of working.

By adjusting your mental model to better admit defeat, consider this as a learning opportunity, regroup and do it again! Better yet, if you have lots of premium tokens to burn, you can even experiment with different approaches and see which one works best.