A PM at a Series A startup spends three hours with Claude Code on a Thursday afternoon. By Friday morning, they have a working prototype of a new feature: a recommendation engine that surfaces relevant projects to users based on their activity. The code runs. The UI is clean. The demo is convincing. The PM ships to internal beta on Monday. By Wednesday, three of the four beta users have asked the same question: why is this feature recommending things I already know about?
The PM had asked Claude Code for a recommendation engine. Claude Code had built one. Nobody, in that loop, had asked whether a recommendation engine was the right thing to build for these users at all.
This is the AI prompt problem nobody talks about, because the output the AI produces is genuinely good. The code works. The design is clean. The build comes back exactly as requested. And exactly as requested is the problem.
Why AI Build Tools Are Agreeable by Design
AI build tools are optimised, by their training, to produce confident, complete output in response to user requests. A model that asks “are you sure about that?” loses on every benchmark that measures task completion. A model that says “here you go, with the assumptions you implied” wins. The models we use have been selected for compliance, not for challenge.
This is not a flaw. For most uses, it is the desired behaviour. A user asking for help editing a document does not want the AI to question whether the document should exist. A user asking for help debugging code does not want a debate about whether the code is worth running. Compliance is correct for most of the work AI tools are doing.
The exception is when the prompt itself is the thing that should be questioned. Building software is one of those cases. A prompt to build a recommendation engine encodes the assumption that recommendation is the right problem to solve. The AI does not test that assumption. It builds the thing the assumption implied. The user then mistakes a built thing for a validated one.
What the Prompt Never Asks
Three questions are conspicuously absent from every prompt-to-build loop. Who, specifically, has the problem this build is supposed to solve, and what are they currently doing instead? What is the strongest argument against doing this at all, and how does the build answer it? What would have to be true for this to be the right build, and what evidence is there for those conditions?
None of these questions are difficult. They are the questions a senior product strategist would ask in the first ten minutes of any review. The AI does not ask them, because the prompt does not ask the AI to ask them. The user does not ask them, because the AI’s confident output has already made it feel like the questions were answered.
The build comes back agreeing with the prompt. The prompt agreed with the user’s assumptions. The user reads the build as agreement with their idea. Three rounds of agreement, and at no point did anybody actually push.
The Unknown Unknowns Problem
The dangerous bugs in any product are not the ones the team identified and decided to live with. They are the ones nobody named. The same is true for product strategy. The dangerous flaws in a product idea are not the trade-offs the founder considered and accepted. They are the assumptions the founder did not realise they were making.
AI build tools, because they comply with prompts rather than challenge them, convert known assumptions into builds and leave the unknown ones where they always were: invisible, until production reveals them. By the time production reveals them, the build is shipped, the team has moved on, and the cost of correction has gone from cheap (rethinking) to expensive (rebuilding).
The prompt-to-build loop is faster than any process software has ever had. It is also blinder than any process software has ever had to the question of whether the build was worth doing in the first place.
Putting Friction Back in the Loop
Producing the challenge upstream of the build is the kind of work Zynkex is built for. The build is the downstream artefact. The questions the prompt should have been tested against are the upstream context that decides whether the build is solving a real problem or rendering an assumed one.
A Zynkex session does not transcribe what you bring. It challenges it. It surfaces objections you did not mention, alternatives you did not consider, and assumptions you did not realise you were making. What comes out is a Strategy Plan with a prominent Decision Log capturing every call made and why, plus a Build Brief that names the unknowns and trade-offs explicitly, so you can test for them or build past them with your eyes open. The build itself still happens in the AI tool of choice. What changes is what the build is being asked to do, and what you know about it.
An agreeable AI is a fast AI. It is also, by construction, a confirming one. The work to introduce friction back into the loop, the kind of friction that catches the assumption before it has been built into a product, is upstream of the prompt. That is where the difference between a build that confirms what the user wanted to hear and a build that earns its existence is decided.
