@fjzeit - - 16 min read
Lode Coding
AI coding assistants can read your files, but they do not automatically understand your project.
They do not know which compromises were deliberate, which naming patterns matter, where the boundaries really are, or why a piece of code looks simpler than the alternative you rejected two months ago. That deeper context usually lives in your head, in old conversations, in review comments, and in a handful of half-remembered sessions with whatever coding tool you happened to be using at the time.
That is the problem Lode Coding tries to solve.
I created Lode Coding in 2024 as a way to work with AI without giving up the knowledge, judgment, and accountability that professional software engineering requires, and it has evolved through continued use on non-trivial projects.
Lode Coding is a practical way to give AI assistants durable project memory without giving up ownership of the work. The core idea is simple: keep a structured set of markdown files alongside the codebase that describe the system, the patterns that matter, and the decisions the assistant will need to make good choices in future sessions.
Crucially, this is not meant to become a new documentation job for the engineer. In a healthy Lode Coding workflow, the lode is created and updated as a byproduct of working with the agent: planning, clarifying, correcting, reviewing, and implementing. The engineer provides judgment, direction, and standards. The agent turns the resulting knowledge into durable project memory.
Done well, that produces benefits early and often: better aligned plans, higher-quality implementation, less rework, and a much better chance that when the session ends, the work is actually done.
I call that maintained body of project knowledge the lode.
The name comes from mining. A lode is a rich vein of valuable material. In this case the valuable material is project knowledge: architecture, terminology, constraints, patterns, tradeoffs, lessons learned, and the shape of the system as it exists today.
It is a working method. The tools can change. The model can change. The lode stays with the project.
The Real Benefit
The value of Lode Coding is that it keeps you from starting from scratch.
Once a project accumulates enough useful context, the assistant can begin each session from a much better place. Instead of the engineer having to repeatedly re-explain the same decisions, the agent can retrieve the relevant knowledge from the lode based on the task and the conversation. Instead of hoping it infers your standards from code alone, you give it a maintained description of the system and the practices that shape it.
That can sound like something ordinary agent skills, tool memory, or better prompting should handle already. In practice they do not solve the same problem. Lode Coding works because the lode lives in the repository, stays tightly aligned to the system and its current implementation, and is continuously shaped by the engineer’s contextual discussion with the agent about the problem domain, the problem at hand, and the design and solution decisions that drive the work. The result is durable, reusable context rather than a one-session boost.
In plain terms, a good lode helps with:
- faster onboarding for new AI sessions
- fewer repeated explanations
- more consistent implementation choices
- better aligned, higher-quality outcomes
- less rework and less downstream cleanup
- better continuity across tools and vendors
- stronger cognitive ownership and easier accountability
- better odds that the assistant will produce something you are actually willing to own
That last point matters most.
AI assistance is only useful if the result remains understandable, maintainable, and acceptable when the session is over. If the assistant helps you move faster but leaves you with code you would not defend in review, the speed was fake.
For me, that is the deeper reason Lode Coding exists. Its purpose is to amplify cognitive ownership, retain the knowledge required to discharge professional responsibilities well, preserve accountability, and ensure that decades of hard-earned engineering practice are not washed away in the rush to AI.
What a Lode Actually Is
A lode is a folder of markdown files in your repository.
At minimum it might look like this:
project/
└── lode/
├── summary.md
├── terminology.md
├── practices.md
├── lode-map.md
└── [domain folders...]
Over time it grows into a structured set of focused documents:
- a top-level summary of the project
- shared terminology
- repo-wide practices and constraints
- subsystem summaries
- focused topic files for tricky areas
- plans and temporary handover material when needed
The important part is not the exact shape. The important part is that the knowledge becomes durable, reusable, and discoverable.
What Goes Into the Lode
The lode should describe the current state of the system and the rules that matter when changing it.
Useful lode content includes:
- what the system does
- how the main parts fit together
- terminology used in the domain
- invariants and contracts
- design decisions that still matter
- patterns worth repeating
- known edge cases
- lessons that would otherwise be relearned the hard way
What it should not become is a changelog in disguise.
The lode is not there to say, “On Tuesday we added X.” It is there to say, “This subsystem now behaves like this, for these reasons, under these constraints.”
That distinction matters because the lode is supposed to help the next session make good decisions, not reconstruct the emotional history of the previous one.
How the Lode Gets Written
I do not treat lode writing as a separate documentation project.
The best lode content usually emerges during real work: planning, review, correction, implementation, and follow-up. As you explain the problem, refine a design, reject a bad direction, or clarify a pattern, you are already generating the material that the lode should retain.
The assistant can then turn that into durable project memory.
That matters because hand-written process documentation often dies of neglect. A lode survives more easily when it is maintained as a byproduct of engineering conversations rather than as a separate discipline that competes with the work itself.
The Working Style
Lode Coding works best when you treat the assistant less like an oracle and more like a very fast collaborator with uneven judgment.
In practice that means:
- establish the problem clearly
- discuss the shape of the solution before asking the agent to change code
- keep the work incremental
- review what the assistant changes
- intervene early when it drifts
- update the lode so the next session starts smarter
You can do this in different tools and with different UI metaphors. Some tools separate discussion mode from editing mode. Some do not. That detail is less important than the behavior.
The key habit is simple: talk through the work before and during implementation instead of hoping the assistant will infer your intent from a vague prompt.
Conversational Orchestration
One of the more important ideas in Lode Coding is what I think of as conversational orchestration.
What I mean by that is simple: the conversation with the agent is a large part of how the work gets shaped, supervised, and improved.
The session usually begins with objectives, likely relevant areas of the system, an outline of the goal, and often a set of pointed questions about the area of interest both to help confirm the engineer’s knowledge and also to bring relevant knowledge into the context. That discussion then iterates until the topic is focused and the session context is sharp. The agent enriches the session from the lode, and the engineer keeps steering it toward the real objective.
Once both sides are aligned, the agent proposes a high-level plan. The engineer reviews it, clarifies it, narrows it, and pushes back where needed. From there the agent can turn that shared understanding into a phased implementation plan. Depending on the complexity, the engineer may ask for the whole plan to be executed or may keep the work phase-by-phase.
At that point the engineer’s role becomes more observational than active, but not passive. The agent implements. The engineer watches the work unfold, reviews file changes as they appear, and intervenes when drift shows up. That intervention is part of the method, not a failure of it. Because the implementation is the direct result of an iterated conversation, the review experience feels much closer to supervising your own thinking made concrete than to receiving an opaque blob of generated code.
This is why Lode Coding is not just about storing knowledge. It is also about shaping the conversation so that planning, implementation, review, correction, and lode maintenance all reinforce one another. The lode improves the conversation; the conversation improves the implementation; the implementation and its corrections improve the lode.
That upfront work is usually measured in a few minutes, not hours, and in practice it is often far more accurate than trying to write detailed specifications before the session begins. The result is that the end-to-end process accelerates while quality goes up: when the session is done, the work is usually done. You are not left with the false productivity of unattended parallel agents that return a pile of rework, a review backlog, or a fresh documentation backlog. In that sense Lode Coding feels a lot like manual professional development, where the developer receives an incomplete work item, sharpens it through thinking and discussion, and then implements. The difference is that the same discipline is now accelerated rather than bypassed.
Why This Improves Results
Most disappointing AI coding sessions fail for boring reasons:
- the assistant lacked important context
- the user noticed drift too late
- the task was too large and underspecified
- the resulting knowledge was not captured, so the next session repeated the same mistakes
- the engineer progressively loses cognitive ownership
Lode Coding directly addresses all five.
It improves context, encourages intervention, favors smaller steps, and retains the useful information that comes out of the work. None of that is flashy, but it is exactly why it works.
This is also why I think the method scales better than one-shot prompting. The more a project depends on accumulated understanding, the more valuable durable project memory becomes.
Ownership Does Not Go Away
Lode Coding is not about surrendering authorship to the machine.
If anything, it makes ownership more explicit.
You still decide what problem is worth solving, what tradeoffs are acceptable, what architecture fits the system, what code is good enough to keep, and what should be rejected. The assistant can accelerate the mechanical and exploratory parts of development, but it does not inherit responsibility.
That stays with you.
That includes the quieter parts of professional software engineering: judgment, taste, standards, terminology, design philosophy, and the accumulated practices that let you explain and defend your decisions. Lode Coding is meant to keep that professional memory alive and usable rather than letting it dissolve into opaque prompts and disposable sessions.
A useful standard is this: do not accept an outcome unless you are prepared to maintain it without the assistant present.
If the answer is “I would not want this merged under my name,” then the session is not done.
Tools Change, Project Memory Should Not
One reason I like this approach is that it is deliberately tool-agnostic.
The industry will keep changing its wrappers, pricing models, memory features, and preferred workflows. If your project knowledge only exists inside a vendor-specific feature, then your context is rented rather than owned.
A lode is just markdown in the repository. Any capable assistant can read it. Multiple assistants can use it. Future tools can use it. Humans can inspect it. It survives tool churn.
That makes it a better long-term place to put valuable project knowledge.
A Simple Example
Suppose you are building a compiler, a line-of-business web app, or a desktop tool with a few hard-won patterns. You solve a tricky problem around parsing, error recovery, caching, or UI state transitions. The immediate temptation is to move on once the code works.
In a Lode Coding workflow, you do not stop and write that knowledge up yourself. The explanation, implementation, review, correction, and acceptance are already part of getting the work done. As the work progresses, the agent updates the lode with the useful reasoning and decisions so they become durable project memory.
Not as a diary entry. As working knowledge with effectively zero extra effort from the engineer.
For example:
- what the subsystem is responsible for
- which design decisions were deliberate
- which tradeoffs were chosen and why
- which philosophies or working principles shape the solution
- which domain language the project uses and what those terms mean
- which inputs it assumes are valid
- which invariants must remain true
- which failure modes are expected
- which pattern future edits should follow
That pays off later when you return to the code, switch tools, hand the work to another assistant, or ask for a related feature in the same area.
What Makes Lode Coding Distinct
There are plenty of ideas in the broad space of persistent project memory for AI-assisted development. Lode Coding is my name for a version that aims to be unusually effective and unusually low effort.
What makes it different is not merely that it stores project knowledge. It is that the knowledge is maintained by the agent as part of the work, kept close to the code, structured for retrieval, and integrated into a disciplined review-and-ownership workflow. That combination matters.
I still like “lode” because it is short, memorable, and points at accumulated value. The broader category explains the problem space; Lode Coding names a stronger claim about how to solve it well:
- capture what matters
- keep it current
- use it to seed better sessions
- produce better aligned, higher-quality outcomes
- reduce rework instead of pushing it downstream
- strengthen cognitive ownership so professional responsibility and accountability remain intact
- retain ownership of the outcome
A Reasonable Way to Start
You do not need a grand migration plan.
In a mature Lode Coding workflow, the engineer does not stop and scaffold the lode by hand. The model recognizes when no lode is present, offers to create one, and then maintains it as part of the work. If the project is large, most models will suggest initially creating and enriching the baseline lode, leaving further enrichment for later when areas of the system are touched. For greenfield projects the lode is created and enriched from the outset.
In my own workflow, that behavior is automated through a system prompt that tells the agent how to create, maintain, and use the lode. The prompt linked below this article is one concrete example.
That arrangement matters because the lode becomes rich only when the model owns it. When the model is responsible for maintaining project memory, the engineer has to pass knowledge through the model during planning, implementation, review, and correction. That is the real point of the 100% prompting idea: not dogma for its own sake, but a way to ensure the model continuously receives and retains the reasoning, language, standards, and judgments that matter to the goal at hand.
In practice, the baseline lode will usually begin with files like:
summary.mdfor the project at a glanceterminology.mdfor domain languagepractices.mdfor patterns and constraints- focused files for subsystems as the work reveals they are needed
From there, the model grows and refreshes the lode as the project evolves.
If a topic keeps needing explanation, it probably deserves a lode file.
If a session uncovers a rule that future sessions should not forget, it probably belongs in the lode.
If a document is only useful for today’s temporary handover, keep it in a temporary area and do not pretend it is durable knowledge.
Final Thought
The most useful way to think about Lode Coding is as a way to make AI-assisted development faster, sharper, and more ownable without abandoning the responsibilities of professional software engineering.
Its value is not only that the assistant remembers more. Its value is that conversational orchestration produces better aligned plans, higher-quality implementation, less rework, and fewer of the hidden costs that make many AI workflows feel productive while quietly pushing effort downstream.
A few focused minutes spent enriching the session, sharpening the objective, and reviewing the plan can save far more time than they cost. When the session is complete, the work is much more likely to be genuinely complete: not a rough draft for later repair, not a backlog of review debt, and not a pile of detached generated output waiting for someone else to make sense of it.
That is what the lode is for. It keeps knowledge alive, keeps judgment in play, and helps preserve the cognitive ownership that makes accountability possible.
In the end, that is what Lode Coding is trying to protect and amplify: continuity, alignment, judgment, accountability, and software you can still call your own.