Stop Prompting Blind: The Spec That Fixed My AI Rework Problem
Why 66% of developers waste hours on “almost right” AI code, and the 5-part template that prevents it.
Check out the Build Series. Part 1 | Part 2 | Part 3 | Part 4 | Part 5
The single most reliable way to get bad AI-built code is to open a new Lovable session and start typing what you want without first telling Lovable what it is building into. Part 6 of this series showed you what to verify after an AI-built feature ships. This is what you write before the first line of code exists.
When I was building AIAdventChallenge.com, I had 37 contributors sending me PDF submissions for the advent calendar doors. I asked Lovable to build a PDF upload handler. It built one.
The progress bar worked. The confirmation message appeared. Lovable told me everything was fine.
Everything was not fine.
When I checked the Supabase database, every single table was empty. Lovable had created an edge function that received the PDFs, stored them locally inside the function runtime, and then discarded them when the function ended.
It never passed a single field to Supabase. Thirty-seven contributors’ content, gone after every upload, and the tool reported success every time.
The fix? I deleted all the PDF parsing code and manually copied contributor content into Supabase myself. What killed an afternoon could have been prevented with one paragraph written before I opened the Lovable chat.
That is the exact problem I audit for.
66% of Developers Are Stuck Debugging “Almost Right” AI Code
The Stack Overflow 2025 Developer Survey found that 66% of developers say their single biggest frustration with AI tools is “AI solutions that are almost right, but not quite.” Forty-five percent say debugging AI-generated code is now more time-consuming than writing it from scratch.
This is not a model quality problem. It is a context problem.
The GitHub blog on Spec-Driven Development puts it directly: “The dominant failure mode of AI-assisted development is not the model being wrong. It is the model being wrong because it didn’t know something that the developer assumed was obvious.” Language models are exceptional at pattern completion. They are not built for mind reading.
✅ The AI guesses at scope when scope is unstated
✅ The AI guesses at business rules when they live in a Slack thread
✅ The AI guesses at edge cases when edge cases are not documented
✅ The AI guesses at user tiers, permissions, and caps when they exist only in your head
The pattern is the same on every team I audit. The prompt looked fine. The output looked correct.
Then it broke in production because the AI built the happy path perfectly. Your domain knowledge never made it into the context window.
Why PMs Are the Worst at This
PMs write requirements for a living, but most of us have not updated that skill for how AI agents actually read them.
A PRD written for an engineering team is designed to be discussed, clarified, and interpreted in sprint planning. An AI agent does not ask clarifying questions mid-session. It fills every gap with a reasonable assumption and keeps going.
The JetBrains 2026 Research Blog analyzed two years of log data from 800 developers and found that
“AI redistributes and reshapes devs’ workflows in ways that often elude their own perceptions.”
The time you saved upfront shows up as rework time downstream, but your velocity metrics call it “debugging” instead of “bad requirements.” Your sprint board has no column for time spent fixing what AI assumed.
The Approach I Follow
Here is the five-part spec I write before I give Claude any feature prompt:
✅ What this is and is not. One sentence on the product context, and an explicit “this is NOT” statement. Lovable has no knowledge of your existing architecture. You need to tell it what kind of system it is building into and what adjacent systems it should leave alone.
✅ The tech stack and the tables. Which Supabase tables are relevant, what the key fields are called, and what the data types are. This is the single fix that would have prevented the Advent Challenge disaster. If I had written “PDFs are input. The output is a row in the doors table with these fields,” the edge function would have written to Supabase.
✅ What “done” looks like. A clear success definition at the data level, not the UI level. “Done” is not “the upload button works.” Done is “a row appears in the doors table with content populated and contributor_name set.”
✅ What NOT to build. This is the section I learned the hard way from the Advent Challenge. I got an entire contributor management interface I never asked for. The spec needs an explicit list of things Lovable should not create, including storage it should not set up and interfaces it should not touch.
✅ The failure definition. What should happen when the feature breaks, at the database level. What gets logged? Where? Silent failures are the enemy of AI-built products. If Lovable’s default behavior is “show success and discard the data,” you need to explicitly define what a real failure looks like.
If your AI-built features are shipping with assumption-driven bugs, this five-part spec is the exact process I walk teams through in an audit. Three slots open this month at promptledproduct.com/audits.