Ask the model to propose a detailed plan before proceeding. Specifically, ask it to explain why the code (new or edits) is necessary, why it won’t cause regression to existing functionality, and to list all assumptions. This helps prevent the model from building on incorrect assumptions and helps you reduce the probability space of errors.

Remind it to constantly check its proposals against the Project Knowledge and to validate that the code it’s proposing won’t cause regressions. Keep Project Knowledge updated with the latest version of all files to ensure the model knows the current state of the program. This is less of an issue with @cursor_ai and such, but still worth keeping in mind.

To help maintain state on the program, create a plan.md file and a structure.md file. plan.md should contain a detailed plan for the program (as much as you can foresee) -- I co-develop this plan with the LLM. Ideally, this is a mix of functionality and hygiene. structure.md captures the file structure. Keep these updated in Project Knowledge and routinely remind the model to refer to these files.

Modularize early and often. Break the program into individual modules with clean interfaces. This helps minimize context length and ensures that regressions and bugs are easier to isolate and remedy.

Regularly ask the model to critique the code, and reflect on what’s going well and what isn’t. This helps identify and correct issues faster.

Always ask for the full code of the method that needs to change, rather than just delta snippets, to reduce the risk of unnecessary regressions from copy-paste errors (less of an issue with @cursor_ai). This eats up more context and you'll run out of the chats faster, but it will save you a LOT of time debugging later.

When fixing bugs, ask the model for its hypothesis and what additional information it needs to validate the hypothesis. Ask whether it needs to clarify anything and help it acquire that information. Often, the model will proceed with incomplete information and take you down the wrong path so your number one job is to help it eliminate bad paths.

Focus on building a stable program rather than passing test cases. Sometimes the model might pass a test case but introduce regressions in the process. You must actively remind it that passing a test case is not the ultimate goal (unless that is the case for you). AI will always chase some objective function -- you have to define the objective function.

Frequently update doc strings and documentation, even though this can be tedious. It is crucial for maintaining clarity. Speaking of documentation, it is helpful to maintain a robust README file; this helps you and the model get grounded on the program faster. Alternatively, instruct the model to add documentation every time.

Include documentation such as doc strings. 

A simple heuristic that has worked well for me is to compare the length of the updated file with the length of the previous version of the line. *Usually* if the file's length changes by more than 5-7 lines, it is because the model inadvertently removed a method or some functionality. Here’s the specific instruction that works for me; it results in the model comparing file length and explaining why the the length differs; resulting in fewer regressions.

After writing the code, do a check on file length (lines) and compare it to the current length of the file in Project Knowledge. If the file length varies by more than 5 lines, then check to make sure that you have not caused a regression.

Lastly, regularly back up your code. LLMs can build on top of mistakes, so having the ability to revert to previous versions is essential.

Happy coding!

Enter Claude Sonnet 3.5, and with it, Project Knowledge, which together have been a game changer. With Claude 3.5, the model now maintains much better state information across a project. By leveraging a chain-of-thought approach, I can ask the model to map out the best path forward on complex changes before it even touches the code. This has been revolutionary. I’ve been able to write the core components of a key new business idea using just Claude, and I’ve done it in a matter of days. The competence level of Claude now feels like working with a college senior—a huge leap forward.

However, Claude isn’t perfect (i.e. not yet a Principal Engineer), and it’s clear what’s missing: real-time, updated state information. When you upload files to Project Knowledge and start making changes, Claude doesn’t always account for the evolving state of the program within a session, even if you prompt it to. For example, say you need to make changes that require updates to multiple scripts. By the time you’ve modified two of them, the overall state of the program has changed, and you might need to consider recursion or other complexities.

My workaround has been to constantly upload newly updated scripts to the chat, but this is tedious and far from an ideal solution. The excitement around tools such as Cursor or Github Copilot appears to be around the integrations with models and “comfort features” such as identifying diffs and inserting code into the right places (a huge win, by the way), but I don’t think these are the killer feature. The killer feature, in my view, is maintaining real-time state and a built-in virtual environment that allows the model to auto-test multiple possible solutions and find the most performant one.

This is where the industry is headed, but it won’t be easy; there are significant challenges ahead. One of the biggest challenges is that the user needs to be extremely prescriptive with what s/he wants. Fun demos are relatively easy to code, but anything that needs to make money is necessarily complex or nuanced. Describing these needs in detail will become a must-have skill, a leg up for product managers (hello, PRDs!).

Another challenge is that LLMs struggle with second-order effects. I’ve noticed that even the best models tend to play Jenga with the code, and simplicity is usually not the name of the game. They are often in “apply bandaid” mode, and as a result, a lot of the code ends up working, but it’s unnecessarily complicated. This is somewhat akin to what you’d expect from a recent college graduate—functional but not elegant.

Despite these challenges, this future is becoming more realistic, and it’s going to be worth a lot of money. This technology makes everyone a programmer. It enables people with ideas to bring those ideas to life without needing deep technical expertise, unlocking tremendous value. The path forward for Claude, OpenAI, and others is clear, and I suspect we’re about to enter an arms race among companies like Anthrophic, OpenAI, Cursor, Microsoft/Github and others to build the FSD equivalent of coding.

These are exciting times!