The Abstraction Ladder: Guardrails for Acceleration

I do not think AI has made me a 10x engineer.

If anything, AI has given me more engineering work.

That sounds backwards when the whole promise of coding agents is speed, but the more work I hand over to agents, the more effort I have to put into making sure they cannot quietly drive the project into a wall.

I write less implementation code by hand than I used to. But I spend more time thinking about tests, architecture, constraints, CI, conventions, acceptance criteria and all the other things that tell an agent what “correct” actually means.

The work has not disappeared. It has moved up a level.

The Abstraction Problem

There is a spectrum to using AI in software engineering.

At one end, you write everything yourself and maybe use AI to autocomplete a function. Then you move into generated implementations, larger bounded tasks, agent-driven pull requests and eventually something much closer to outcome-based delegation where you describe what you want and let the agent work out a large part of how to get there.

Every step up that ladder gives you more leverage.

It also gives the agent more opportunities to make assumptions on your behalf.

That is where I think the tension comes from for a lot of engineers. If you delegate too little, you miss out on a genuinely useful acceleration tool. If you delegate too much without understanding the system underneath it, you can quickly end up reviewing code that you no longer feel qualified to challenge.

I do not want to keep writing everything manually just to prove that I can code. But I also do not want to become the person approving generated code because the tests happened to turn green.

Faster Code Means More Guard Rails

Humans carry a lot of project context around implicitly.

We know that a certain pattern is frowned upon in the codebase. We know that a particular API should not be called from that layer. We remember the weird production issue from six months ago. We understand conventions that were never written down because everyone on the team simply learned them over time.

Agents do not reliably have that invisible context.

So if I want them to move quickly, I have to make more of those assumptions explicit.

That means unit tests. Integration tests. Contract tests. Type systems. CI checks. Linters. Architectural boundaries. Instruction files. Validation scripts. Acceptance criteria. Sometimes even dedicated test harnesses whose entire job is to catch the kind of mistake a human engineer would probably have noticed while writing the feature.

This is the part that gets missed when people talk about AI making engineering dramatically faster.

Yes, the implementation can arrive faster. But now I need better rails around the implementation.

The Bowling Alley Problem

The best way I can describe it is a bowling alley with the bumpers up.

Give an agent a task and it can throw the bowling ball much faster than I can. It can also throw a lot more balls in parallel.

That is brilliant right up until one disappears into the gutter because it misunderstood a requirement, hallucinated an API, created an unnecessary abstraction or “fixed” something that was not broken.

The tests and conventions are the rails.

The faster I want the agent to move, the more important those rails become.

Without them, speed just means I can generate bad assumptions more efficiently.

Why the 10x Engineer Thing Bothers Me

The phrase “10x engineer” has always been a bit silly, but AI makes it even less useful.

If an agent can produce ten times as much code, that does not automatically mean I became ten times more effective.

I might also have ten times more code to verify.

I might have several agents working at once, which means I now have several streams of decisions, assumptions and changes that need coordinating. I may be typing less, but I am spending more time designing the environment those agents operate inside.

That can still be a huge productivity gain. The important distinction is that the gain comes from parallelism and leverage, not magic.

AI lets me spend less time on repetitive implementation and more time on architecture, review, validation and the next problem waiting behind the current one.

That is useful. It is also still engineering.

Moving Up the Ladder

For me, the levels look roughly like this:

1. I write the code and AI helps locally.
2. AI writes a bounded implementation and I review it.
3. An agent explores the codebase, implements the change and runs the tests.
4. An agent handles a larger feature while I define constraints and acceptance criteria.
5. I define the outcome, architecture and guard rails while agents decide much more of the implementation path. The higher I go, the less useful it is for me to obsess over every line the agent types.

But the higher I go, the more important it becomes that the system tells me when the agent is wrong.

That is the abstraction trade-off.

Retrospective

I do not think AI means less engineering.

I think it means less manual implementation and more engineering around intent, constraints and verification.

That is why I am increasingly interested in test harnesses, agent instructions, CI rules and explicit architectural conventions. They are not bureaucracy around the agent. They are what make the acceleration usable.

The goal is not to remove myself from the work.

The goal is to move my attention to the part of the work where human judgment is still expensive, while letting agents chew through the parts that do not need me hovering over every keystroke.

So no, I do not think AI has made me a 10x engineer.

It has just given me a much faster bowling ball.

I still need the rails.