I recently went through nine months of my Claude Code history : more than 8,000 prompts across 2,000 sessions. I expected to find a collection of clever prompts. What I found instead was that the prompts had become the least interesting part.
The real change was everything around them.
A rough idea now goes through discussion, a written spec, small implementation plans, autonomous loops, independent reviews, manual testing, and finally a human sign-off. The model writes most of the code somewhere in the middle. That part has become almost ordinary.
AI made writing code fast. It did not make deciding what to build or knowing when it is ready any easier.
The work starts before the prompt
Most new work begins as a long, messy voice note. It has half-formed ideas, screenshots, Slack discussions, things I know, and things I am not sure about. I use OpenWhispr for dictation, though Handy is a good alternative too. Voice is useful because it removes the pressure to compose. The goal is not a perfect prompt; it is enough context for a useful conversation.
An experiment I'm trying out : For bigger changes, that conversation starts before the normal brainstorming. Two different models look at the same idea : one develops an approach, the other challenges the assumptions, security, and trade-offs. This is still an experiment, but the principle behind it feels right. A model should not be the only critic of its own idea.
Requirements are usually written in the language of the product. Codebases are organized around years of technical decisions. The distance between those two is where a lot of bad implementations begin. So before any code moves, the current system gets explained in plain language : how it works, what needs to change, and why that change belongs where it does.
Useful explanations are saved as Markdown or small HTML artifacts. My explain-it skill turns a codebase or a diff into something visual — old and new code, diagrams, and the reason behind each change. These pages are not documentation for the sake of documentation. They are how a mental model gets built before an agent starts moving the system underneath me.
A large change should not arrive as one large PR
Once the problem is clear, the conversation turns into a design and then an implementation plan. I use the brainstorming and writing-plans skills from superpowers for this.
The important part is not the plan itself. It is the boundary around it.
A large change gets divided into a stack of small pull requests : contracts first, then the core logic, supporting workflows, user-facing changes, and integration. Each PR depends on the previous one, but each is still a complete idea that can be understood on its own.
This changes more than review size. A smaller plan gives the agent a smaller world to reason about. It gives a human a realistic diff to read. And when something goes wrong, the failure has an address instead of being buried somewhere inside 4,000 lines.
The pull request is not just a delivery mechanism. It is a limit on how much complexity enters the system at once.
Autonomy needs memory
The implementation itself runs as a loop. Not the magical kind where an agent disappears for the night and returns with perfect software. The boring kind, with files and rules.
Every long-running task carries a contract, a progress tracker, and an append-only log. The contract says what must be true when the work is done. Progress records done, doing, and next. The log keeps the decisions and problems that would otherwise disappear with the session. A small usage check makes the agent stop cleanly before a quota runs out instead of dying halfway through an edit.
The test is simple : an agent should be able to lose its entire session and continue from those files alone.
The main session stays out of the implementation as much as possible. Its job is to hold the plan, make decisions, and delegate exploration, coding, and review to fresh agents. Context is too valuable to fill with every file search and test result. The orchestrator needs the conclusion, not the archaeology that produced it.
Inside each PR, the rhythm is straightforward : implement, commit, simplify, review, fix, repeat. The loop has a limit. If the same issue survives several rounds, more of the same reviewer is unlikely to save it.
There is one rule I care about more than the others : the reviewer cannot be the writer. A model that just wrote the code tends to review its intention. A fresh model has a better chance of reviewing the actual diff. Using a different model helps too, because different systems carry different blind spots.
The last five percent takes half the time
Several clean AI reviews can make a PR look finished. This is usually where the slower work begins.
CI runs, an isolated preview gets deployed, the real flow gets tested, the important code gets read, QA tests the preview, and the whole thing gets tested again on staging. Anything found here goes back into the PR as a normal fix. No grand autonomous loop is needed; the problem is now small and concrete.
Code review has become more conversational too. With a diff open, Codex voice mode can explain what changed and why, one file at a time. When something unfamiliar appears, the conversation can move backward into the surrounding system before returning to the line being reviewed. It feels much closer to having the author beside you than reading a generated summary.
But the human is still reading.
Five AI review rounds can miss the same issue five times. Tests can pass because the agent wrote both the implementation and the tests from the same wrong assumption. A clean pipeline is evidence, not proof.
The bottleneck moved to the boundaries
Looking at the whole process, the difficult work now sits at the beginning and the end.
At the beginning is the question of what should be built. An agent can offer three sensible approaches, but it does not know the customer, the business, and the cost of each trade-off as deeply as the team does. Clicking “recommended” through every brainstorming question is a very efficient way to build the wrong thing.
At the end is the question of whether the result deserves to reach production. That requires understanding the code, experiencing the product, and knowing where failure would hurt.
Everything between those boundaries is getting compressed. That is genuinely exciting. But the point is not to remove myself from the process. It is to spend less time typing code and more time on the decisions that make the code worth shipping.
The workflow can be reduced to one line :
Trust the agents enough to let them work. Stay close enough to understand and own what they produce.
I hope you find this article interesting. Thanks for reading. Until then, bye 👋