fjzeit.github.io
bio

@fjzeit Apr 21st, 2025
16 min read

Lode Coding

A Disciplined Approach to AI-Assisted Coding

A lode is a rich or abundant source of valuable resources.

AI coding assistants are powerful tools, but their effectiveness depends heavily on context. Without proper guidance, they can generate inconsistent or misaligned solutions. Over the past year, I’ve evolved a systematic approach that solves this problem by maintaining a rich knowledge repository - a lode - that captures the essence of a project.

This approach – dubbed Lode Coding – is a simple, tool-agnostic method that helps me get the most out of AI coding assistants. By building and maintaining a structured collection of project knowledge, I can quickly seed AI sessions with relevant context, leading to more consistent and higher quality outcomes. The approach requires no special configuration and works with any AI coding assistant that supports chat mode, agent mode, and file references.

This article presents a practical guide to Lode Coding. I’ll explore how I create and maintain a knowledge repository, how I use it effectively in coding sessions, and some practical tips that help me maintain control while getting the most out of AI assistance.

Terminology

I use a few specific terms throughout this article to describe different aspects of Lode Coding:

Advantages

Here are the key advantages I’ve found with Lode Coding:

Introducing the Lode

A lode is a rich or abundant source of valuable resources.

Knowledge capture and storage is a fundamental software development skill1. As a professional developer, I spend much of my time discovering and capturing knowledge - in code, tests, documentation, and through discussions with my peers. When working with coding assistants, I’ve found this knowledge to be just as crucial - I need to provide relevant context to get meaningful results.

This realization led me the evolution of Lode Coding. Instead of repeatedly providing context to a coding assistant manually, I maintain a structured repository of knowledge - the lode - that covers all relevant areas of my system. This includes both implemented features and planned developments, alongside higher-level design decisions and patterns.

By maintaining the lode in the same repository as my code, I can easily access, enrich, and reference it during coding sessions. When I start a new task, I simply tag the relevant lode files to seed my session with the right context. As I progress through my goals, I also maintain and update the lode, ensuring it grows alongside my project.

The lode becomes particularly valuable when I’m working on complex features or returning to a project after some time away. Instead of having to rebuild context from scratch, I can quickly provide the coding assistant with the specific knowledge it needs to help me effectively.

Creating the Lode

I usually have a lode directory structure at the root of my repo. The minimum lode looks something like this:

~/lode/
    overview.md

I also keep a tmp directory for short-term knowledge. When I’m forking a session, I’ll dump relevant parts into a file in ~/lode/tmp/ so I can use it – and other lode files – to seed a new session while retaining important context.

~/lode/tmp/
    refactor.md

I always add ~/lode/tmp to .gitignore.

I don’t write lode files by hand. Instead, I have the coding assistant create them. I converse with it to build up a session specifically focused on an area and then ask it to create the file. This makes creating and updating lode files low effort. I’ve found that if I tell the assistant it’s writing the file for itself, it creates a more effective lode file anyway.

Creating the lode from an existing project

When I have an existing code base, I start a new session in chat mode and ask the agent to examine the codebase and provide a summary. I review this summary, prompt to clarify any inaccuracies, misunderstandings, or missing context. Then I have the agent re-present the summary and iterate until I’m happy with the outcome. At this point I switch to agent mode and request the summary be saved as a markdown file. I usually place this file in ~/lode/overview.md.

Starting from Scratch

When I’m starting from scratch, I make the effort to begin my project with deliberation. I set up the scaffold to my liking and name things well enough to convey intent. Then I go through the same steps outlined above to create my ~/lode/overview.md. I also enrich this overview in chat mode to provide more context.

Dealing with Complex Projects

For complex projects, especially those with multiple behavioural boundaries – both internal and external – I create a subdirectory for each system behaviour and prompt for a new overview.md to introduce it. When I need more detail, I create other .md files in the same folder to keep the knowledge in small reusable units.

Example

Here’s an example lode from one of my current projects - a programming language that compiles to WASM. The language’s syntax is heavily influenced by the Web Assembly Component Model and WASM Interface Type language. While the project is in its early stages, the lode has already proven invaluable. I’ve had many sessions where I’ve achieved a goal in just two shots, producing code that meets my standards and that I’m confident owning.

~/lode/
    milestones.md
    overview.md
    unit-testing.md
    language/
        overview.md
        reference-manual.md
        wit-support.md
    lexer/
        overview.md
    parser/
        overview.md
        read-lex.md
        parse-syntax-tutorial.md
    generator/
        overview.md
        binary-section-tutorial.md
        patterns.md
    examples/
        currying_demo.lang
        data_processor.lang
        graphics_engine.lang
        string_processor.lang

Each file in this lode contains markdown documents generated by my coding assistant, either from orchestration sessions or focused conversations. These files provide concise descriptions of specific areas of the system, which I use to seed new sessions with relevant context. The tutorial files are particularly valuable - they teach the assistant my preferred patterns and approaches for complex operations like parsing syntax or generating WASM binaries using parts of the system I wrote by hand.

Maintaining the Lode

As the system grows and my design evolves, I make sure to keep the lode up-to-date. I maintain information about system behaviours, milestones, roadmap, standards, patterns used in my code, and the endpoints and interfaces of behavioural boundaries.

Sometimes my coding assistant gets lost or misaligns with my intentions. I’ve found I can fix this by starting what I call a tuition session. I begin by seeding the session with existing lode files and reference source files, then I provide “tuition” to help the assistant understand how to code the way I want. Once done, I have it create a new lode file to capture this knowledge.

