My AI coding assistant fixed every bug I gave it. It never once asked the question I didn’t know I needed to ask.
I built CheCeno because deciding what to eat shouldn’t take five minutes of mental energy every single day — for me, or for anyone. Mood, what’s in the fridge, cook or order: CheCeno decides in seconds instead of you scrolling through the same six recipes you always scroll through.
I built it solo, with an AI coding assistant as my technical partner — auth, payments, an affiliate system, a real admin dashboard tracking actual usage. Technically, it worked. Almost every bug got fixed fast.
What I didn’t get right at first was the story I told about it. I pitched it as “an app that tells you what to cook” — and a free chatbot already does that in ten seconds. Took me a while, and a lot of quiet months, to realize the problem wasn’t the product. It was a question I didn’t know I needed to ask: not “does this work,” but “does this need to exist as its own app.” Nobody raised it — not me, not the AI I built it with — because you can’t ask a question you don’t know is missing.
That gap — the AI executing the task instead of questioning it, and me not knowing what I didn’t know — is what I’m building on next. If you’re curious or stuck on something similar, I’m testing it by hand on real cases right now.
This is a brilliant reframe. You didn't build the wrong product — you told the wrong story. 'Decides in seconds' vs 'tells you what to cook' is the difference between a vitamin and a painkiller. What story are you testing now?
Ai without guard rails and a expert edtior will just make slop
This is probably the biggest limitation I notice with AI coding too. It’s excellent at solving the problem you give it, but not always at noticing that you might be solving the wrong problem 😅
Yeah, that’s the whole gap in one line.
This hits close to home. I'm building something right now and the AI lets you move so fast that you ship before you've properly asked whether anyone will use it. The code compiles, the deploy works, and then... silence. You realise the question was never 'can I build this' — it was 'does this solve a problem someone actually has.' The hardest part isn't the building anymore. It's figuring out whether what you built deserves to exist as its own thing, or whether you just built a wrapper around something a chatbot already does. I'm still figuring that out myself.
Same boat — still figuring out where the line is between “wrapper around a chatbot” and “actually its own thing.” No clean answer yet.
This is a good way to describe the limits of any tool that only responds to what you ask it — technical or financial. The real value often isn’t in answering your question, it’s in someone (or something) asking you the question you didn’t know to ask. Curious what that missing question ended up being for you.
I think your “second opinion” and something I’m building sit on opposite sides of a useful boundary.
You ask the earlier question:
Are we solving the right problem, and should this exist at all?
System Claim Check asks the later one:
Once a concrete claim has been made, what does the evidence actually support?
Your article contains a good example of why both are needed. You write that the problem was not the product, but the story told about it.
That is plausible, but it is also a new claim.
Quiet months establish that CheCeno did not gain traction. A free chatbot producing meal suggestions in ten seconds establishes that a substitute exists. Neither result, by itself, establishes that the product was right and positioning was the cause.
To test that conclusion, I would separate it into smaller claims:
CheCeno reduces decision time compared with the user’s current behaviour.
Users return because the decision is meaningfully easier, not merely because the app is novel.
“Decides in seconds” produces stronger activation than “tells you what to cook.”
The dedicated workflow provides value that users do not obtain from a general chatbot.
Each claim requires different evidence. A copy experiment could test positioning. Repeated usage could test recurring value. A direct comparison could test substitution. None can stand in for the others.
I’m developing System Claim Check as an independent method for turning one system claim into a bounded evidence test and a documented verdict: confirmed, falsified, partially confirmed or not evaluable.
I would be interested in applying a free pilot check to one CheCeno claim while your second-opinion process questions whether it is the right claim to test. That would show whether the two methods are competing approaches or complementary stages of the same decision.
The "friction as pause" insight from this thread is the sharpest point in here, and I think there's a layer underneath it.
When you were coding slowly, you weren't just second-guessing the code. You were imagining the user, because you had to: you needed to picture how someone would actually use the thing to decide what to build next. That loop pulled you outside your own frame regularly, as a side effect of the process itself.
AI-assisted building is fast enough that you never have to leave your own head. You stay in your frame the whole way through. Which is probably why "does this need to exist as an app" never gets asked: not because it's hard, but because the speed means you never had to inhabit a stranger's perspective long enough to generate the question.
The "why-checker" idea JolinHan raised in the thread isn't just nice to have now. It's filling a structural gap that used to be filled accidentally by slowness.
What finally made the question visible for you: a specific conversation with someone, or just enough quiet time passing?
Good distinction, and I think you’re right about the mechanism — slow coding forced you to sit with the user in your head, AI-assisted building doesn’t. To your question: mostly quiet time passing plus one blunt comment on this thread, not a single flash of insight.
This is the most honest thing I’ve read on here this week. We’re all so focused on ‘does it compile’ that we forget ‘does it deserve to exist.’
The fact that you’re now testing the question-asking layer by hand on real cases is fascinating. Are you essentially building a second AI that challenges the first one’s output? Or is this more of a human-in-the-loop filter before you productize it? Either way, I’d follow that thread—it sounds like you’re not building CheCeno anymore, you’re building a ‘why-checker’ for builders.
Why-checker for builders” is a better name than anything I’d come up with myself.
Neither exactly — not two AIs auto-checking each other, not quite human-in-the-loop either. Somewhere in between, still manual. And yeah, it’s drifted past CheCeno at this point — that’s just the example that made the gap visible.
this is the thing nobody talks about with AI-assisted building. the tool optimises for the task you gave it, not the task you should've given it. I've had the same experience — shipped something technically solid, then realised the product question was wrong the whole time. the hard skill isn't getting AI to write code, it's knowing what code to ask for.
“Knowing what code to ask for” is exactly right, and it’s the part that doesn’t show up in any benchmark — you can’t measure it the way you measure whether the code runs. Same story here: technically solid, wrong question underneath it the whole time. The annoying part is you usually can’t tell from inside the build — it takes someone or something outside the momentum to catch it.
yeah this is the thing. AI will build whatever you tell it to, at full speed, whether or not it's the right call. before, having to actually sit down and code something slow enough that you'd second-guess yourself halfway through. now you just don't, because it's done in 10 minutes and on to the next thing.
asking the right question was always the hard part. it just used to be hidden behind the hard part of writing the code.
This is a sharper version of the point than I’d landed on, actually. It’s not just that friction disappeared — the slowness of writing code by hand was doing double duty, it cost you time and it gave you a free pause to second-guess yourself while you were stuck typing something out. AI removed the cost and quietly took the pause with it, and nobody budgeted for losing that second thing because nobody realized it was a side effect rather than the point.
I’ve made something similar but harnessing it to a structured output and not trying to let it do too much is helpful. As deterministic as possible.
The vitamin vs painkiller framing in the comments nails it. Deciding what to eat isn't a fun problem, its a tired one, so the app has to feel like relief not another decision to make.
The missing question rarely comes from tools, it comes from watching ten people try to solve the problem without your app. If a free chatbot already covers the job, the wedge has to be distribution or context, not features. I review a lot of early-stage decks and "works technically, unclear why it must exist" is the most common failure mode I see.
Really insightful reflection. The gap between 'does it work' and 'does it need to exist as its own app' is something I've struggled with too. I'm building GoldBean API — a pay-per-call AI API marketplace — and the same question haunted me early on: why would someone use this instead of going direct to OpenAI? The answer was pricing transparency and multi-provider access in one endpoint. But it took months of talking to developers before that clicked. Your point about AI not asking the missing question is spot on — AI executes, it doesn't strategize.
Really insightful reflection. The gap between 'does it work' and 'does it need to exist as its own app' is something I've struggled with too. I'm building GoldBean API — a pay-per-call AI API marketplace — and the same question haunted me early on: why would someone use this instead of going direct to OpenAI? The answer was pricing transparency and multi-provider access in one endpoint. But it took months of talking to developers before that clicked. Your point about AI not asking the missing question is spot on — AI executes, it doesn't strategize.
This is a really interesting point. AI is getting very good at executing tasks, but knowing which questions to ask before executing them is a completely different challenge. That “unknown unknowns” gap is something more builders should think about.
I wish u good luck
This resonates. I work in AI governance, and the failure you're describing has a structural name: current assistants are answer-entitled — they treat every prompt as something to satisfy, never as something to challenge. "Fix this bug" is a well-posed task; "should this exist as its own app" is ill-posed, and the systems are biased toward the first by construction. You genuinely cannot ask a question you don't know is missing — and neither can a tool optimized to complete YOUR frame.
One thing that has worked for me, crude as it is: role separation. Before any build session, I run a separate session whose only job is to attack the premise — it gets no access to the plan's momentum, just the one-paragraph pitch, and it has explicit permission to conclude "don't build this." The builder session starts only after the premise survives. It doesn't guarantee the missing question gets asked, but it creates a slot where that question is someone's actual job.
Curious about your next project: are you building a tool that interrogates premises, or more of a practice/checklist? The "execution got cheap, friction disappeared" point from the comment above is real — the stop-and-think has to be reinstalled somewhere deliberately.
“Answer-entitled” is a good name for it.
Still a practice, not a shipped tool, and yeah — close to what you’re describing. Mine’s a variation on the same idea. Curious to see where you take yours.
The last part is very true. ~
While AI can be very good at solving the problems you give it, it is completely oblivious to the question of whether that problem is worth solving.
Sometimes the hardest part is realizing the missing question only after you’ve already spent weeks trying to build.
In my opinion, building with AI has one of the stranger parts. It eases execution therefore the amount of friction that used to make you stop and think disappears too.
I am curious to know whether this changed what you build next. (?)
Not yet in a concrete sense — no new project has come out of it directly. What’s changed is more upstream: I now default to asking a wider question before starting anything, instead of trusting my own first framing. Whether that shows up as a specific “next thing” is still open.
Congrats on shipping this! Getting from an idea to something people can actually use is already a big achievement. What kind of early users are you hoping to attract first?
Thanks! Honestly still figuring that out in real time — right now the people who’ve responded most (including a few from this thread) are other solo builders who recognize the “shipped something, didn’t think hard enough about who’s actually stuck on this problem” pattern. Longer term I think it’s less a demographic and more a behavior: people who already default to “cook or order” indecision several times a week, not occasional cooks looking for recipe inspiration.
The “cook or order” split is what makes CheCeno more interesting than just another recipe picker. It feels like it could be pulling in a lot more organic traffic than it probably is right now, especially now that you’ve sharpened the actual problem beyond “what should I cook?” Have you found one kind of decision where people seem to instantly get why it exists?
Good question, and honest answer: I don’t have real usage data to back this up yet, so take it as a hypothesis, not a finding. My best guess is the “already home, too tired to decide, fridge has random stuff” moment — that’s specifically what it’s built for, versus “I want to cook something nice this weekend,” where a recipe site or Pinterest still wins. Haven’t validated that split with actual users yet, it’s just what the design assumes.
Now that you’ve narrowed the positioning to that “already home, too tired to decide” moment, I’d seriously consider adding media placements alongside your organic strategy.
I can help increase organic traffic by getting CheCeno featured in relevant publications and building a stronger “Featured In” footprint around this specific problem. The goal isn’t just a launch spike — it’s to build long-term visibility, authority, brand awareness, and bring more relevant people into the product so you can finally validate that hypothesis with real usage data.
I’ve done this kind of work before and already have some ideas for CheCeno specifically. If you want to explore it, feel free to reach out to me at mumar@growwithmumar.online.
I'd push back gently on the correctness/worth split further up the thread, or at least on where the line sits.
A bug only has a ground truth if somebody decided what was supposed to happen. Most of what actually reaches real users isn't a failure against a spec, it's a case nobody ever ruled on. What should the checkout show when the quantity field is left empty? What happens when someone types a comma decimal because their keyboard is German, or pastes an emoji into a postcode box? There's no failing test, because no one framed the question. The assistant doesn't raise it for exactly the reason it never asked whether the app should exist: both are questions about unstated intent, not about correctness.
So I don't think they're two different kinds of problem. It's the same blind spot at two scales. The author can't see the questions they never framed, and the model inherits that blindness from the author, because everything it knows about the intent came from them in the first place.
Which is why the fix has the same shape at both scales: someone who wasn't in the room looks at it. A stranger asks why this is an app, and a stranger types nonsense into your form. Both find things no amount of self-review would ever have surfaced. Cheap, and weirdly hard to make yourself actually do.
That’s a real challenge, not just a restatement, and I think you’re half right in a way that actually sharpens the original claim rather than collapsing it.
You’re right that most real bugs aren’t violations of a stated spec — they’re unruled cases, and in that sense the blind spot is the same one: unstated intent, inherited by whoever (or whatever) builds the thing. That’s a better account than “correctness has ground truth” gave it credit for.
Where I’d push back is on “the fix has the same shape.” The German decimal comma lives in a bounded, enumerable space — you can fuzz it, a machine can generate weird inputs faster than any stranger can type them. “Should this exist” doesn’t live in a bounded space at all; no amount of input generation touches it, because it’s not a coverage problem, it’s a judgment about worth to people who don’t exist yet in your test data. Same blindness at the root, but only one of the two scales can be automated away. The other one specifically requires a mind, not just noise.
Conceding the first half: you're right that the two scales differ in how automatable they are, and I was too neat in saying the fix has the same shape.
But I don't think the input side gets automated away either, and the reason is the thing that surprised me most once I started doing this deliberately: fuzzing solves generation, and generation was never the bottleneck. The bottleneck is the oracle - knowing that the output is wrong.
A fuzzer types 1e400 into your price field, gets HTTP 200, and moves on happy. It has no idea the total now reads £Infinity, because nobody told it what the total was supposed to say. It finds crashes, because a crash is self-labelling. It does not find wrongness. And most of the input bugs that reach real users aren't crashes at all - they're a screen rendering something absurd under a perfectly healthy status code.
The space is also less enumerable than it looks. "Empty quantity field" is bounded. "Empty quantity field, after a back-navigation, keyboard set to German, session resumed from background" isn't - that's a product, not a set, and it explodes. That combinatorial space is where the bugs actually live, and it's why fuzzers plateau early on real apps instead of sweeping the field.
So where I'd land: machines are excellent at generating inputs and poor at judging outputs. "Requires a mind, not just noise" is absolutely true of your scale, and more true of mine than people expect. The difference between them is real, but it's a gradient rather than a line.
Which is a conveniently self-serving conclusion from someone who decided to pay humans rather than write a fuzzer. Make of that what you will.
Fair point, and I’ll take it — a fuzzer finding a crash is different from a fuzzer finding “£Infinity” on a screen that returned 200 OK. One is self-labelling, the other isn’t. You’re right about that.
Where I’d disagree: you’re assuming “judging whether the output makes sense” has to be a human job. I don’t think it does anymore. Asking an AI “does this price look sane, or broken?” is cheap and scales fine — that’s a judgment call, not input generation, but it doesn’t need a person to make it. So the part of your argument that needs “a mind” still gets automated, just through a different tool than a fuzzer.
And fair play for naming your own bias before I could — that’s why I don’t read this as you just defending your business. I’ve got the same one, the other way.
Hey Imris
I've figured few important things & marketing strategies for this App.
I'll be mentioning one of them that is having a marketing page.
Marketing Page is a simple Landing page that tells visitors why this should install the App. It's currently missing, It's enforcing user to start with login.
There are other things, I got that I wanted to share. What's the best way to reach out to you?
Appreciate you digging into it — the missing marketing page / forced login is a real gap, not something I’d push back on. hello@checeno.app, happy to hear the rest there.
I’ll drop you an email shortly with the other things I noticed + a few ideas around positioning and getting the first users.
this is why knowing how to code is still very important if you wanna go far in this industry as Ai wont tell you often espacially on complex tasks this is better this is worse you learn that after years of experiecne
Partly agree, but I’d separate two different things. A good model, asked directly “which of these two approaches is better and why,” often gives a solid answer — that’s judgment it can access if you prompt for it. What it won’t do on its own is flag that you’re solving the wrong problem in the first place, because that requires questioning the premise, not just evaluating the options you already handed it. Experience helps with both, but I think the second one is the harder gap to close — even for senior engineers, not just AI.
Sounds like a dream assistant.
Ha — “dream” is probably the right word for where it’s at right now. It’s not built yet — I’m running the idea as an AI simulation on real cases before turning it into an actual product. If you’ve got something you’re stuck on, happy to run it through the simulation and see if it holds up outside my own head.
The “does this need to exist as its own app?” question is the interesting part. It’s easy to optimize something that works without stopping to question whether the underlying problem is actually worth solving. That seems like a much harder failure mode for AI to catch.
That’s the sharper way to put it, and I think it’s right: a bug has a ground truth you can check against. “Is this worth solving” doesn’t — there’s no test that passes or fails. That’s probably why it’s such a durable blind spot. You can build all the verification you want around correctness and never touch the harder question, because verifying correctness and judging worth are just different kinds of problems, not degrees of the same one.
Ended up writing more about this exact distinction — free PDF here if you want to go deeper: https://github.com/simro89/the-second-opinion/releases/download/1.0/THE.SECOND.OPINION.pdf
That distinction between correctness and worth is a useful one. I’d be interested in continuing the conversation beyond the thread — what’s the best email to reach you at?
Good question to take offline. hello@checeno.app — happy to keep going there.
Thanks! I’ve just sent it over.
Looking forward to hearing your thoughts whenever you have a chance.
I also did what you mentioned, and I'm still trying to fix my mistake. It's quite hard finding people who'd validate your idea.
That’s the hard part, yeah — and I don’t think it’s just you being bad at networking, it’s a real structural gap. For what it’s worth, this thread itself has been the closest thing I’ve found to actual validation: strangers with no stake in my idea, pushing back for free, because the platform makes that normal. Slower than having a dedicated person, but real.