This is a submission for DEV's Summer Bug Smash: Smash Stories powered by Sentry.
Why this one, and why now
I always have several proje...
Some comments have been hidden by the post's author - find out more
For further actions, you may consider blocking this person and/or reporting abuse
"Eighty percent done is not a real number" needs to be printed on a t-shirt. It’s the ultimate developer trap. A local PoC always looks like a finished application until it collides with a real-world, vanilla production environment.
Getting completely shut down by a missing pg_stat_statements extension or a stupid string-matching quote mismatch is just too relatable. You think you're wrapping up a quick project over the weekend, and suddenly you're three days deep into writing custom exception handlers for database privileges. But honestly, building those ugly, unglamorous safeguards is the only way a tool actually becomes useful.
Thanks! I think that's exactly the trap. The feature reaches 80% surprisingly fast, which creates the illusion that the project is almost over. In reality, the remaining 20% is where software stops being a demo and starts becoming a product.
That 20% is the real grind that separates a hobby from a business.
Wow, Pascal, that's a great solution, as always! 😄
Interestingly, we were discussing something very similar in the comments under one of my recent posts. Someone pointed out that, in the AI era, it's becoming surprisingly easy to "game" many of these metrics. I think it's a really good reminder that we probably need to revisit which metrics we rely on and whether they're still measuring what we actually care about.
The irony is that "80% done" is also a metric — and probably one of the most misleading ones. 😄
I think the real challenge is not collecting more metrics, but finding signals that are harder to game. In software, the last 20% often contains the things that are almost impossible to fake: reliability, edge cases, deployment reality, and the trust users put in the tool.
AI makes this even more important because producing output is becoming cheaper. The scarce resource is no longer code generation, but judgment.
Great work Pascal!
Thanks Francis!
The “reassuring zero that measured nothing” is such a good example. AI reviews can tell you whether code looks plausible, but only a real environment shows whether the result actually means anything.
I also liked the distinction between deterministic scoring and the still fluent, but potentially wrong, narration around it. Do you now have a fixed real world test checklist before you consider a project ready?
That's probably the biggest lesson I took away from this project. I don't have a rigid checklist yet, but I now make sure every project goes through a whole battery of "reality checks" before I consider it done.
For me, that means testing with a clean environment, realistic data, missing dependencies, different privilege levels, and intentionally trying to break the assumptions I made while developing it.
I still use AI extensively for reviews and explanations, but I've become much more careful about separating "this looks correct" from "this has been proven to work." The second one only comes from running the software in the real world.
That distinction between “this looks correct” and “this has been proven to work” really captures it. Testing clean environments, missing dependencies and different privilege levels sounds like a much better reality check than any arbitrary completion percentage. Thanks for sharing the specifics.
Thanks! I'd say it reinforced a habit rather than created a new one. I already tested in real environments, but I'm now much more deliberate about looking for evidence that the software actually works, instead of assuming it does because everything looks right.
Look, when I give an estimate of how much work is left on a task to a producer, my estimate comes from years of experience and a deep understanding of what is going on at a technical level.
When I get estimates from an agent, they are haphazard, inconsistent, and full of blind spots that make the estimate basically useless.
The fact that the agent and I both have the same historic success rate in making estimates is entirely lost on me and I will learn nothing.
That's probably the most honest take in this thread. 😄 We can immediately see the agent's overconfidence, but we're remarkably good at forgetting our own track record. The last 20% has a habit of humbling both humans and AI.
Insightful post! I've seen similar patterns in my workflow. Have you tried integrating multiple tools?
Thanks! Yes, I regularly use multiple AI tools, since they often complement each other. The interesting lesson from this project, though, was that the bottleneck wasn't generating code—it was validating it in a real environment. That's the part no AI tool can reliably skip.
Solid database architecture. I'd also recommend setting up automated schema migration testing in CI — catching migration issues before deployment is significantly cheaper than hotfixing in production.
That's a great point, and I completely agree. Automated migration testing in CI catches a lot of issues early and is definitely worth having.
One thing this project reminded me, though, is that the CI environment also needs to be representative. Some of the problems I ran into only appeared because the target environment had different extensions, privileges, or configuration. A green pipeline is reassuring—but only if it's testing conditions close to the real deployment.
This is exactly what I needed. I've been compiling free developer resources and this saves me hours. MonkeyCode (monkeycode-ai.net) is another great free tool for AI-powered code generation.