In a World of Agent Orchestration, Systems Thinkers Win

As I sit here doing core re-architecting of the entire backend of an application that was built over the duration of 5 years in a few weeks, the future of engineering is quite vivid to me, the future belongs only to engineers who understand applications at a system level.

Most of the new code won't be typed by me.

My days look like this. Two agents run side by side for hours.

One builds: it takes a piece of work, sends sub-agents through the codebase, and comes back with pull requests. I stay inside its loop, going back and forth and making small decisions as it works. It isn't churning away mindlessly.

The other one keeps us grounded in principle. When you're speed-running a refactor this big, it's easy for an executor to get carried away by the details in front of it. Long-running agents over-index on feedback you gave for one specific situation and start applying it where it doesn't fit. Collect enough of those and they lose sight of what the work was for.

So I keep the second agent's context apart from all that back and forth. It judges the work against the goal, not against every small correction made along the way.

It's a strange position to be in. I'm getting through more engineering than I ever could alone, I'm writing less of the code than I ever have, and I've never carried more responsibility for it. The bottleneck isn't typing anymore. It's me, deciding.

In Slop Grenades I argued that agents do the work but don't take responsibility for the choices inside it. This is the other half of that thought. If the choices are the job, the gap between engineers who understand the system and engineers who only implement it is getting wider, and it matters more than it ever has.

Implementation skill isn't wasted. It's what lets you judge the work at all. But if all you want is to pick up a finely specced ticket and execute it, I think that job is ending, because agents are very good at exactly that.

Your decisions travel further now

A decision that misreads the business used to move at the speed of one person. Now, it moves at the speed of a team. So does a good one.

Say you're splitting a large change across a team of agents, each working from the same written spec. In that spec, you assume the backend enforces your business rules, when in fact the UI does most of that work by hiding buttons and limiting options. If you were working alone, that mistake might leave one endpoint accepting changes the UI would never allow. With agents, it can spread through module after module. Their tests might pass too, because they were written from the same flawed assumption. The gap stays hidden until something other than the UI starts calling the backend, such as an integration or an AI agent. Every agent did what it was asked to do, but one bad judgement has now been applied across the codebase.

That's the case for systems thinking in one picture. When agents do the building, your understanding of systems is what you steer them with. It shapes how you spec issues, what gaps you identify, what you prioritise, how you prompt and when you notice the work drifting. The engineers who think in systems and understand architecture at a high level will be best equipped to direct the agents writing the code.

As agents take on bigger pieces of work, one engineer who understands the system will be able to steer work across multiple products and codebases. Teams are already asking more of each engineer now that they have more resources; it's part of why the forward deployed engineer is in demand again. Output is no longer the constraint. Judgement is.

What the code can't tell you

An old codebase has two kinds of weirdness: things nobody got around to fixing, and things nobody dares to remove. From the outside, they look the same.

During this re-architecture, an agent spotted what looked like a chance to tighten our permissions model. Some capabilities didn't fit the new architecture neatly, so it marked them for restriction. On paper, it was a sensible cleanup.

Except some of those capabilities were how our warehouse and buying teams do their jobs.

We weren't changing what staff could do, only how it happens: through modules that own their data, define the business rules once as explicit operations, and record every state change as an event. Taking those actions away would have made the architecture cleaner at the expense of the people who depend on it.

The agent wasn't being unreasonable. It worked with what it had. What it couldn't see was why those workflows existed, or what years of keeping things running had quietly built around them.

You can write these things down, and you should. Agents do better work when the business rules and the reasons behind them live in the codebase.

But businesses don't stand still. Priorities shift, workarounds become routine, and sometimes the reason something works the way it does lives only in the heads of the people using it.

The skill is recognising when the code isn't telling you the whole story, and drawing on your domain knowledge and understanding of systems to close that gap.

So what do you get good at?

If you're an engineer wondering where you fit, I wouldn't start by collecting AI tools or learning another framework. I'd start by changing how you approach the work you already do.

Take the next feature you're given and follow the whole workflow, not just the part you were asked to change. Where does it begin? Where does state change? What breaks if it fails halfway? What depends on the result?

You might realise you know how your change works in isolation, but not how it affects the system as a whole. That's the gap worth closing.

And when you write specs, write one you'd trust an agent to execute as written; without having to fill in critical gaps, or potentially make bad assumptions. Spell out what must still be true when they're done, and which decisions have to be the same everywhere. Ask yourself what they could get technically right and still get wrong for the product.

When you write specs, write one you'd trust an agent to execute as written, without having to fill in critical gaps or make bad assumptions. Spell out the invariants: what must remain true when the work is done, and where there is zero room for interpretation. Before anyone builds, have an agent interrogate the spec and drill for gaps.

Is it still worth getting into tech?

If you're just getting into tech, I can imagine how strange this looks. You're being asked to spend months learning something an AI seems to do in seconds.

I'd still tell you to learn to code.

You won't write every line of your career by hand. But you need to understand what you're asking these tools to build, how data moves and why systems fail. You can't challenge an implementation you don't understand.

Then build something: small enough to finish, real enough that someone other than you uses it. Let AI help with as much of it as you like.

The real education starts when people use it. When they do things you didn't expect, or a feature that made perfect sense turns out to solve the wrong problem.

That's where you start learning to think beyond code.

And find a world that interests you, whether it's logistics, finance, health, games or music. Learn how the people in it work and what frustrates them. You don't have to choose between understanding technology and understanding the world you're building for. The combination is the point. So pick one and develop real domain expertise in it: talk to the people on the ground, learn how it makes and loses money, and build something for a problem they actually have. If you get the chance to work in that industry, take it. Nothing teaches a domain faster.