1. Work the task
The agent edits, runs tests, and opens a PR — and notes the conventions it hit along the way.
The agent gets better at your repo over time
How the agent learns
Most coding agents start every session from zero. 0dai keeps a project memory on disk in the ai/ directory. Each session reads what earlier sessions recorded about the codebase, so the next task starts where the last one left off.
Illustrative model. The timeline and charts below show the shape we expect as project memory builds up on a repo. They are an example, not measured customer data. We will publish real numbers once we can stand behind them.
Compounding context
Each session builds on the last
When the agent finishes a task, it writes what it learned about the repo to a project memory on disk: the test layout, naming rules, the error-handling style. The next session reads that memory before it touches a file. Nothing is re-derived from scratch, so the second week of work costs less review time than the first.
2. Record to memory
Those notes land in ai/ on disk, scoped to the project and versioned with the repo.
3. Read it back
The next session loads that memory first, so it starts already knowing how the codebase is written.
The first three weeks
From cold start to settled in
An illustrative arc on a single repo. Day 1 is a cold start — larger PRs, more review cycles. By Day 21 the agent matches the repo's patterns, so PRs are smaller and clear review faster.
- 1Day 1
Cold start
The agent reads the repo from scratch. It guesses at file layout and naming, so PRs are larger and reviewers send them back more than once.
~9 h to merge3-4 review rounds - 2Day 7
Picking up the house style
Project memory now holds the import order, the test layout, and a few naming rules. New diffs need fewer corrections.
~6 h to merge2-3 review rounds - 3Day 14
Matching conventions
The agent reuses error-handling and test patterns it recorded earlier. PRs land closer to how a regular contributor would write them.
~4 h to merge1-2 review rounds - 4Day 21
Settled in
Generated changes read like the rest of the codebase. PRs are smaller and scoped, and most clear review on the first pass.
~3 h to merge~1 review round
Illustrative figures — see the note at the top of the page.
Trends
The shape, in three lines
Two metrics fall as the agent stops re-learning the repo; one rises as it records more of how the codebase is written. Each chart is an illustrative model over the same three-week window.
Goes down
PR cycle time (hours)
Time from first commit to merge. Falls as the agent stops re-deriving the repo's structure each session.
Goes down
Review rounds per PR
Back-and-forth before approval. Drops as generated diffs already match the team's conventions.
Goes up
Patterns learned (cumulative)
Style, naming, and test rules the agent has recorded in project memory and reuses on the next task.
What it records
Four things the agent keeps
Project memory holds the conventions that make a diff read like the rest of the repo. Four of them carry the most weight.
Code style
Import order, line width, where helpers live, when to extract a function versus inline it.
Naming
How the repo names variables, files, and routes — and which abbreviations it refuses.
Test conventions
The test framework, the fixture layout, and whether new code ships with a test in the same PR.
Error handling
Whether the repo throws, returns a result type, or logs and continues — and the shape of its error messages.
Example task-log lines
- Session 127: learned the repo destructures props at the top of each component.
- Session 131: tests live next to the file as name.test.ts, not under __tests__/.
- Session 140: API handlers return a Result type; do not throw across the boundary.
Illustrative lines, in the format the CLI writes to project memory.