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.

Continue reading →