You type "add a way for users to upvote posts" into Cursor. It builds something that works. You type the next request, then the next, and by feature five the upvote count is stored in three different places, none of them agree, and you're not sure anymore why. Nobody wrote a bug on purpose. Everyone, including the AI, was just answering the question directly in front of it, one prompt at a time, with no memory of the decisions two features ago.
That's prompt-and-pray: describe what you want, hit enter, see what comes back, patch what's wrong, repeat. It's not a lazy approach exactly, it's the default one, because typing a request and reading the result is the most obvious way to use any of these tools. The alternative, deciding what you're building before you start typing requests, sounds like extra work up front. It's actually the thing that keeps prompt six from undoing prompt two.
What prompt-and-pray actually looks like
Prompt-and-pray isn't a strawman, it's how most people start, including experienced developers. You have an idea, you open Claude Code or Cursor, and you describe the next thing you want. The tool builds it. You look at the result, decide if it's close enough, and either accept it or describe what's wrong. Then you move to the next thing.
For a single feature in isolation, this works fine, arguably better than planning would, because you're reacting to something real instead of guessing in the abstract. The trouble starts when feature two needs to agree with a decision feature one made silently. Maybe feature one stored user preferences as a JSON blob because that was the fastest path to a working demo. Feature four needs to query one of those preferences directly, and now you're either migrating the schema or writing a workaround. Nobody decided the JSON blob was temporary. It just was, quietly, and the AI had no way to know that, because you never told it.
Why it works great for feature one and badly for feature five
Every additional prompt-and-pray decision is a small, local, reasonable-sounding choice made with no visibility into the choices before or after it. Individually they're all fine. Collectively they drift, because nothing is holding them to the same set of ground rules. This is the mechanism behind the common complaint that AI coding tools "get worse over time." The model usually isn't degrading. The context it's working from is, and prompt-and-pray guarantees that context stays thin.
The tell is usually structural before it's visible. Two components that should share one date-formatting function each grow their own. Three different pages implement "is this user allowed to see this" slightly differently. None of it looks broken in a demo. It looks broken three weeks later when you're debugging why the same fix didn't fix the bug in the other two places it also lives.
Signs you're already prompt-and-praying
You don't need to diagnose this in the abstract. A few concrete tells show up before the app is actually broken:
- You've asked the AI to "make sure it's consistent with the rest of the app" more than once. That instruction is a request for the AI to infer your own decisions back to you, which is exactly the job a spec should have done up front.
- Two similar features look and behave slightly differently, and you can't remember deciding that they should.
- You keep re-explaining the same constraint ("no, this app doesn't have teams, it's single-user") in a new prompt every time it comes up, because nothing durable is holding that decision.
- The AI's suggestions have gotten noticeably more generic since session one, even though the model hasn't changed. That's usually context dilution, not the model getting worse.
None of these are catastrophic on their own. Together, they're the shape of a project accumulating undocumented decisions faster than anyone, human or AI, can track them.
What spec-first means (it's not a 40-page doc)
Spec-first sounds like it means writing a formal document nobody will read. It doesn't. It means making the handful of decisions that future prompts will need to agree with, once, before you start prompting, so every feature after the first one is building against the same ground rules instead of guessing new ones.
Concretely: one paragraph describing the app, a ranked list of what you're building and what you're explicitly not, and a rough shape for the data. That's the whole spec for a weekend project. Anthropic's own guidance on agentic coding (opens in new tab) makes a related point about agents generally: well-scoped tasks with clear success criteria outperform open-ended ones, and the same logic holds for coding agents specifically. A spec is just that scoping, written down once instead of re-decided every prompt.
The point isn't to plan every screen before you start. It's to fix the handful of decisions (data shape, what "done" means for the core features, what you're deliberately skipping) that every later prompt would otherwise have to guess at fresh.
The same feature, built two ways
Prompt-and-pray: "add comments to posts." The AI picks a shape for a comment (probably flat, no replies) because that's the simplest interpretation. Two weeks later you ask for threaded replies, and it has to retrofit a parent-child relationship onto data that was never built to hold one.
Spec-first: before touching comments, you'd already decided, as part of your ranked feature list, whether replies mattered for v1. If they don't, you say so explicitly ("comments, no threading, that's a v2 idea") and the AI builds the flat version knowing it's flat on purpose. If they do matter, the AI builds the parent-child relationship from the start, because you told it to, not because it guessed right.
Same AI, same tool, roughly the same amount of typing either way. The difference is whether the decision got made once, on purpose, or five times, by accident, across five different sessions. This holds whether you're in Cursor, in Claude Code, or describing the same feature to Lovable or Bolt. The tool executes the decision. It doesn't make it for you, no matter how confident the output looks.
The takeaway
Prompt-and-pray isn't wrong because it's careless. It's wrong because it asks the AI to remember decisions it was never told, and then acts surprised when it doesn't. Spec-first isn't more work, it's the same handful of decisions made once instead of re-litigated every prompt.
That's the actual product Draftlytic builds: not a longer document, a shorter one, made once, up front, in a shape Claude or Cursor can act on without guessing, and that translates just as cleanly if Lovable is what you open next.