Developers solve business problems by shipping features. Agentic AI promises to make the feature-shipping part faster, but the speed comes with a hidden tax.
Every spec the agent reads gets pattern-matched against its training data, and those patterns rarely fit your specific business problem exactly. The mismatches contain assumptions and load-bearing decisions that don’t match your domain. If they get baked into code before you notice them, you’ve traded short-term speed for medium-term cleanup. The solution is to surface those mismatches before the agent writes a line of code.
This post is about how to do that. It’s seven checks I run before letting Claude write any code, and the discipline of separating design from implementation that make the checks worth doing.
These checks challenge the concept that the “last 20% takes 80% of the time”, by front loading the time consuming part to build your context accurately and make the code reviewing less painful.
The seven checks
The pattern across all seven is the same: ask the agent to articulate its understanding, read what it produces critically, and push back on anything that you don’t understand, or doesn’t match your mental model of the problem. Repeat until your mental model and the agent’s output have aligned.
1. Narrow the scope to a vertical slice you can verify
Give the agent the large Gherkin file (the spec that outlines all the details of the feature you are creating) — and ask the agent to find a thin slice that delivers something physically testable end-to-end. Not a horizontal layer (a database table, an API endpoint), but a vertical slice that goes from user action to data change and back.
Reject slices that are too large to verify in one sitting; reject slices that are too small to demonstrate the feature works end-to-end.
The artifact: a tightly-scoped slice you can hold in your head, with clear success criteria.
2. Map the user journey before the technology
Have the agent explain to you what the user can do after this feature that they couldn’t do before. Trace the journey: how do they reach the feature, what do they do once they’re there, where do they go afterward.
Ensure that the agent’s understanding aligns with your own, if this understanding is misaligned then any output will also be misaligned.
The artifact: a written user journey with entry and exit points named.
3. Surface the entities and their relationships
Have it list the entities the spec describes. List the entities that already exist in the database. Identify the relationships the spec implies between them.
Then check for conflicts. Are the spec’s relationships already enforced in the existing schema, or do they assume a structure that doesn’t exist yet? Are there cases where the spec contradicts existing constraints?
This is the step where the spec-versus-codebase gap gets articulated. The spec describes a world; the codebase implements a (possibly different) world. Step 3 is where which entities exist, which are new, and which need to be modified gets documented. Skipping this step is how the agent ends up writing code that assumes a schema you don’t have.
The artifact: an entity map with relationships marked as “exists,” “needs to be added,” or “in conflict.”
4. Define the contracts between front-end and back-end
What endpoints does this feature need? What’s the request shape, the response shape, the error cases? Which endpoints already exist and need to be modified, and which are new?
Get the agent to propose the contracts explicitly before any implementation. Read them as a critical reviewer would: are the response shapes consistent with the rest of the API? Do the error cases match how the rest of the codebase handles errors? Are there N+1 patterns lurking in the proposed shape?
The artifact: a list of endpoints with their contracts written out.
5. Annotate the mockup with component intent
Have the agent fetch the visual mockup, walk through it and identify three categories:
Generic components — patterns that appear multiple times in the mockup and could be implemented once as reusable components. The agent will sometimes propose duplicating these because they appear in different sections; that’s a pattern-match against per-section organization rather than a domain-grounded decision.
One-off components — patterns that are genuinely unique to this feature and don’t need to be generalized.
State management — your intuition about which state lives where. Component-local, shared, global, server-derived. The agent’s defaults here are particularly worth scrutinizing because state management patterns vary wildly across the training data.
The artifact: an annotated mockup with components categorized and state ownership decisions noted.
6. Chart the data flow end to end
How does data travel from the database to the user-facing component? Where does it enter the front-end (service layer, HTTP call), how is it passed between components, where does state mutation happen, and how does the change propagate back to the server?
Have the agent diagram this. The diagrams will often reveal places where the agent has proposed redundant calls, missed caching opportunities, or assumed a synchronous flow where the rest of the codebase is async.
The artifact: a data flow diagram you can verify against the actual proposed code.
7. Challenge the output, especially when it’s voluminous
Pass the spec, the mockup, and your prompts probing the six questions defined above to the agent and ask it to articulate its understanding of each check. Review the output, determine how the agents understanding compares to your visualization of the problem & solution. Ensure the design makes sense to you.
When you don’t understand something, ask. When you spot a load-bearing decision you didn’t make explicit yourself, ask why it was made. When the output is too dense to evaluate in prose, ask for a diagram or a table.
This is the step where you find the assumption mismatches. Every one you catch here saves an order of magnitude more time than catching it after the code is written. This is also where your skill as a senior engineer matters most — the agent may or may not catch its own mismatches, and the questions you ask are what surface them.
The artifact: a document of assumptions and load-bearing decisions, agreed to before implementation begins.
The payoff
Every assumption caught at the planning stage is an order of magnitude cheaper than catching it post-implementation. Every load-bearing decision made explicitly is one that can’t silently fail later.
These seven checks are the methodology in the abstract. In a follow-up post, I’ll apply them to a real feature — introducing a multi-user permission model to a side project that didn’t have one — and show where the agent’s first proposals were architecturally wrong, and how the checks surfaced the mismatches before any code was written.
Part 2, where I run this workflow end to end on a real slice, is here.