Most developers start the same way: “Write me this feature.” They get code, iterate on it, fix what breaks, ask again. Repeat until it’s close enough to ship.
A Redditor in r/PromptEngineering has been testing a different sequence. Instead of asking AI for code directly, the author builds a structured prompt system first. The code comes after.
That sounds like a minor process adjustment. In practice, it moves the work to a completely different stage of the build.
The Core Problem With Jumping Straight to Code
When you go from vague goal to code generation in one step, you’re asking the model to fill in the gaps for you. Sometimes it guesses correctly. More often, those gaps become bugs, missing features, or architecture that doesn’t quite match what you actually needed.
The result: you spend hours iterating on code when the real issue was that the requirements were never clear.
Old way: “Build me a habit tracker.” Get code. Realize it’s missing half of what you meant. Revise the prompt. Get different code. Iterate on the output.
New way: use AI to turn vague intent into a structured specification first. Then let that spec drive the code.
The difference isn’t prompt quality. It’s that iteration happens at the right level.
The Prompt-First Workflow, Step by Step
Here’s how the four phases break down:
Phase 1: Intent Capture
Start with a simple, abstract goal. Keep it loose on purpose.
Example: “I want an app that helps me track daily habits.”
That’s the full input. No spec, no tech decisions, no assumptions baked in yet.
Phase 2: Prompt Structuring
Have the AI expand that intent into an operational layer. This includes:
- 🔹 Subtask decomposition (auth, data model, UI components)
- 🔹 Constraints and boundaries (platform, stack, privacy rules)
- 🔹 Success criteria (what “done” actually looks like)
- 🔹 Human review checkpoints
This is where engineering judgment gets encoded. Not in the final code. Here, in the structure. The author is using AI to write a spec, one that then feeds the next stage.
Phase 3: Tool-Level Prompt Generation
The structured layer drives targeted, executable instructions:
- “Generate a React + TypeScript login component with form validation”
- “Design a localStorage schema for habit entries with timestamps”
- “Write unit tests covering edge cases for streak calculation”
Each instruction is scoped, specific, and grounded in the constraints established in Phase 2. Nothing is left ambiguous for the model to fill in.
Phase 4: Implementation + Human Steering
The AI produces code based on those instructions. The human steers at key decision points, adjusting constraints and direction as needed. When something’s off, the fix happens at the prompt-structure level, not just the output level.
That distinction matters. It means you’re correcting your map, not patching your terrain.
Three Things That Actually Drive the Results
The author identifies where the real leverage is in this workflow.
First, don’t force the model to jump to final code. Having it generate the next executable layer first produces more stable results. Errors surface in planning, not in debugging.
Second, constraints beat wording tricks. Explicit success criteria, failure conditions, and tool selection logic consistently outperform clever prompt phrasing. A well-constrained vague prompt beats a perfectly-worded unconstrained one.
Third, the leverage lives in the middle layer. Not the original request. Not the final output. The structured prompt architecture in between. That’s where professional judgment gets encoded and preserved across the build.
One of the top comments on the post pointed to spec-driven development as a more powerful alternative. That’s not really a contradiction. What this workflow does is use AI to handle the spec translation work. The principle is the same. The access point changes.
What This Means for How You Work
The human role shifts when you build this way. Less time writing syntax or wrangling output that doesn’t fit. More time defining intent, setting constraints, and reviewing whether the result actually solves the right problem.
The author’s argument: this is why “everyone can code” might finally become something real. Not because code became unnecessary. Because the interface to creating software is changing.
Honest caveats: you still need to express intent clearly and recognize when output misses the mark. Garbage constraints in, garbage code out. That part doesn’t change.
But if you can articulate a goal, define what success looks like, and spot logical gaps? This workflow is worth a serious look.
Start Here
On your next project, before asking AI to write anything:
- State the goal in one sentence. No spec, no constraints yet.
- Ask the AI to decompose it into subtasks, constraints, and success criteria.
- Review that structure. Adjust it until it reflects what you actually want.
- Use that structure to drive targeted code generation prompts.
That’s the sequence. Try it once and see what changes.
The author ran a live demo of the full workflow, including the complete prompt architecture. Video and details in the original post.
Frequently Asked Questions
Q: Isn’t this just spec-driven development with extra steps?
Kind of, yeah, both start with a spec. But here’s the thing: instead of you grinding out detailed specs from a fuzzy idea, AI does the first translation for you. It breaks down your vague intent into actual structure (subtasks, constraints, success criteria). You’d still do spec-driven dev manually, but AI handles the hardest part: bridging the gap from “I want a habit tracker” to “here’s what we actually need to build.”
Q: What’s the AI doing that a skilled spec writer couldn’t do?
Honestly, a good spec writer could do this. The AI advantage is pure speed, it generates that structured breakdown in seconds instead of hours. Then you refine it. Think of it like having a drafting assistant who handles the boring-but-necessary work of decomposing ambiguous goals, so you can focus on direction and tweaks.
Q: Where do I actually review and steer things, when do I jump in?
Two main touchpoints: after the AI structures your initial intent (review those subtasks and constraints), and before it generates code from the tool-level prompts. Catching direction issues at these early checkpoints keeps iteration lean, since you’re adjusting specifications instead of refactoring code later.
Q: Does this work for all kinds of projects?
It’s best when you know what you want to build but the path to get there is complex. Building a feature you’ve thought through? Perfect. Exploratory work where requirements emerge as you go? Traditional iterative coding might be faster, since you’d be adjusting prompts constantly as you learn. The workflow trades some flexibility for cleaner iteration on code.
Instead of asking AI for code, I ask it to generate prompts first. Here’s why it works better.
by u/Pale-Entertainer-386 in PromptEngineering