The first time you use AI on a new codebase, the results are decent but generic. You spend time explaining your conventions, your architecture, your constraints. By the tenth session, the AI knows your patterns. It follows your naming conventions without being told. It chooses the right database access pattern without a prompt. It writes tests in the style your team expects.
That progression is not magic. It is the result of the fourth of five mutually reinforcing pillars in the synthesis coding framework: the self-improving system. Most engineering practices treat the practice as fixed and the project as the thing that changes. Synthesis coding treats both as evolving systems.
This pillar was originally framed as “Iterative Context Building” — the URL of this article preserves that history. Context accumulation is the most visible thread of self-improvement, but it is one of four. The broader framing recognizes that the project, the skills, the instructions, and the practice itself all evolve in parallel.
Four Threads That Compound Together
The self-improving system runs along four threads. They reinforce each other and they fail together when one is neglected.
Context
Every session adds to the project’s accumulated memory. Decisions made, paths considered and rejected, conventions established. CLAUDE.md, AGENTS.md, CONTEXT.md, REFERENCE.md, and session archives capture this so it survives across conversations, across AI tools, and across the people who pick up the project later. Project memory belongs to the project, not to any single AI tool.
One team I worked with documents every architectural decision in a standard ADR format: the decision, the context that led to it, the alternatives considered, and the rationale for the choice. When starting work on a feature, engineers load the relevant ADRs into the AI conversation. The AI then implements following those established decisions without being told each time.
This works because architectural decisions are exactly the kind of information AI needs but cannot derive from code alone. The code shows what was built. The ADR explains why it was built that way, which prevents the AI from making different (and conflicting) choices when implementing new features.
Skills
When you find a better way to do something, you do not just do it. You codify it. Patterns get named and packaged so the AI applies them next time without being re-taught. The skills library grows from a few personal tricks into a serious system of reusable practices.
Another team maintains a collection of prompts that efficiently establish their project context. Starting a new feature? There is a context prompt that loads the database patterns, API conventions, testing approach, and deployment requirements in a single message. Starting a new service? A different prompt loads the service template, inter-service communication patterns, and observability standards.
These prompts are maintained like code: version controlled, reviewed when they change, updated when the patterns evolve. They are shared across the team so that every engineer starts from the same context baseline. Over time, the most useful prompts get promoted into proper agent skills — installable instruction packages that work in every AI tool the team uses.
Instructions
The files that tell each AI tool how to work in this project get refined every time the AI does something wrong. If the AI keeps making the same mistake, the instruction is the bug, not the AI.
Teams that treat their CLAUDE.md and AGENTS.md as living documents — updated whenever a particular failure recurs — converge on a stable instruction set that prevents the same class of mistake from showing up again. The first time the AI uses tabs instead of spaces, the convention goes into the file. The first time it skips writing tests for a particular kind of function, the rule goes into the file. After enough iterations, the instructions encode the team’s hard-won understanding of how to make the AI productive on this codebase.
Practice
The discipline of synthesis coding itself improves through everything above, plus what gets shared with other practitioners. Improvement happens at four scales at once: the current project, the team’s shared playbook, the practitioner’s craft, and the discipline as a whole.
The compounding effect within a project is dramatic when measured. A team I worked with tracked it informally. The first feature they built with AI took about 80% as long as their traditional approach. Not much savings, and some of that was eaten by the learning curve. The fifth feature took 50% as long. The tenth feature took 30%. The context they had accumulated — documented conventions, established patterns, refined prompts, sharper instructions — made each subsequent feature faster to build correctly.
This is the opposite of how most teams use AI. Most teams treat each conversation as independent. They re-explain their architecture every time. They fix the same convention violations repeatedly. They never capture what worked so it can be reused. Each conversation starts from scratch, and the productivity gains plateau at whatever the AI can figure out from a cold start.
The Feedback Loop
The four threads are not one-way streets. The AI is not just consuming context, skills, and instructions — it is also producing material that feeds back into them. When AI generates a solution that works well, that solution becomes a pattern the team can codify into a skill. When AI generates something that needs correction, the correction reveals a convention that was not explicit enough — which then goes into the instructions. Both outcomes improve the system for future work.
The teams that compound fastest are the ones that treat this feedback loop deliberately. After a productive session, they ask: what did the AI get right that we should codify? What did it get wrong that reveals a gap in our documented conventions? The answers go into the skills library, the ADRs, the project files. The next session starts from a higher baseline.
The Plateau Problem
Without a self-improving system, AI-assisted development hits a productivity plateau. The AI gets you 20-30% faster on routine tasks — code generation, boilerplate, test scaffolding — but it never gets better because it never learns your specific patterns, your specific failure modes, your specific conventions. Every conversation is the AI meeting your codebase for the first time.
With a self-improving system, there is no plateau. The compounding continues as long as you keep investing in the four threads.
The limit is not the AI’s capability. It is your team’s discipline in evolving the context, the skills, the instructions, and the practice that make the AI effective.
That discipline is the difference between a team that uses AI tools and a team that practices synthesis coding.
How This Pillar Connects to the Others
The self-improving system is what makes Transferable Knowledge, the fifth pillar, operationally meaningful. Knowledge that does not get encoded back into the system is knowledge that does not actually transfer. Skills, instructions, and project memory are the artifacts through which one engineer’s understanding becomes the team’s understanding — and through which one project’s lessons become the practitioner’s craft.
It also loops back and strengthens Human Architectural Authority, the first pillar. The architectural decisions you make on your next project are sharper because the lessons from this one got encoded and carried forward. Patterns you learned at the cost of a painful production incident become guardrails the next project never has to discover by accident. The human at the center keeps getting better at the part that is hardest to automate: judgment.