A coding agent can produce a working screen before the team has decided how the product will reach users or who will maintain it. I prefer to settle those questions before asking it to build.
The useful starting point is one action the first user needs to complete. For example, a content editor needs to publish a page without opening a developer ticket. That is an illustrative test, not a claim about a client project.
Write down the first user and the workflow
Describe the user, their starting point and the result they need. Keep the first test small enough that someone can actually try it. A list of features is useful later, but it does not replace a workflow that can be checked.
The question is: can this person complete the important action under the conditions the product will face?
Check how the product gets out
For an app, decide how you will distribute a release, who owns the store account and how updates will work.
For a content site, decide who edits the content and how you will check that the page can be found through search.
For a business system, identify where the data lives, who can access it and how you will recover from a failure.
These are questions to investigate. The answers depend on the product and the tools you choose. A convincing demo does not settle them.
Keep a short decision record
An architecture decision record gives the team a small place to record the context, the choice and its consequences. I also like to write down the alternatives and what would make us revisit the choice.
A starting template:
- The problem and the first user.
- Constraints: distribution, permissions, maintenance and budget.
- Two reasonable alternatives to test.
- The choice and the reason for it.
- An experiment that proves the important action is possible.
- The person responsible once the experiment works.
The record can stay short. Its job is to keep the decision visible when the code starts moving quickly.
Give the agent a bounded first task
An illustrative prompt:
Before writing code, show two implementation paths that fit these constraints. For each path, explain what we would need to operate and what is still unknown. Then propose a small experiment that tests the main risk.
After choosing a path, ask for the first workflow only.
If deployment is the risk, the experiment needs to include deployment. If content editing is the risk, ask a real editor to try it. The test should address the thing that could make the product fail after the demo.
This is how I separate the product decision from writing code: agree on the user, the limits and the test, then let the agent help build the smallest useful experiment.
This is an English adaptation of my original Hebrew guide. Professional background and selected work.
Top comments (0)