If a feature has too many open questions to implement confidently, use AI to build a disposable prototype before committing to the production design.
For a small change, you can clarify the requirement and let the agent execute. A large feature often has uncertainty in the requirement, the architecture, and how the pieces will work together. Writing a detailed plan forces you to make decisions about a system you haven’t tried yet.
I’d delay that level of planning. Understand the problem, identify the important constraints, and develop some architectural opinions. Then prompt the feature into existence and use it to test those opinions.
The first implementation becomes an executable technical design document. Once you’ve learned from it, throw it away, record the decisions, and build the production system incrementally.
Build enough to test the design
You still need to do some thinking before launching the prototype.
Work through the major questions with the AI. Where should state live? How should the components interact? What existing systems need to be involved? Which decisions would be expensive to reverse?
Run targeted spikes where you need them. Give the prototype enough direction to test a plausible design.
Then have AI build an end-to-end version of the feature. For a user-facing feature, I’d want something clickable. You should be able to walk through the actual flows, including awkward states and edge cases.
This code can be rough. You may never review most of it. Its job is to make the design concrete enough that you can discover what you misunderstood.
A document can describe a workflow without exposing how awkward it feels. A prototype lets you try it. You can discover that an action requires information the user doesn’t have yet, that two components need to share state you expected to keep separate, or that an integration makes your proposed flow difficult.
Those discoveries give you something concrete to reason about.
Be deliberate about which assumptions the prototype actually tests. A mocked integration tells you little about whether the real integration will support your design. If that’s a major uncertainty, exercise it directly or run a separate spike.
Extract the lessons and discard the code
Once the prototype exists, spend time using it.
Walk through the important flows. Look for missing behavior, awkward boundaries, and decisions that became difficult to implement. Ask the AI where it had to work around your proposed architecture to get the feature running.
You’re trying to learn enough to make better production decisions. Keep track of what worked, what failed, and what you’d change.
Then discard the prototype implementation.
I’d make that decision before building it. Otherwise, once you have something working, there’s pressure to keep it. You start fixing a few things, adding tests, and telling yourself you’re almost ready to ship.
The problem is that the prototype contains decisions made to get an experiment running quickly. Some will be useful. Others will be accidents. Keeping the implementation creates pressure to preserve both.
Starting again lets you apply what you learned without carrying every shortcut forward. AI makes that a practical option worth considering, even for a substantial feature.
Record the decisions and build in slices
Now write the design that will guide the production implementation.
Capture the important decisions in an ADR or a short set of decision records. Explain the architecture you chose, the boundaries between components, and the rules the system needs to preserve. Include the alternatives you tried and why you rejected them.
That last part matters. An agent working on a later slice may see an apparently simpler approach and reintroduce something you already tested and discarded. Give it the reasoning it needs to understand the decision.
You now have architectural context grounded in an experiment. Use it to break the feature into smaller, cohesive slices.
For each slice, follow the small-feature workflow: clarify the goal and required proof, let AI implement and verify it, then return to judge the behavior and design. Have it prepare the change for peer review and maintain it through feedback.
The prototype lets you explore the feature broadly before committing to its structure. The production slices let you implement that structure with the verification and scrutiny each change needs.
When implementation becomes cheap enough to use as an experiment, we can learn from a working system before treating its design as settled. I’d use that opportunity deliberately, with the prototype’s disposal built into the plan.