"You can outsource your thinking, but you can't outsource your understanding."
Andrej Karpathy, AI Ascent discussion on agentic engineering
That sentence captures how I use coding agents. I delegate research, planning, implementation, and review. I keep responsibility for understanding the system and deciding whether a proposed change is the right one.
Coding agents can take a short prompt and produce an entire application. Vibe coding embraces that possibility, including the experience of guiding software by its visible results without reading every implementation detail.
I come from an older engineering habit. I need to understand what I am building before I ask an agent to build it. I want the behavior, constraints, risks, and definition of done written down well enough that I can judge the result. My workflow is a lightweight form of specification-driven development, with concrete examples where they make the expected behavior clearer.
I usually begin with a short description of what I need. It names the outcome, the reason for the change, and any constraints I already know. I do not try to write a complete implementation plan at that point.
The next step turns that brief into something an implementation agent can execute. I ask a capable planning model, often Opus, Fable, or GPT-5.6 Sol at high reasoning effort, to inspect the project and develop the missing detail. A separate critic then reviews the proposed specification, preferably through another frontier model.
I approve the reviewed specification before implementation starts. That is the point where I decide whether the plan represents what I wanted, whether the tradeoffs make sense, and whether the proposed evidence will be enough to accept the result.
Start with the outcome
My first brief is intentionally small. It should give the planning agent direction without making guesses about code it has not inspected.
For an illustrative interface change, I might start with this:
Task: Add a clear empty state to the project list.
Outcome:
A user with no projects should understand why the list is empty
and what action is available next.
Preserve:
Existing project links and filtering behavior.
Context:
This should remain a focused change. Check the existing component,
tests, responsive layout, and accessibility patterns before proposing
the implementation.
This gives the planner a destination and a boundary. It does not prescribe files, markup, or test cases before the repository has been examined.
Let the planner develop the specification
The planning agent reads the project instructions and the relevant code. It identifies which behavior changes, what must remain compatible, which parts of the system are involved, and how the result can be verified. If the request leaves an important product or architecture decision open, the plan should surface it instead of choosing silently.
A useful specification normally answers questions such as:
- What user-visible or system behavior should change?
- Which existing behavior and interfaces must be preserved?
- What is outside the scope of this change?
- Which dependencies or sequencing constraints affect the work?
- What tests, builds, and local checks will demonstrate completion?
- Which risks require rollback, migration, security, or data-integrity planning?
The result is more detailed than my original brief. Implementation choices remain with the agent doing the work. The specification defines clear acceptance criteria and boundaries, then stops before prescribing the code line by line.
Review the design independently
The planning model does not approve its own specification. It sends the plan to a different frontier model before my review.
If Fable develops the design in Claude Code, Sol or Astra can review it. A plan written by Sol can go to an Opus or Fable critic. The exact pairing changes. Every reviewer receives the original request, project constraints, and proposed plan without inheriting the planning conversation. This workflow for sure increases the token usage but reduces the iteration cost of fixing errors later based on my experience.
The critic looks for missing requirements, unresolved decisions, unnecessary scope, weak acceptance criteria, and assumptions that do not match the repository. It should explain why a concern matters and what needs to change. The planning agent then revises the specification, and the critic reviews the new version.
This resembles the configurable loop and critic idea in Ralph from oh-my-claudecode, which can send completion review through an architect, a critic, or a Codex critic. I took the separation between author and critic and applied it earlier, while the specification is still cheap to change. My workflow otherwise has its own scope and approval points.
Approve the specification before execution
After the critic provides feedback or approval, I read the specification myself. I focus on the outcome, the decisions that affect behavior, the stated risks, and the evidence required for completion.
This review is easier than discovering intent from a finished diff. The open questions are visible, and changing the plan does not require undoing an implementation. If the document still leaves a decision implicit, I send it back for another planning pass.
Once approved, the specification becomes the working agreement for execution. It gives the implementation agent enough context to make local decisions and gives reviewers a stable definition of done.
Delegate against the approved plan
The implementation agent works from the reviewed specification and stays within its boundaries. Larger changes can be divided into ordered pieces, but each piece needs clear ownership and a way to verify it. Parallel work is useful only when the parts can proceed without several agents rewriting the same files or making conflicting interface decisions.
During execution, the specification remains the reference point. New information may require an amendment, especially when the repository contradicts an assumption in the plan. That change should be explicit. Quietly changing the intended outcome halfway through makes the final evidence difficult to interpret.
After implementation, I use independent model reviews and a structured code-quality check to challenge the complete change. I describe that process in Reviewing AI-generated code with multiple models.
Decide how much final review the change needs
The last step depends on risk. For a contained frontend change, I may accept the result from passing ci-local, focused tests, the production build, static checks, and completed independent reviews. I still read the summary and confirm that the evidence covers the approved specification.
Backend changes receive more direct attention when they affect stored data, permissions, shared contracts, migrations, or a critical path. I read the full revised diff, inspect the relevant tests, and trace the behavior that could cause a difficult rollback or an operational failure. Automated evidence narrows that review to the decisions and failure modes that matter.
The process gives me two useful checkpoints. I approve the specification before code is written, then choose the final review depth from the risk of the finished change. The agents develop and challenge the details between those decisions, while the tests and validation record show what was actually checked.