> ## Content Index > Fetch the complete content index at: https://www.mangocode.dev/llms.txt > Use this file to discover other available public pages before exploring further. # I do not ask AI if my idea is good, I ask it why it is bad. - URL: https://www.mangocode.dev/i-do-not-ask-ai-if-my-idea-is-good-i-ask-it-why-it-is-bad/ - Published: 2026-07-21T06:20:00.000Z - Updated: 2026-09-17T20:09:02.000Z - Description: Before building an AI feature, I asked DeepSeek to challenge my idea instead of praising it, using a method I am calling the Kill-This-Idea Prompt. It talked me out of part of the idea and handed me options I had not considered. - Author: Raoul Mangoensentono *I let DeepSeek attack my idea, then had Claude check DeepSeek's homework. It caught an outdated fact. It also caught something better: DeepSeek had argued against a different idea than the one I actually had.* --- **TL;DR:** Before building an AI feature, I asked DeepSeek to challenge my idea instead of praising it, using a method I am calling the Kill-This-Idea Prompt. It talked me out of part of the idea and handed me options I had not considered. Then I had Claude verify the critique, and found two things: one claim was built on an outdated fact, and the central objection was aimed at a different architecture than the one I had described. Correcting the direction killed two of DeepSeek's five objections and left the other two standing, plus a new one nobody had raised yet. The lesson is not "trust the AI." It is use the AI to spar, then check what it told you. This is the first entry in an experiment where I try to bake AI into how I actually work. --- I had an idea I liked, which is usually when I should be most careful. I was sketching an app where a user uploads a photo of a receipt and AI reads the line items and the total and drops them into a database. The kind of feature I get asked to build at Qualogy, where I work on Oracle APEX applications and REST services for enterprise clients. There is one annoying detail with any feature like this. Every scan costs money, because every scan burns tokens, and you pay for those tokens. So I had what felt like a clever thought. What if the user brings their own AI? I would build an MCP server exposing the upload capability, and the user connects that server to their own AI client, the same way you might connect Google Calendar to Claude so it can create events for you. Their AI reads the receipt and calls my tool to submit the data. The token cost sits on their subscription, not mine. Cost problem solved. I was fairly convinced. That is exactly why, before writing any code, I did something I have started doing on purpose. I asked an AI to tear the idea apart. ### Not "is this good," but "why is this bad" There is a difference between asking a model to validate an idea and asking it to attack one. If you ask "is this a good idea," you get a confident yes and a list of reasons you were right. That feels great and teaches you nothing. I find that models lean agreeable. Ask a soft question, get a soft answer. So I did not ask if it was good. I gave DeepSeek this, close to verbatim: > "As an expert architect and designer, verify and challenge my idea. I want to build an option into my application that uses AI, for example uploading a photo of a receipt where the AI reads the line items and total and loads them into a database. I pay for the tokens every time. I was thinking to move those costs to the user by creating an MCP so they can connect the MCP to their own AI and use that to upload the photo and data." It did not hold back. ### What came back DeepSeek laid out five objections. The two that hit hardest were about quality and business risk, not architecture. If a user brings their own cheap model and it misreads a receipt and duplicates fifty line items into their database, they do not blame their model, they blame my app. The moment I decouple my product from the AI cost, I also decouple it from the AI quality, and quality is the thing people actually pay for. Related to that: I would have no control over the prompt their AI runs against my system, which is a real trust problem if their client sends malformed or hostile data back. But the objection DeepSeek called the dealbreaker was different. It said MCP is built for local tool-to-agent communication only, that my cloud backend could never reach an MCP server sitting on a user's laptop, and that the whole idea was dead on that basis alone. It painted a picture of the user generating API keys, configuring a server, and running a terminal command just to scan a receipt, and concluded nobody would survive that setup. That objection is what actually changed my thinking in the moment. It also, it turns out, was not really an objection to my idea. ### Checking the homework, twice I handed DeepSeek's full response to Claude and asked it to verify the claims. I do not want to get stuck defaulting to one model, I would rather pit them against each other and see what survives contact. Two things came back. First, the small one: MCP has an official remote transport, Streamable HTTP, that supports standard HTTP authentication and is exactly how hosted MCP servers work today. "MCP can only talk locally" is not true as a general statement. That was true early on, but it is not true now. Second, the bigger one, and I only caught this because I read the correction carefully instead of just accepting "one fact was wrong." DeepSeek's dealbreaker assumed my cloud backend would need to reach *into* a local model running on the user's machine. But that is not what I described. My idea was the other direction: I host the MCP server, the user's own AI client connects *outward* to it, the same pattern as any third-party connector you'd add to Claude or ChatGPT. Once you correct the direction, the entire "networking nightmare" and most of the "terminal commands and API keys" objection stop applying. That is a completely normal, increasingly common setup. My own prompt was ambiguous enough that I cannot fully blame the model for reading it the other way, but the effect is the same either way: the most forceful argument against my idea was aimed at an idea I did not actually have. ### What survives the correction Here is the part that matters more than "gotcha, the AI was wrong." Correcting the architecture did not clear my idea. It just told me which objections were real. Dead once the direction is corrected: the networking dealbreaker, and most of the local-setup UX complaint. Still standing: the quality and trust problem. It does not matter which direction the connection points, the user's own AI is still the one reading the receipt, and I still cannot guarantee what it sends back or hold it to a consistent standard. That objection survives untouched. New objection: a problem neither DeepSeek nor Claude raised, one that only surfaced once I worked through the corrected version myself. If the user has to leave my app and go do the upload inside their own AI client to use the connector, that is not "upload a photo, done." That is a meaningfully different, more effortful product experience, just a different kind of friction than a terminal command. So the real decision is not "MCP good or bad." It is three options, each with a real cost. Eat the token cost myself and keep the experience simple. Go with the bring-your-own-key proxy DeepSeek suggested as its alternative, where the user pastes in an API key and my backend does the work with their key. Or build and host the MCP server properly, accept the engineering time that takes, and accept that some users will find the connector flow more effort than a simple upload. None of them are free. The question I actually have now is whether the engineering cost of any of the AI-hosted options is worth what it saves versus just paying for the tokens myself. I do not have that answer yet. It is not really the point of this article either. The exercise was never about which option I pick, it was about how much of DeepSeek's argument was actually mine to accept. ### The actual lesson If I had asked DeepSeek to validate my idea, it would have cheered me on. Asking it to attack the idea surfaced two real problems I had not considered. That part worked exactly as I hoped. But the argument that convinced me fastest, the dealbreaker, turned out to be arguing against the wrong architecture and resting on an outdated fact at the same time. I would not have caught either one without handing the answer to a second model and then reading the correction closely enough to notice the direction was flipped, not just the fact. Both things are true. The sparring was worth having. The claims still needed checking, carefully, not just once. That is the whole method: use the AI to spar, then check what it told you. This is the first real test of an experiment I am running, where I try to bake AI into my actual workflow, not as a novelty but as a genuine step before I build things. It earned its place. It also reminded me why I do not outsource the final call. ### How to run the Kill-This-Idea yourself Do not ask for a verdict, ask for an attack. Something close to what I sent DeepSeek: act as an expert, here is what I want to build and why, challenge it, find the flaws, tell me why it fails before I waste time on it. Then hand that answer to a different model and ask it to verify the claims. Then read the correction slowly enough to check whether it fixed a fact or whether it quietly fixed your entire premise. Those are different corrections, and only one of them is obvious at a glance. --- **Have you ever had an AI talk you out of something, and did you check whether it was right, or just relieved that it sounded right?**