From code-only to idea-to-product: the three agents I added before the code

What the flow looks like now

One router looks at each task and decides what kind it is. For a new idea, it turns on discovery and design. For a feature on existing code, it skips discovery and only uses design if the feature changes the UI. If it can't tell whether something is a new idea, it asks me.

For a new idea, the order is:

The three new agents are discovery, research verify and the designer. Everything from the planner down is the loop I already had.

Discovery, and how it labels what it finds

Discovery is one agent with three skills. The first looks at the market and the competitors. The second does desk research on users, reading Reddit, Quora and the wider web for what people say about the problem. The third audits the look of comparable products and drafts a colour palette.

Every claim it writes is tagged as sourced, inferred or a hypothesis. That tagging matters most for the user research. Reading what people post online is useful, but it isn't the same as talking to users. So the desk research is always labelled as hypotheses, and never written up as if it came from interviews.

Discovery runs on Qwen 3.8 Max in Pi.

A second model checks the facts

Research verify reads what discovery wrote and checks it. Do the links resolve? Are prices dated? Is every claim tagged? It runs on GLM 5.3, which is a different model family from discovery's.

I use that rule across the whole loop. The planner runs on Claude Opus 5.5 and the challenger on Qwen. Discovery runs on Qwen and verify on GLM. When the same model checks its own work, it tends to agree with itself.

If verify finds a problem, it fails loudly and stops. It doesn't send the work back for another round on its own. I'd rather see a clear failure than pay for a loop that goes round and round.

The Go/No-Go gate

After verify, I decide whether the idea is worth planning. This is a human stop, and it sits before any money goes on planning. A no-go ends the idea there.

I think this is the most useful gate in the flow. Planning is where my spend goes, and the cheapest time to drop a weak idea is before it has a plan.

Design comes after the plan and before the code

The designer runs once I've approved the plan, and before any code is written. It produces a design doc, the user flows, a locked palette for the product, and the screens.

The palette is for that product. Discovery's draft palette feeds in, and the designer locks it. I didn't want one house palette forced onto every product the loop builds.

Each run, the loop asks me which design mode to use:

• Vanilla HTML, using Kimi K3 in Pi. This is the cheap option.
• Claude Design, using Claude Sonnet 5.5 in Claude Code.

Figma comes later. I ask per run because the right choice depends on the idea. A rough test of a market doesn't need the same design spend as something I expect to show to customers.

If I reject a design, it goes back to the designer, or back to a re-plan if the problem is really in the plan. After three rejected attempts the work parks and waits for me.

Why the designer and UI QA use the same model

This is the one place where I broke my own rule about model families.

The designer and UI QA both run on Kimi K3. I did that on purpose. The executor, which is a different model, builds the UI. Then UI QA compares the build against the design. I want that check done by the model that made the design, because it holds the intent behind it. It knows why each screen looks the way it does.

The model families still differ where it counts. One model designs, another builds, and the designing model judges the build. The check that matters is between the builder and the design, and those are different models.

There was also a practical trigger. My earlier UI QA model, DeepSeek, did badly on a vision test. I needed a new model for UI QA anyway, and this was the setup that made sense.

The gates, the cap and auto-approve

There are four human gates: Go/No-Go, plan approval, design approval and final approval. For speed, an auto-approve flag can pass the first three for me. The final gate is always a person. It is never auto-approved.

There's also a spend cap on every run, enforced by the loop, so a run stops instead of running past it.

A note on cleanup

Adding three agents had a side effect. When I reviewed the repo afterwards, the docs had drifted from the code. Some skill links didn't resolve inside the repo. I fixed them so every skill link resolves inside the repo, and added a CI check so they stay that way.

What I haven't proven yet

I want to be clear about where this stands. The coding loop has run on real client work. The idea-to-product flow hasn't run end to end on a real idea yet. I've built the agents, the gates and the routing, but I don't have results to show you.

I don't know yet whether discovery's desk research turns up anything a founder wouldn't find in an afternoon. I don't know whether the Go/No-Go gate will save money in practice, or just feel like it should. And I don't know how well Kimi K3 holds a design's intent across a real build.

The next step is to take one real idea through the whole flow and write up what happened, including what broke.

What to take from this

If your AI setup starts at the code, think about adding steps before it. Find out who has the problem and who already sells a fix. Have a different model check those facts. Put a human decision in before you spend on a plan. Design the product before anyone builds it, and check the build against that design.

You can do most of that with whatever tools you already use. The order and the human stops are what I'd copy first.

If you're building products with agents, I'd like to compare notes. Where does your setup start, and what do you check before any code gets written? If you'd rather talk it through, you can book a discovery call or email hello@pgamila.com.