The Agent Codes. I Decide What.
A year ago I was sure AI wasn’t going to replace my coding. I used it for review sessions and to ask for solution options. I loved figuring out the solution to a hard problem, and I thought I loved coding it just as much. I was never giving that up.
Then, this year, that flipped. The agents got good enough to implement a complete feature, and most of the time it didn’t need rework. I expected to be devastated. No more coding.
The opposite happened. I still like coding. I’m just surprised how easily I let the agent have it.
Back then AI was my pair programmer. Now it’s my pair requirements analyst.
The agent codes. I decide what. I always loved requirements analysis, interviews, domain modelling and brainstorming a solution. What I disliked was documenting all of it in detail. AI took over exactly the part I hated, and now I love doing it. About 70% of my time goes into requirements and steering the outcome, and then I watch the agent build what I asked for.
I do all of that with Compound Engineering in Claude Code.
Why I stopped prompting straight to code
Better AI models were only part of it.
Before this loop, building a feature was a prompt plus whatever was in the chat.
The agent started building, ran into an edge case, and made a decision. A reasonable one, to the best of its knowledge. But it didn’t have my knowledge. It didn’t know the customer, the earlier design choice, or the trade-off I had already made in my head and never written down.
So I reviewed, disagreed, and we did it again. Rework, over and over, and the fault was mine every time. I had never told it.
Now those decisions are made before the code exists, and they are written down. Including the why, which matters more than I expected: when the agent still has to decide something halfway through, it reads why I chose what I chose and decides the way I would.
What Compound Engineering is
Compound Engineering is a workflow from Every, shipped as a plugin for Claude Code. Two commands install it:
/plugin marketplace add EveryInc/compound-engineering-plugin
/plugin install compound-engineeringThe loop is brainstorm, plan, work, review, compound. Each step is a skill you call by name, and each one leaves a document behind in the repo.
The rule behind it, from Every’s guide: each unit of engineering work should make the next one easier, not harder. The guide puts about 80% of the time in planning and review and 20% in work and compound. Most of the thinking happens before and after the code gets written.
The last step is the one that gives it its name. After a non-obvious fix, /ce-compound writes down what was learned, in the repo, so the next session starts with it instead of rediscovering it.
I compared this loop with Microsoft’s version in an earlier post. This one is about my seat in it.
A day, through one feature
Here is the loop on a real feature from Flowline, my Dataverse ALM CLI. The problem: after a deploy, some settings, steps and (work)flows need to be set or disabled per environment. A connection reference, or a flow you want switched off in test. No command did that.
/ce-ideate, sometimes
When I don’t know what to build yet, ideate gives me ranked options with their trade-offs. I pick one. Most days I already know, so I skip it.
/ce-brainstorm: requirements, not ideas
Despite the name, this is requirements analysis. The agent interviews me. It goes back and forth through edge cases, acceptance criteria and open questions until the shape is settled, and writes it all into a requirements document.
When a question has more than one defensible answer, I run my own /options skill: the solutions side by side with pros and cons, and the agent says which one it would pick. I decide. For complicated requirements, I run /ce-doc-review over the document before it goes to planning.
The brainstorm for this feature proposed two commands: flowline config and flowline set.
For a simple requirement I skip brainstorm and go straight to plan.
/ce-plan
The plan turns requirements into steps at file level, with dependencies and how to verify each one.
The plan for this feature came three months later, and it threw out the brainstorm’s design. One command, flowline configure, instead of two. Secret handling became a plan of its own.
There’s no code in that decision. It’s a product decision.
Every plan also has to include the tests and the documentation updates. That’s my definition of done, written down before anything is built.
A plan also tells the agent where its authority ends. One on a client project says: stop and ask when the VAT rate for a product category is unclear, because that’s an accountant’s call, not an engineering one.
/ce-work
The agent executes the plan step by step and verifies each one. It simplifies its own code afterwards, and I often add /ponytail to push it towards the most minimal solution that works.
The single biggest improvement here: give the agent the real dev environment and let it run the integration tests itself. It catches its own dumb mistakes before I ever see them.
This is the step where I’m mostly a spectator.
/ce-code-review
Then the review. I go through the findings one by one and approve or skip each fix. My version also asks a second agent, Codex, for its view of the same change. A different model notices different things.
/ce-compound
I run this one a lot. Every non-obvious fix becomes a solution document in the repo.
One of them is about a Dataverse plugin package that silently stops registering new assemblies on update. That document became a blog post. More importantly, the next agent that touches deploy reads it first and doesn’t lose a day to the same bug.
Count the files in Flowline’s docs folder and you can see where my engineering went: 84 plans, 37 brainstorms (most of them archived now), 49 solution documents and 15 ideation sessions. The code is what’s left after all of that.
Running several at once
This is where it starts to feel like actual product management.
I work on several requirements in parallel, each in its own brainstorm and plan session. When one is ready to build, it gets its own git worktree and branch, and /ce-work runs there by itself. I wait until it’s done, then review.
On one project that means agents doing requirements sessions, implementation and reviews at the same time.
And I’m rarely on just one project. Several projects, each with several agents, is the point where you need a tool to manage them all. Right now I use Herdr, a terminal multiplexer that shows which agent is working, blocked or done, so I switch to whichever one needs me. I’m also trying JetBrains Air in Rider, which does the same inside the IDE and is in early access.
Where the hard problems went
When I wrote about this shift on LinkedIn, not every developer recognised it. That makes sense to me, because I think there are two kinds of developers, and the agent hits them very differently.
The first kind loves the hard problem in the code. The architecture, the clean abstraction, the bug you bash your head against, sleep on, and finally crack. That’s their craft, and it’s exactly the part the agent now takes over. For them, handing that to an agent means losing the best part of the job. I get that.
I’m the second kind. Solving a hard problem in an elegant way is my favourite part of this job too, but my hard problems were in the business: how a process really runs, what the customer actually needs, which rule breaks in which edge case. A manager once told me their team had spent three months working out how to solve a problem. I solved it in two weeks. The same manager told me I was a better requirements analyst than coder. I didn’t listen.
I always solved the problem before I started coding. I modelled the domain, the database, the flow through a UI, and worked out different solutions side by side. That was the part I loved. The coding came after, once the hard part was done.
The agent took the part after. For me the hard problems stayed, because they were never in the code.
That manager was right. It took an agent to make me listen.