Recently I've been digging into how to use AI efficiently for personal projects and at work. It got my interest when I was using Cursor to quickly build a proof of concept for a project I had been thinking about for a while, but couldn't find the time to do myself. While I — well, the AI — was developing it I started to notice a pattern emerging that made development and bug-fixing extremely efficient, and I want to share these findings with you.

It is well-known by now that the AI is only as good as the person driving it. It is a tool, and a tool is only useful to a person who understands how wield it.

Documentation First

It is no secret that most developers don't like to write documentation. Or at the very least it isn't their first priority — they'd much rather jump in and write some code. Firstly, this is bad practice in general, secondly if you use an AI to write the code it is a sure-fire way of ending up with a massive pile of spaghetti-code¹.

Infrastructure

Many who try to use AI in their development environment for the first time seem to conclude that the AI isn't doing a very good job, and then ends up discarding the AI as a merely curiousity that might be useful for small, trivial and uncomplicated things only. And it is understandable why; we are told that these AIs are oh-so powerful PhD-level masterminds that can solve anything — but then can't solve almost trivial design problems when asked to do so in a real-world scenario.

The reason why it can't do this out-of-the-box is that you haven't given it the input it needs to arrive at the right solution.

Test-Driven Development

Lessons Learned

Contrary to what you might think, you can teach the models you use new things. While you cannot directly teach an AI model anything new, as its weights are fixed and controlled by the providers, you can give it the infrastructure needed to save memories locally that it can refer to later.

As your agent debugs issues in your system it will usually find ways of doing so by recognising.

It should record these properties:

• Symptoms - observations that identify the type of problem.
• Causes - related causes that can trigger that kind of error.
• Solutions - description of how the problem might be resolved.

Symptoms

Let's say your system uses some operating system which will halt on a non-recoverable exception. A reasonable system will produce a log message for such an event, which should include some information about the failure. Minimally this might be the instruction-pointer and a return-address, or possibly even a backtrace. This is a symptom.

Causes

Solution

A reasonable solution in this case would be to analyze the disassembly to determine how actually happening and likely causes.

Example

1# Debug Agent Memory
2
3## Symptom
4
5## Cause
6
7## Solution
8
9### Key words
10- assert
11- exception

Model Context Protocol

If you have a large-scale project it can be exceedingly difficult for an AI to figure out which parts are relevant to look at or how to attack a particular problem. Since you have explicit knowledge of the system, giving it a set of relevant tools that it can invoke helps it gain a footing.

The TL;DR

• Focus on concept and documentation first — an AI is much more likely to get it right if it is anchored in a well-documented concept.
• Use test-driven development and have the AI consistently check that it makes progress without breaking the system.
• Give the AI adequate infrastructure that fits with your project.
• Provide the means for the AI to learn is a powerful way of making it more and more efficient over time — especially for debugging!

In the end, all of this is really just a reiteration of good development practices that we all know are tried, tested and proven to work. And, it just so happens that it will accelerate your AI-driven development even more as well, if you follow these practices.

1. Code control flow that is convoluted, and therefore, hard to understand Wikipedia ↩