TL;DR
Your first instruction set is rarely complete. A one-time prompt often misses architecture, edge cases, security, testing, dependencies, and acceptance criteria. Prompt the LLM to expand the instruction set, critique what is still vague or missing, and then polish it into a modular execution plan. But do not let the instruction set become one giant mega-prompt. Use the expansion process to discover the full context, then break the work into Lego-like blocks: one phase, one function, one connection point, one verified result at a time.
One of the biggest mistakes I keep seeing in AI-assisted development is treating the first instruction set as if it is complete.
It usually is not.
A first-pass instruction set can look polished. It may have sections, bullets, roles, constraints, deliverables, and a definition of done. It may feel comprehensive enough to hand to an LLM or coding agent. But in real projects, especially larger vibe coding projects, the first draft almost always omits something important.
Not because the model is lazy.
Because the first version of the instruction set is usually based on what you remembered to ask for, not everything the project actually needs.
That distinction matters.
When you tell an LLM, “Create an instruction set for this feature,” it will usually produce something useful. But useful is not the same as complete. It may cover the happy path while skipping error handling. It may describe the feature without describing integration boundaries. It may mention testing but not define what must be tested. It may say “follow security best practices” without translating that into concrete rules. It may generate implementation steps but miss rollback behavior, logging, observability, user permissions, or the real definition of done.
This is why I have started treating instruction sets as iterative artifacts.
The first prompt creates the skeleton.
The second prompt finds the missing bones.
The third prompt turns it into something an AI agent can actually execute.
A simple pattern works surprisingly well:
“Review this instruction set. Expand it with anything missing, especially edge cases, architecture concerns, dependencies, testing, security, and acceptance criteria.”
Then run it again:
“Now review the expanded version. Identify any vague instructions, hidden assumptions, missing context, or places where an AI coding agent could misinterpret the task.”
Then run one more pass:
“Polish this into a final execution-ready instruction set. Make it modular, explicit, testable, and suitable for a coding agent working in phases.”
That sounds almost too simple, but it pays dividends.
The difference between a one-pass instruction set and a three-pass instruction set is often the difference between “the AI generated code” and “the AI generated something I can trust enough to review.”
This became obvious in projects like GePT-AI Studio. The early temptation was to describe the application and let the model run. But the project was not just a UI. It had concerns about workflow, governance, model selection, artifact handling, file safety, organizational memory, user experience, and long-term extensibility. A single instruction set could not reliably hold all of that unless it was expanded, challenged, and refined.
The same pattern showed up in the Desktop AI Coding app concept. “Build a desktop AI coding application with mobile monitoring and command control” sounds like a clear request. It is not. That sentence hides a pile of architectural decisions: local execution, cloud relay, outbound-only connectivity, status publishing, approvals, alerts, connector management, local model support, authentication, logging, and failure modes.
A one-time prompt will often collapse those pieces into a foggy implementation plan.
An expanded instruction set starts separating them into real engineering work.
The Teams plugin idea is another example. “Add Microsoft Teams integration” sounds like a single feature. But once the instruction set is expanded, you start seeing the actual bricks: resolve users, search messages, open results, create or reuse chats, post messages, manage Microsoft Graph authentication, cache tokens, handle permissions, and expose deterministic MCP tools. Each one needs its own boundaries and verification.
That is the point: expansion reveals structure.
Polishing makes that structure executable.
But there is a second trap here.
As your instruction sets get better, they also get longer. And as they get longer, they can become their own source of complexity. A giant instruction set can become just as dangerous as a giant coding prompt. The LLM may miss pieces, blur priorities, or optimize for surface-level completion instead of actual correctness.
So the answer is not simply “make bigger prompts.”
The answer is: expand first, then modularize.
This connects directly to the Lego set approach I discussed in my post on building vibe coding projects piece by piece. The principle there was simple: one piece, one function, one connection point, one verified result at a time. A complex application should not be handed to an AI as one giant blob. It should be broken into small, testable units that can be completed and connected deliberately.
Instruction sets need the same discipline.
Use the expansion process to discover the full project context. Then split that context into modular instruction blocks:
Project Context: What are we building, why does it exist, and what constraints matter?
Architecture Rules: What patterns, boundaries, and dependencies must be respected?
Phase Objective: What specific piece are we building now?
Implementation Instructions: What should the agent do in this phase?
Do Not Do List: What should the agent avoid changing, inventing, or assuming?
Verification Steps: How do we prove this phase works?
Definition of Done: What must be true before we move to the next block?
That format gives the LLM enough context without asking it to mentally juggle the entire project at once.
The goal is not to bury the model in instructions.
The goal is to remove ambiguity.
A weak instruction set asks the AI to guess. A stronger instruction set makes the important decisions explicit. An expanded and modular instruction set gives the AI room to execute without giving it room to drift.
This matters because AI coding failures often do not appear to be failures at first. The code compiles. The screen renders. The feature seems present. But under the surface, the model may have ignored the architecture, duplicated logic, skipped tests, invented a workflow, weakened security, or solved a slightly different problem than the one you intended.
That is how you end up managing the side effects of your last ten prompts instead of making progress.
Better instruction sets prevent that.
Not perfect ones. Better ones.
The practical rule is simple: never assume the first instruction set is complete. Ask the LLM to expand it. Then ask it to critique the expansion. Then ask it to polish the result into a modular, executable form.
You are not just prompting for output.
You are prompting for understanding.
And in AI-assisted engineering, that extra pass is often where the real context finally appears.
