# AI Always Says Yes. That’s the Problem. Author: Chris Adolphus Published: 2026-03-26 Canonical page: https://www.chrisadolphus.com/blog/ai-always-says-yes-thats-the-problem/ Why AI validation is not enough, and how to pressure-test ideas before committing to build them. I’ve been having the same conversation repeatedly, in different forms, with different people. A friend in design thinks about an idea on a Tuesday. By Thursday, they’ve shipped a prototype. By the following week, they’re wondering why nobody’s using it. A friend in engineering has an insight about an automation. They sketch it in a system prompt. They build it in a weekend. The code is clean. The logic is sound. The market doesn’t care. A friend in growth gets consumed by a disruptive idea, starts building with AI coding agents, buys a domain, and gets blocked by a compliance issue and a dependency they didn’t see coming. I don’t say this to dismiss them. These are talented, smart people. What they’re doing, shipping fast with AI, is genuinely impressive. But there’s a layer of the process they’re skipping, and nobody has told them it exists. ## AI is a brilliant liar Here’s the thing nobody talks about enough: AI will almost always tell you your idea is great. Ask Claude, GPT, Gemini, any of them, whether you should build your idea, and you will get a considered, structured, optimistic response affirming your instinct. You will get a list of reasons it makes sense. You will feel validated. This is the most dangerous feature of every AI assistant on the market. > AI doesn’t know what it doesn’t know about your market. And it will never tell you what you haven’t asked. It’s not that the AI is wrong, exactly. It’s that it’s answering the question you asked, “is this a good idea?”, instead of the ten questions you didn’t ask. And those are exactly the questions that determine whether an idea becomes a product, or becomes a lesson. ## The questions engineers and designers skip I was on a call recently with two friends. I walked them through something I’d built, not just the end result, but how I got there. The gulf between my starting point and what I shipped surprised them. Not because the output was dramatically different, but because of how much work had happened underground, before a single line of code. That work looked like this: - **Policy layer:** What are the rules of the environment this will live in? - **Compliance and legal:** What is not allowed, and who owns the liability? - **Market:** Does this problem actually exist at scale, or just for me? - **Domain:** Is this solving a symptom or the root cause? - **Customer:** Would a real person pay for this? - **Technology feasibility:** Is the thing I’m imagining actually buildable right now, with the technology I want to adopt? - **Performance at scale:** Does this break when it works? - **Dependencies and cost:** Is there an API, service, or tool this relies on? If so, can I actually afford it at the usage level that makes the idea viable? - **POC vs MVP:** Am I proving something or delivering something? - **Priority order:** If I can’t deliver everything, what matters most and why? - **Phased implementation:** What version of this can I actually ship, and what should I learn from it? None of these questions are glamorous. None of them produce a demo. None of them feel like progress in the way that shipping code does. But they are the difference between building a product and getting stuck halfway through one. ## The best ideas are the ones you kill *I have killed 99.99999% of ideas I’ve ever come up with.* When I tell people this, they assume it means I’m unusually critical, or that I have some high creative bar, or that I’m unlucky. None of that is true. It means the stack works. Every layer of questioning is a filter. Most ideas fail the first filter, policy, legal, or market. Some survive three or four layers before dying on the dependency question. Yes, this works, but the third-party service it relies on would cost more than the revenue it generates at any realistic usage level. Or you need special partner access just to use the API at all. Dead idea. Next. The ones that make it through all the layers? Those get built. And they have a fundamentally different probability of success, because they’ve been pressure-tested from every angle before a single resource was committed. > Speed without a kill mechanism isn’t velocity. It’s expensive iteration on ideas that should have been stopped earlier. The engineer or designer shipping with AI hasn’t removed the need for this process. They’ve just removed the bottleneck that used to force the conversation, which was the time it took to actually build something. When building was slow, you naturally asked harder questions before starting. When building is instant, nothing makes you stop and ask them. Nothing, that is, except the instinct to do so. ## The gap shows up at the seams What I noticed with my friends wasn’t that they were doing something wrong. It’s that they were doing something incomplete. The ideas they shipped were real. The logic was sound. But they’d entered the build phase without going through a validation phase, because they didn’t know there was supposed to be one. AI had been an enthusiastic co-conspirator at every step. It helped them name the idea. It helped them spec it. It helped them write the code. What it never did, because nobody asked it to, was kill the idea before it was late. ## Run the pressure test yourself One last thing worth mentioning: I ran this framework on itself. My first instinct was to build this as a product. A proper idea validation tool, clean UI, guided flow, the works. The pressure test killed that version quickly. The dependency costs were significant, and most importantly, the core value, which is the prompts and the questions, didn’t need a product wrapper to be useful. What survived the stack was this: a Medium article explaining the thinking, and a free prompt library anyone can use today. No infrastructure. No subscription. No build phase. The fastest path from insight to value. That’s the framework working exactly as it should. The idea didn’t die. It got better. The 12-layer framework described in this article is available as a free prompt library on GitHub. Each layer is a structured prompt you can run with any AI assistant, designed to challenge your idea, not validate it. It includes the full prompt for every layer, a quick-kill triage template that filters most bad ideas, a scorecard for comparing multiple ideas, worked examples across different product categories, and industry addenda for fintech and health-tech. [***Pressure Test: github.com/[your-handle]/pm-pressure-test***](https://github.com/chrisadolphus/pressure-test)