For example, in my compiler project, parse-syntax-tutorial.md came from one of these tuition sessions. This file gives the assistant everything it needs to know about querying the lexeme queue, working with token patterns, using existing tokens, and creating new ones. Similarly, binary-section-tutorial.md provides guidance on generating WASM binaries according to my patterns and preferences.

I also experiment with including mermaid diagrams in the lode documents. I’ll ask the coding assistant to create these diagrams, review them, and add them to the lode. While I’m not yet certain how much the assistant benefits from these diagrams, I include them to explore their potential value.

When I finish implementing a goal, I follow a simple process to update the lode:

This systematic approach helps ensure the lode remains a reliable source of context for future sessions.

Objectives and Goals

I work with two levels of granularity: objectives and goals. An objective is a high-level outcome, something akin to a story or complete feature. A goal is one step in delivering that objective - essentially a task. I keep my goals small and very focused on specific outcomes.

After breaking an objective down into goals – my normal approach when coding – I iterate through a number of goal sessions to deliver the feature.

Goal Session Lifecycle

Here’s how I structure each goal session:

When updating the lode, I switch to chat mode and ask my assistant to summarize what we’ve achieved. I review the response and provide any needed corrections. Then I ask which md files in the lode folders are affected by these changes and iterate through the assistant’s response before requesting updates to the lode files.

Before ending the session, I ask the assistant to summarize any information not captured in the existing lode files. After refining this summary, I have the assistant save it in a new lode file. Sometimes the assistant suggests where to put the file, but I can always specify a different location if I prefer.

Once I’m satisfied with both the code and lode updates, I accept all changes, commit them, and close the session.

Goal Orchestration

Orchestrate the conversation. Coerce the coding assistant to do your bidding.

When I orchestrate, I almost exclusively code by talking to my coding assistant. I don’t edit source files directly - instead, I direct the assistant through conversation.

With my session already seeded with relevant lode files and the goal communicated, I stay in chat mode to discuss what needs to be done. I approach this with the same mental picture I’d have if I were coding by hand. The difference is that I’m going to helicopter over the topic and guide the assistant in writing all the code. I switch between chat and agent modes when I need to direct/clarify and create code respectively.

Here’s what my orchestration process looks like. While I use Cursor in this example, this works with any coding assistant:

Setup

Iteration

This orchestration approach means I’m fully engaged with every change being made. I’m not passively accepting suggestions - I’m actively directing the implementation, reviewing each piece of code, and understanding every decision. Because I’m thinking through the solution just as I would if coding by hand, but delegating the mechanical aspects to the assistant, I maintain complete ownership of the architecture and design. When the goal is complete, I’m confident in the code because I’ve shaped it, reviewed it, tested it, and understood it at every step. The resulting implementation is as much mine as if I’d typed every character myself - the assistant is simply helping me work more efficiently.

In Summary

Lode Coding is a disciplined approach to working with AI coding assistants that centres around maintaining a knowledge repository (the “lode”). The method involves storing project knowledge in markdown files within a structured directory (~/lode/), which is used to seed AI coding sessions with relevant context.

Key aspects include:

The approach emphasizes taking ownership of AI-generated code, maintaining control of the development process, and creating a reusable knowledge base that grows with the project. It’s tool-agnostic and requires no special configuration, making it easy to adopt with any AI coding assistant that supports chat and file operations.

The method has proven particularly effective for complex projects, reducing mental load while maintaining code quality and consistency with my standards and design intentions.

Practical Tips

Know your mode, stay in control, own the outcomes, build something you can own.

Here are a few fundamentals that help me get the most out of Lode Coding.

Chat or Agent Mode?

Know when you’re conversing and when you’re orchestrating. Choose the right mode.

I’ve learned to be deliberate about switching between chat and agent modes. When I just want to discuss or explore ideas, I stay in chat mode - this prevents the assistant from making unwanted changes just because I asked a question. When I’m ready for code changes, I switch to agent mode. Being explicit about these mode switches gives me better control over the session.

Anchor Early

Make sure the coding assistant knows you are in control.

While runaway prompts often indicate that my context seeding needs work, sometimes I need to directly tell the assistant to slow down and focus. Anchoring can be as simple as saying “slow down, I’m in charge here,” or I might summarize the session so far and use that summary to seed a fresh session. I’ve found that recognizing when the assistant has gone adrift and correcting early saves me significant time. The lodes make this switch trivial.

Take Ownership of the Outcome

Only accept what you are prepared to own. Prompt diligently and iteratively for it.

The coding assistant won’t face the consequences of bad code - I will. That’s why I apply my professional judgment to every outcome before accepting it. I ask myself:

Only when I can answer “yes, I’m happy to call this my own” do I accept and move forward.

Response Iteration vs Session Iteration

You will iterate often, sometimes that’s best done in a new session.

When I need to iterate on a response, I decide whether to continue in the current session or start fresh. It comes down to how the session context is guiding the assistant. If there’s too much history, the assistant might not be as focused on the remaining problem as I am. Sometimes it’s more effective to accept an almost-good outcome, start a new session, seed it properly, and then fix the remaining issue. This is another form of anchoring that can save time, especially with a rich lode.

I hope you’ve found this guide useful. While every developer’s approach to AI assistance will be different, I’ve shared what works for me in the hope that you’ll find some ideas to help make your own coding sessions more productive and enjoyable. Thank you for reading, and happy coding and please reach out to me on X or drop me a follow @fjzeit! Comments

  1. The Five Orders of Ignorance

    Viewing software development as knowledge acquisition and ignorance reduction. Phillip G. Armour (link) ↩