I enjoy your craftmanship and your visual simplicity even when a program dedicated to someone directly. A good part in AI ages is the small development liberalization, a bad part is: for example this one.
Civic technologist building AI tools that help systems explain themselves. Clew Suite builder, NACM 2026 speaker. I write about hackathons, product judgment, agent readiness, and learning in public.
The detail about the plan carrying "one wrong guess all the way to the end" is the most valuable thing in this article, and most "AI built my app" posts conveniently skip it.
Every AI-coding demo shows the happy path: prompt → working app → wow. Nobody shows the part where the model's wrong assumption about your domain (e.g. "invoices are per cafe" vs "per delivery") gets baked into 15 files before you notice.
Curious: when you caught the wrong guess, was it because the app visibly broke, or because the output "looked right" but felt off? Asking because the second one is the scary case — silent correctness bugs are the ones that ship.
Civic technologist building AI tools that help systems explain themselves. Clew Suite builder, NACM 2026 speaker. I write about hackathons, product judgment, agent readiness, and learning in public.
This time it was during testing that I found the wrong assumed workflow. I was testing the invoicing on the different cafe's and I noticed that not all of them had the same items. One tiny detail that would have made the invoicing worthless. It stings to think of it this way but it's true. It was a very good lesson to learn.
"This one tiny detail would have made the invoicing worthless" is the perfect example of why testing on real data (or realistic data) beats testing on the happy path.
The AI doesn't know that "not all cafes have the same items" — that's domain knowledge that lives in your head, not in the training data. The only way to catch it is to actually use the app.
Curious if you've thought about how to make that knowledge explicit next time. A "domain constraints" section in the spec, or a checklist before testing?
Civic technologist building AI tools that help systems explain themselves. Clew Suite builder, NACM 2026 speaker. I write about hackathons, product judgment, agent readiness, and learning in public.
Great question. The more I've learned about spec driven development the more I realize that I don't know what I don't know. A domain constraints section could help in that regard for sure. One of the other DEV-ers @khunjua referred me to Open Spec. Their workflow has an explore step to map the problem before the proposal is written. I'm eager to see if that's a good way to uncover the constraints, too.
/opsx:explore map the problem and understand the codebase
/opsx:propose draft proposal.md, specs/, design.md, tasks.md
"The more I've learned about spec-driven development, the more I realize that I don't know what I don't know" is the most honest sentence in this thread.
That's exactly why the "explore" step matters. Most people skip it and go straight to "propose", which is why their specs miss the constraints that only show up when you actually read the code.
Curious how the explore step handles the "I already know this codebase" case. If you've been working on the same repo for 6 months, does it still explore, or does it skip to proposal?
Civic technologist building AI tools that help systems explain themselves. Clew Suite builder, NACM 2026 speaker. I write about hackathons, product judgment, agent readiness, and learning in public.
Good question, and I can't answer it yet. I haven't used OpenSpec, I've only read the docs. Cuenta started from an empty folder, so there was no code to read first. My version of "explore" was interviewing E. about how she works, and that's where my miss was.
I'll find out on my next build. Have you used explore on a repo you already know well?
Physicist. Ran a deep-tech VC fund for three years. Now CEO of Entalpa: we build a spec layer for AI coding agents, so the agent builds what you meant, not what it guessed.
Yes, this happens quite often. It seems that the developer’s main job is to verify the requirements and acceptance criteria rather than just the implementation. Have you tried OpenSpec? I’m curious how you’d compare its approach to the Devpost skill pack
Civic technologist building AI tools that help systems explain themselves. Clew Suite builder, NACM 2026 speaker. I write about hackathons, product judgment, agent readiness, and learning in public.
Agreed. By the end, most of my time went to checking whether the requirements were right, not whether the code matched them.
I just looked through OpenSpec and I'm planning to try it on my next build. The planning and structure appeal to me. The skill pack interviewed me to write the plan from an empty folder. OpenSpec looks stronger for what comes after: each change gets its own proposal, tasks and spec updates. My one big miss here meant fixing the spec by hand in three places, and OpenSpec seems built for exactly that. Bookmarked and ready to use! Thanks for the suggestion.
Physicist. Ran a deep-tech VC fund for three years. Now CEO of Entalpa: we build a spec layer for AI coding agents, so the agent builds what you meant, not what it guessed.
Glad it helped! The "fixing the spec by hand in three places" part is exactly where it starts to hurt. Would love to hear how it goes on your next build.
Civic technologist building AI tools that help systems explain themselves. Clew Suite builder, NACM 2026 speaker. I write about hackathons, product judgment, agent readiness, and learning in public.
The "two finish lines" catch is my favourite part of this. "E. uses it for her business" and "mock data on camera" can both be called done, and only one of them matters, so splitting hackathon done from project done before the build is exactly the kind of decision that saves a rewrite.
The per-cafe menu shows the limit of any spec interview, though. It catches what you know to ask about. It cannot catch an assumption nobody knew they were making, and eight faithful slices plus a passing end-to-end test will happily confirm a wrong plan. Your timed run by hand, done the way E. works, was the real acceptance test.
On your closing question I lean the way Pushpendra did. If what changes between bakers is brand, menu, numbering and terms, that is configuration, and the product is one small, clearly defined tool. The work per new baker is the eight question interview. Would you keep the invoice-to-her-own-inbox period for every new baker too?
Civic technologist building AI tools that help systems explain themselves. Clew Suite builder, NACM 2026 speaker. I write about hackathons, product judgment, agent readiness, and learning in public.
Thank you! "An assumption nobody knew was being made" is the right name for it. That miss is on me. I never had E. review the plan, and on a custom build that should have been a step. Next time the user reads the scope before any code gets written.
And yes, I'd keep the self-send period for every new baker. Going from a handwritten book to trusting something in the cloud is a big jump. A few weeks of invoices landing in their own inbox first is how they see it works before a customer ever gets one. That's the reliability proof, and it costs nothing but my time to set up.
Thanks for connecting my comment to this. I like how your experience exposed another layer of the problem: separating the builder from the checker helps, but if both inherit the same wrong assumption from the spec, they can still agree and be wrong.
On your last question, I’d lean toward one predictable core with customer-specific configuration, provided the workflows really overlap. I’d validate that with a few real users before generalizing, though. E.’s workflow was exactly the kind of evidence the original plan couldn’t provide.
Civic technologist building AI tools that help systems explain themselves. Clew Suite builder, NACM 2026 speaker. I write about hackathons, product judgment, agent readiness, and learning in public.
I really like how you tested the app by actually using it the way your wife would. The part about the plan being wrong, even when the code was working perfectly, stood out to me. It shows why testing with real users matters so much, especially when you're building something for a real business. I'm also building something crazzy
Civic technologist building AI tools that help systems explain themselves. Clew Suite builder, NACM 2026 speaker. I write about hackathons, product judgment, agent readiness, and learning in public.
Wrong plan, right code! It's a doozy. You're right, testing with real users catches what lives in your head that you didn't necessarily build to. More user feedback during the planning stage would have helped me catch how my plan was wrong at an earlier stage. Well, at least I hope it would!
∵ you liked it ∴ you’ll like this. I built becauseiliked.com so recommendations finally explain themselves.
Try -> https://becauseiliked.com/?utm_source=devto
Love this, I built the site and store for my family’s home business too, and the “lives in someone’s head” part is so real. On your question, I’d say one tool. Like you said, what’s custom is mostly data (brand, menu, numbering, terms), so that’s config, not code. The hard part would be the onboarding interview, not the app. Also “an invoice shows what was ordered, not what’s allowed” is a great catch.
Civic technologist building AI tools that help systems explain themselves. Clew Suite builder, NACM 2026 speaker. I write about hackathons, product judgment, agent readiness, and learning in public.
The bit about the shared menu is such a good example of how AI can build the wrong thing perfectly. I’ve had similar misses where the code was fine, but the assumption behind it was off. Testing the actual workflow is hard to skip.
Civic technologist building AI tools that help systems explain themselves. Clew Suite builder, NACM 2026 speaker. I write about hackathons, product judgment, agent readiness, and learning in public.
I enjoy your craftmanship and your visual simplicity even when a program dedicated to someone directly. A good part in AI ages is the small development liberalization, a bad part is: for example this one.
Thank you @pengeszikra I appreciate it!
The detail about the plan carrying "one wrong guess all the way to the end" is the most valuable thing in this article, and most "AI built my app" posts conveniently skip it.
Every AI-coding demo shows the happy path: prompt → working app → wow. Nobody shows the part where the model's wrong assumption about your domain (e.g. "invoices are per cafe" vs "per delivery") gets baked into 15 files before you notice.
Curious: when you caught the wrong guess, was it because the app visibly broke, or because the output "looked right" but felt off? Asking because the second one is the scary case — silent correctness bugs are the ones that ship.
This time it was during testing that I found the wrong assumed workflow. I was testing the invoicing on the different cafe's and I noticed that not all of them had the same items. One tiny detail that would have made the invoicing worthless. It stings to think of it this way but it's true. It was a very good lesson to learn.
"This one tiny detail would have made the invoicing worthless" is the perfect example of why testing on real data (or realistic data) beats testing on the happy path.
The AI doesn't know that "not all cafes have the same items" — that's domain knowledge that lives in your head, not in the training data. The only way to catch it is to actually use the app.
Curious if you've thought about how to make that knowledge explicit next time. A "domain constraints" section in the spec, or a checklist before testing?
Great question. The more I've learned about spec driven development the more I realize that I don't know what I don't know. A domain constraints section could help in that regard for sure. One of the other DEV-ers @khunjua referred me to Open Spec. Their workflow has an explore step to map the problem before the proposal is written. I'm eager to see if that's a good way to uncover the constraints, too.
/opsx:explore map the problem and understand the codebase
/opsx:propose draft proposal.md, specs/, design.md, tasks.md
"The more I've learned about spec-driven development, the more I realize that I don't know what I don't know" is the most honest sentence in this thread.
That's exactly why the "explore" step matters. Most people skip it and go straight to "propose", which is why their specs miss the constraints that only show up when you actually read the code.
Curious how the explore step handles the "I already know this codebase" case. If you've been working on the same repo for 6 months, does it still explore, or does it skip to proposal?
Good question, and I can't answer it yet. I haven't used OpenSpec, I've only read the docs. Cuenta started from an empty folder, so there was no code to read first. My version of "explore" was interviewing E. about how she works, and that's where my miss was.
I'll find out on my next build. Have you used explore on a repo you already know well?
Yes, this happens quite often. It seems that the developer’s main job is to verify the requirements and acceptance criteria rather than just the implementation. Have you tried OpenSpec? I’m curious how you’d compare its approach to the Devpost skill pack
Agreed. By the end, most of my time went to checking whether the requirements were right, not whether the code matched them.
I just looked through OpenSpec and I'm planning to try it on my next build. The planning and structure appeal to me. The skill pack interviewed me to write the plan from an empty folder. OpenSpec looks stronger for what comes after: each change gets its own proposal, tasks and spec updates. My one big miss here meant fixing the spec by hand in three places, and OpenSpec seems built for exactly that. Bookmarked and ready to use! Thanks for the suggestion.
Glad it helped! The "fixing the spec by hand in three places" part is exactly where it starts to hurt. Would love to hear how it goes on your next build.
Excited for the next project!
The "two finish lines" catch is my favourite part of this. "E. uses it for her business" and "mock data on camera" can both be called done, and only one of them matters, so splitting hackathon done from project done before the build is exactly the kind of decision that saves a rewrite.
The per-cafe menu shows the limit of any spec interview, though. It catches what you know to ask about. It cannot catch an assumption nobody knew they were making, and eight faithful slices plus a passing end-to-end test will happily confirm a wrong plan. Your timed run by hand, done the way E. works, was the real acceptance test.
On your closing question I lean the way Pushpendra did. If what changes between bakers is brand, menu, numbering and terms, that is configuration, and the product is one small, clearly defined tool. The work per new baker is the eight question interview. Would you keep the invoice-to-her-own-inbox period for every new baker too?
Thank you! "An assumption nobody knew was being made" is the right name for it. That miss is on me. I never had E. review the plan, and on a custom build that should have been a step. Next time the user reads the scope before any code gets written.
And yes, I'd keep the self-send period for every new baker. Going from a handwritten book to trusting something in the cloud is a big jump. A few weeks of invoices landing in their own inbox first is how they see it works before a customer ever gets one. That's the reliability proof, and it costs nothing but my time to set up.
Thanks for connecting my comment to this. I like how your experience exposed another layer of the problem: separating the builder from the checker helps, but if both inherit the same wrong assumption from the spec, they can still agree and be wrong.
On your last question, I’d lean toward one predictable core with customer-specific configuration, provided the workflows really overlap. I’d validate that with a few real users before generalizing, though. E.’s workflow was exactly the kind of evidence the original plan couldn’t provide.
Yes, agreed. They both doubled down on their wrong assumptions. I have to laugh about it now but it was such a miss!
Thank you for the suggestion. E has already shown it to one of her chef friends. They liked the workflow. We'll see where it goes from here!
I really like how you tested the app by actually using it the way your wife would. The part about the plan being wrong, even when the code was working perfectly, stood out to me. It shows why testing with real users matters so much, especially when you're building something for a real business. I'm also building something crazzy
Wrong plan, right code! It's a doozy. You're right, testing with real users catches what lives in your head that you didn't necessarily build to. More user feedback during the planning stage would have helped me catch how my plan was wrong at an earlier stage. Well, at least I hope it would!
Love this, I built the site and store for my family’s home business too, and the “lives in someone’s head” part is so real. On your question, I’d say one tool. Like you said, what’s custom is mostly data (brand, menu, numbering, terms), so that’s config, not code. The hard part would be the onboarding interview, not the app. Also “an invoice shows what was ordered, not what’s allowed” is a great catch.
Thanks for the suggestion! More robust onboarding would definitely be helpful. What did you catch when your family's app started being used regularly?
The bit about the shared menu is such a good example of how AI can build the wrong thing perfectly. I’ve had similar misses where the code was fine, but the assumption behind it was off. Testing the actual workflow is hard to skip.
It really is. Maybe a mapped workflow on the users side would help visualize the steps and help uncover assumptions.