Most developers start using AI coding tools the same way. They open a chat, describe what they want, and ask it to write the code. Sometimes it works. More often, it produces something almost there but slightly wrong, and fixing it costs more time than it saved.
That was my experience too, until I changed how I approached using AI in my work. The difference was not the model. It was the method. I have used this approach with both GitHub Copilot and Claude across professional and personal projects, and it has consistently outperformed ad-hoc prompting. What I eventually realised is that I did not have a prompting problem. I had a context management problem. Once I started treating documentation as a shared memory system between me and the AI rather than project paperwork, I immediately noticed the benefits.
The Problem I Kept Running Into
When I asked an AI tool to build something without proper context, I was asking a capable developer to work from a rough verbal description. It would fill gaps with assumptions. The output reflected those assumptions, not my actual requirements.
The result was code that compiled, looked reasonable, and missed the point.
There was a second problem compounding that. AI sessions have limits. Context windows fill up, sessions time out, and picking up mid-project means re-explaining everything the tool no longer has access to. Without structure in place, each new session felt like starting from scratch. The tool would drift, contradict earlier decisions, or hallucinate details about code it could no longer see. The problem was not the tool. It was the lack of shared context.
What Software Engineering Already Knew
Looking back, I was rediscovering something software engineers have understood for decades. Requirements matter. Specifications matter. Shared understanding matters.
Teams that write architecture decision records, do not do it because they enjoy writing documents. They do it because decisions made without a written record get forgotten, misremembered, or invisibly reversed. The same dynamic applies when working with AI tools, except the stakes are compressed into a single session. An AI tool without a specification is in exactly the same position as a developer joining a project on day one with no documentation and no handover. It will do something, but it will do it based on guesswork rather than intent.
What AI has not replaced is the need for clarity before execution. It has amplified it. A developer working from ambiguous requirements might ask clarifying questions or flag the ambiguity. An AI tool will proceed confidently and produce something wrong. The principle has not changed. The leverage has. A poorly written specification might slow down a developer. The same ambiguity can send an AI system down an entirely different path.
The Pattern I Settled On: Plan, Document, Build
Across several projects, I have settled on this consistent three-stage approach. Your mileage may vary, but for me this has improved both output quality and reduce the overall time to produce working code.
Stage one is planning with the AI. Before writing a line of code, I use the tool as a thinking partner. I describe the problem, the constraints, what I want to avoid, and what success looks like. This is a conversation, not a prompt. It often takes several exchanges and the plan changes as I think through it.
Stage two is producing the shared memory system. Once the plan feels solid, I ask the tool to turn it into a structured implementation guide, something detailed enough that a developer, or a completely fresh AI session, could build the project from scratch without clarification. For a download module, that means defining input sources, retry behaviour, storage location, error handling, and expected output contracts. Every integration point written down, every edge case considered.
Stage three is building from it. Individual tasks become smaller and more contained. Instead of “build me a pipeline that does X”, each prompt becomes “implement the download module described in section 3 of this guide.” The output is more accurate because the context is explicit rather than inferred.
The Shared Memory System in Practice
AI tools do not retain memory between sessions. Every time you start a new conversation, the tool has no idea what you built yesterday, what architectural decisions were made, or what constraints were agreed. Without the guide, the first part of every session is reconstruction. With it, you hand the tool the document, point to the relevant section, and pick up exactly where you left off.
The habit that makes this work is marking progress directly in the guide as you go. Completed sections get marked done. Decisions that shifted during implementation get noted inline. The tool is reading facts rather than guessing at them. In practice this has almost entirely eliminated the drift and hallucination problems I used to run into regularly.
It also removes the anxiety around session limits. Each session has a bounded task drawn from the guide, and progress is captured before moving on. The next session picks up cleanly from there.
A Few Habits That Have Helped
Once the implementation guide exists, the prompts themselves become simpler. These habits evolved through trial and error, but they have held up consistently across both tools I have tested this with.
Reference the guide explicitly at the start of every session. Provide the relevant section and state clearly what is being implemented. Relying on conversational continuity reduces output quality. Explicit context restores it.
One module at a time. Bounded tasks produce reliable, testable code. Unbounded prompts invite shortcuts and inconsistencies. The specification defines the boundary.
Ask for tests against the specification, not just the implementation. When the guide defines correct behaviour, tests can be written against that definition. This catches a different category of bugs than implementation-only testing.
Treat the guide as a living document. When something changes during implementation, update it immediately. This is the equivalent of keeping ADRs current when a decision is revisited. Without it, the shared memory drifts from reality and stops being reliable.
When This Approach Is Overkill
Not every task warrants this. For small scripts, quick one-off automation, or narrow prototypes, the overhead of upfront planning outweighs the benefit. Direct prompting works fine and iteration is low cost.
The pattern pays off on anything with multiple components, anything spanning more than one session, or anything where consistency between modules matters. The more complex the project, the more the absence of a shared memory system costs in drift, rework, and debugging time.
What This Actually Changes
The reality is that most developers are treating AI tools as a prompting problem when they are actually facing a context management problem. Better prompts produce marginal gains. A shared memory system changes the quality ceiling entirely.
This becomes clear once you experience the difference. The tool stops drifting. Sessions stop feeling like they are fighting against an invisible limit. Output becomes consistent because the inputs are consistent. The specification does not just guide the AI. It eliminates the conditions that produce unreliable output in the first place.
AI development is not primarily a prompting problem. It is a documentation problem. Treat it accordingly, and the tools available today become significantly more capable than most developers currently experience them to be. That is not a small shift in productivity. For complex projects spanning multiple sessions, it is the difference between a tool that works and one that does not.
Where to Start
The entry point is low cost. Start a conversation with your AI tool of choice and describe the problem you are solving, not the implementation, the problem. Ask it to produce a structured plan, push back on anything that does not fit, and refine it until it accurately represents what you want to build. Then ask it to turn that plan into a detailed implementation guide that a fresh AI session could execute from scratch.
That document has been worth more to me than any individual prompt I have written. I have used this pattern with both Copilot and Claude across different project types, and the core approach holds regardless of which tool is being used, because the underlying problem it solves is the same in both cases.
Improving this one capability, building a shared memory system before building anything else, is one of the highest-leverage changes a developer can make to how they work with AI tools today.
Also published on Medium.