Lode Coding Revisited
@fjzeit - Sep 10th, 2025 - 8 min read
Lode Coding is simple, repeatable, low friction, and effective.
Back in April I wrote a short piece on Lode Coding, a disciplined approach to AI-assisted coding. If you’re not familiar with Lode Coding then please read the original Lode Coding article first.
Today I am revising this topic to share a few refinements to the approach. If you want to know about my background then there’s plenty of info in my bio.
Lode Coding’s primary goal is to enhance my own disciplined approach to software development through the use of llms. It’s not a one-shot-wowfest, but an incremental adoption of modern tooling to improve existing, well established, practices.
Keep It Simple, Try It, Take What Works
I’ve found this approach to be extremely effective. It lacks the ego-lifting-circle-jerk-feelgood-factor that seems to attract attention. But I hope some find it as useful as I have.
Lode Coding is simple, repeatable, low friction, and effective. Try it, take what works, leave the rest, or ignore it. I am sharing it for those who will find it useful. It works for me but ymmv.
Revisiting Some Key Points
It’s a Switch, not a Dial
One thing I should have made quite explicit in my original article is that Lode Coding is a switch, not a dial. I don’t mix Lode Coding with traditional coding. I have two distinct forms of development practice:
Traditional coding is where I code manually and deliberately. When I’m coding like this there is no copy/paste. No prompting for implementation. Just good old fashioned discipline, knowledge, and reference material. I don’t use AI auto-complete nor AI-suggestions. I do what I’ve always done. And there are plenty of scenarios where this remains the best approach.
Lode Coding is all about 100% prompting. No code editing. My editor becomes my window into the model’s output. I’m not coding, I’m orchestrating, anchoring, reviewing, and iteratively refining. I’m sharing my experience with the model and building up an effective context window that enables good coding outcomes. And, when I’m done, I’m getting the model to sow that knowledge back into the lode. This differs considerably from Vibe Coding: my focus is on knowledge capture, lode enrichment, ownable outcomes, and quality results.
I’ll talk more about how I segue from one to the other in the next section.
I don’t Write the Lodes
I can’t emphasise this enough. I never write a single lode myself. The model creates and maintains all of them. It’s surprising sometimes how insightful these lodes become. Leaving the llm to write the lodes encourages me to share the knowledge, perspectives, and design objectives required to meet the goal.
Tooling Agnosticism Pays Off
This has proven invaluable. I switch between Github Copilot, Claude Code, and Jetbrains Junie with zero friction. Very helpful considering how the pricing landscape is changing on what seems like a weekly basis. I can seed a session for any assistant and get at minimum the same baseline outcomes. I’ve never used the memory features in any of the tools, they aren’t worth the lock-in.
Currently I pay US$10/m for Github Copilot, US$20/m or US$100/m for Claude Code (depending on how busy I am), and I have access to Jetbrains Junie through my All Products pack. Being able to move between vendor offerings with zero friction is extremely useful, especially considering that Github Copilot has a number of “unlimited” models.
Chat/Agent Mode is Less Important Now
I have found myself being less concerned about chat vs agent mode. Most models will respond to questions without running ahead. But sometimes I find it useful to be explicit that this is a chat or planning session.
Early Anchoring
Once the lodes are enriched enough early anchoring becomes relatively simple. Introducing the lode overview at the start of a session is usually enough. I’ve also found that the model will create a system overview lode without being asked, so I’ll usually source this early too.
In the next section I’ll expand on how I’ve adapted early anchoring.
Take Ownership of the Outcome
This one is absolutely key. Taking ownership of the outcomes, being prepared to call the work my own, being able to maintain it when there’s no agent available. Ultimately the code the model produces reflects my own goals. I am always pushing the development forward with my prompting, not being pulled forward by the model’s decisions.
Nothing gets pushed unless it’s 100% understood, 100% ownable, and at an acceptable level of quality. I can switch to traditional coding practices with all of the Lode Coding outcomes. Just as if it had been written by me or another team member.
Enhancing the Approach
So what enhancements have I made since the last article? Well there are a few that are worth reporting on now. Some I will hold off on until I’ve tried them a bit longer. But let’s delve (!!) into the former.
Planning Lodes
In the original article I mentioned the ~/lode/tmp folder as being a special location for temporal information that I don’t want in the repo. This includes planning lodes. I’ll kick off a planning session, seed it with relevant lodes, have a conversation with the model, ask for it to propose a plan, iterate a refinement of that plan, get the model to document the plan to a tmp lode - including relevant information from other lodes. Then I’ll start a new session, source that one tmp lode, and prompt: make it so.
Planning sessions are 100% discussion based. Lode maintenance is zero effort due to sourcing the lode-overview and relevant lodes as part of that discussion.
Early Anchoring
I find this less useful now due to the planning lodes. It’s far more effective to start a session, source relevant lodes, discuss the session outcomes, create a planning lode, clear the session and then run the next session from that planning lode. Sometimes I can’t just make it so and will have a conversation that produces iterative outcomes.
Switching between Lode Coding and Traditional Coding
I find that the models, especially Claude Sonnet, are better at UI design/implementation than I am. So I will often work traditionally on back end features and then segue into a Lode Coding session to create/iterate the UI.
After a traditional session I’ve found it useful to update the lodes. This’ll usually involve telling the model I’ve made some changes, and then watching it read the code and the lode and then update the lode automatically.
The Grok Effect
I’ve also found it useful to gather information via grok. Usually relating to more technical aspects of a problem. I’ll have a code-agnostic conversation with grok and then copy the conversation as markdown and drop it into ~/lode/tmp as a resource for a Lode Coding session. I have on occassion also brought Grok into an active session to help seed some expertise with minimal effort on my part.
Claude Code Commands
These two commands in my Claude Code global config illustrate how easy it is to kick off and finish a session with a lode update.
~/.claude/commands/lode.md
# Seed lode method
Our knowledge management approach is defined in lode/lode-overview.md
~/.claude/commands/lupdate.md
# Request lode update
remove code comments that provide historical commentary.
update lodes with concise information,
do not leave historical commentary,
the lode is a snapshot for AI agents.
Examples
lode-overview.md provides an example lode overview used for initial project seeding. This gives the model enough information about the approach to enable it to maintain lodes. Bear in mind that the model will update this lode just like any other lode. I place the file in ~/lode/lode-overview.md (github gist)
I have recently open-sourced a handful of projects which have included some Lode Coding efforts. These are:
fjleb128 is an early project which I wrote by hand. I added the lodes later in the project to help me go from “good enough for me” to “good enough to open source”. One area of the library that was Lode Coded was the span support and associated tests. These lodes are a little more verbose than more current ones but give a decent impression of what the model will produce as an outcome of a session. (repo)
arcc is a tool that was produced entirely via Lode Coding. I think I might have put in about 30 mins of traditional coding practice into it. Leveraging my long-established Win32 SDK experience, I prompted my way through this one just to get the tool good-enough. If I wanted to extend this tool I’d probably put in more time cleaning up the code and improving separation of concerns. This one is included because it’s as close to Vibe Coding as Lode Coding gets. (repo)