Delegate the Typing, Never the Attention

AI coding agents are force multipliers. But it’s worth being precise about what they multiply: whoever is operating them. A strong engineer directing agents gets multiplied output. The multiplier applies to judgment too, and that cuts both ways. Remove the judgment, and you’re multiplying something else.

I didn’t want to take that on faith. So I built the other side of the argument properly.

Meet CARL

CARL stands for Code Automation and Review Layer, and the name describes his two jobs.

The Code Automation side is an autonomous pipeline. CARL is hooked into Jira: hand him a story and he develops it, driving AI coding agents through the full development lifecycle to a finished pull request. He runs concurrent agents in isolated git workspaces, routes different models to different phases of the work, reviews the finished result, feeds that review back to the agents for rework, and pauses at human approval checkpoints along the way. He’s wired into the same harness the rest of our engineering runs on, a shared module of skills, standards, and firm context, so his agents build to our practices instead of the model’s defaults.

The Review Layer side reviews every pull request the team submits, following the same review skill our engineers use. Honestly, that side was almost free. CARL started life as our take on OpenAI’s Symphony, a published spec for orchestrating coding agents that teams are meant to implement themselves, and that original concept was only the automation side. But reviewing a PR needs everything the pipeline already had: GitHub access, agents, workspaces to check out the code. So I added it.

The real goal

I didn’t build CARL as a philosophical exercise. I built him so non-engineers could ship features. The dream is a colleague who can’t code writing a well-formed story in Jira, and CARL carrying it from concept to reviewed pull request without an engineer’s hands on a keyboard.

And it works. I tested him on a series of real features, and most of what came out was good.

What worked

Agents are genuinely reliable at well-specified implementation. Give one a clear brief with the context it needs and acceptance criteria, and it delivers, over and over. The failures almost never came from a model being unable to do the work.

The harness mattered more than the model. Shared context about our systems, coding standards that ship with every repo, and automated review at the end of the line moved quality more than swapping in a smarter model ever did.

And the Review Layer earned its keep immediately. It isn’t a rubber stamp; it catches real things we missed on the first pass, on every PR, whether a human or CARL wrote it.

The failure mode

Then I found the cliff.

When I stopped reading the code and started managing by end goal, describing the outcome I wanted instead of directing the work, output quality dropped a lot. Not subtly. One feature built that way shipped a real regression to production. We caught it and patched it quickly, but it changed how I run agents.

The important part is why the cliff exists. It isn’t about model capability. It’s about the operator’s visibility. Every problem I’ve caught in agent-written code, I caught because I read it. I couldn’t catch what I never looked at, and no amount of automated review fully replaced that. The agents didn’t get worse when I stopped paying attention. I did.

The verdict

Most of what CARL built was fine. Not exactly how I’d have done it, almost never bad, but not great either. And by the time I’d written the story carefully, worked the approval checkpoints, and read the result closely enough to trust it, the whole thing was taking me longer than doing the work directly.

Which points at something I didn’t expect to conclude: the pre-AI shape of the work still holds. Business communicates the goal. Engineering does the implementation. AI coding changed how fast the implementation happens and what one engineer can carry, but it didn’t remove the role where someone with technical judgment owns what the code actually does.

So the rule I run by now: delegate the typing, never the attention. I read what the agents produce, and I direct them with specific intent. The design stays human. That’s not a limitation of the tools. It’s what operating them well looks like right now.

Where CARL landed

CARL still runs, as the Review Layer of his own name, reviewing every pull request the team submits. The autonomous pipeline exists, and it works. It just lost a fair fight to an engineer driving good tooling.

Which is the multiplier thesis proving itself. The agents were the same in both cases. The difference was what they had to multiply.