turri is the first coding agent with the power of regenerative software. It gives you back control over engineering while the agent handles the coding. Instead of maintaining code, you maintain the system's definition (specs, tests, and ADRs) structured using ***plain. You describe what you want, turri captures it as a durable, reviewable system definition, and generates the code from it. As your intent evolves, turri regenerates the affected code rather than patching it prompt after prompt. The system definition remains the source of truth, and tests verify that the generated code conforms to it.
Code is disposable, system definition is durable.
turri is named after Turritopsis dohrnii, the immortal jellyfish that regenerates itself from its young form, again and again - as turri regenerates the code from the durable intent - see the name.
turri has a desktop app too: turri desktop.
Quick start
turri is built on pi and runs on macOS, Linux, and WSL (native Windows via Git Bash is best effort). You'll need Git, Bash, and Node.js 22.19+.
Install
npm install -g @turri-dev/cli turri doctor
turri doctor checks your environment and tells you how to fix any missing dependencies. See the installation guide for details.
Configure your models
turri uses a capable model to define the system and plan the work, and a smaller, cheaper model to write the code. It supports any model provider available through pi, and some subscriptions too.
mkdir my-project && cd my-project turri init-config
Choose your model provider, then sign in with /login once turri has started.
Build your first app
Then simply describe what you want:
Build a small API where users can register and sign in.
turri captures your intent in ***plain, generates the code, and validates it against the system definition.
As your requirements evolve, just describe the changes. turri updates the system definition and regenerates the affected code.
Other ways to run turri
Prefer a graphical interface? Try turri desktop.
You can also run turri in Docker, or from a clone to follow main or work on turri itself.
For more, see Using turri and Examples.
From a clone
To run the local version of turri instead of the npm package:
git clone git@github.com:turri-oss/turri.git && cd turri npm install npm link # puts `turri` on your PATH, pointing at this clone turri doctor
The clone runs its TypeScript sources directly, so there is nothing to build. To pick up new commits, run git pull and npm install, then start turri again - a running one keeps the code it started with. More in the installation guide.
Why
Coding agents write in minutes what used to take teams weeks. But while coding got faster, our ability to understand and review code didn't. We increasingly become accountable for software we don't fully understand.
Software built with coding agents grows prompt after prompt, patch upon patch. Decisions and reasoning get lost in chat sessions, misunderstandings accumulate in the code, and each change builds on top of the last. Eventually, neither the developer nor the agent fully understands the system anymore.
Better models and more elaborate agent workflows don't solve the fundamental problem: code remains the source of truth, and humans are expected to understand and maintain something they can no longer meaningfully review.
Regenerative software flips the traditional model of software development. Instead of maintaining code and trying to preserve the reasoning behind it, we maintain the system's definition and regenerate the code from it.
With turri, you engineer the system's definition instead of maintaining its implementation. The agent writes the code, but you retain the understanding and control over what gets built.
The goal isn't to write code faster. It's to understand your software again.
For the story behind turri, read Why I built turri.
Code is disposable
1. Define
Describe what you want to build or change. turri captures your intent as a structured system definition using ***plain, including specifications, architectural decisions, and tests.
2. Review
Review the system definition before implementation begins. Make sure it describes what you actually want, without getting lost in implementation details.
3. Regenerate
turri generates code from the approved definition. When requirements change, it regenerates the affected parts of the implementation rather than accumulating patches on top of existing code.
4. Prove
turri verifies the generated implementation against independently defined tests. The coding agent cannot change the tests to make its implementation pass. If validation fails, turri iterates until the implementation conforms to the definition.
The name
turri is short for Turritopsis dohrnii, the immortal jellyfish, which, when injured or old, turns back into its young self and regenerates - the same jellyfish, from the same genes, again and again.
That is what regenerative software asks of software, and what turri does:
| Turritopsis dohrnii | turri |
|---|---|
| Its genes are what it is: every generation develops from the same ones. | ***plain is what the software is: every generation of code is regenerated from it. |
| Injured or old, it does not patch itself: it goes back to the polyp and regenerates the adult. | Code that has drifted is not patched prompt after prompt: it is regenerated from ***plain, as much of it as has to be. |
| Every cell can become another, and it is still the same jellyfish. | Every line of code can be replaced, and it is still the same software - because what it is never lived in the code. |
| It can do it again and again, for as long as it lives. | The code can be regenerated whenever ***plain changes or a model gets better, for as long as ***plain is kept. |
So the tools speak its language: regenerate regenerates the code from ***plain as it is now - or the functionalities you name, though nothing changed, or all of it from scratch - drift says how far the code has moved from it, and lineage shows every generation of a module and what each was regenerated from.
Models
init-config's models are only a starting point. turri is built on pi, so any model pi supports works - Anthropic, OpenAI, Google, Amazon Bedrock, OpenRouter, a local one. A model is reached as pi reaches it - /login, in turri as in pi, the provider's API key in the environment (ANTHROPIC_API_KEY, OPENAI_API_KEY, GEMINI_API_KEY, ...), or a cloud account - and named as pi names it, provider/model-id, with :high, :low and so on for how hard it thinks. It uses three: the harness model you talk to, which writes ***plain and plans the work - worth a capable one - and the coding and judge models its agents build and judge with, which can be smaller and cheaper, such as GPT-6 Luna or Gemini 3.1 Flash Lite. turri --harness-model and --coding-model choose them for a session, and pi's /model switches the one you talk to as you go; to keep them for the project, set them with /turri-config harness-model, /turri-config coding-model and so on - each role's too, as models.<role> - or write them in its config.turri.yaml:
harness-model: anthropic/claude-opus-5-5 # the model you talk to: a capable one coding-model: openai/gpt-6-luna # writes the code and the tests: a smaller one will do judge-model: google/gemini-3.1-flash-lite # judges the conformance runs
One left out is the one before it: judge from coding, coding from harness. Every way to set them: models.
Use
In the project where your ***plain lives:
Then say what you want:
A small API where people can register and sign in, in Python.
In a new project turri starts it itself, without asking how: it chooses the stack - the one you name, else a standard library stack this machine can build - writes the module and its unit testing script (and the conformance tests' when you ask for them, or the test advisor finds a functional spec that needs them), regenerates the smallest thing that runs at once, then the main thing you described, and says what it chose and what it would write next. Every change after is yours to ask for: turri writes it as ***plain and regenerates it. While it works:
- the panel above the input shows every build - its stage, what its agents are doing, its model and cost - and the queue behind it;
- ask to try it at any time - "let me try it" - and
releaseputs what is built so far indist/<module>andactivatestarts it, installing what it needs - nothing to approve; - the side panel (
ctrl+h) takes the screen and opens on regen - ***plain, every item marked planned, working, regenerated, validating, conform or needs you - andpturns it to the pulses (/pulses) - every pulse, running, queued and finished, and what each regenerates; what its agents did is in each pulse's log in.turri/jobs/, kept with--debug(debug: true); /halthalts a pulse,/lineageshows every generation of a module, and thedrifttool says what is left to regenerate;/btw <question>asks turri something on the side - answered at once, even while a question waits for you (typed as the answer, under "Something else…"), and left out of the conversation;/turri-configchanges any setting of the project'sconfig.turri.yaml- the models, review, the test advisor, how many pulses at once - and says when it takes effect: now, at your next message, or at the next pulse. No restart:/turri-config review false, or/turri-configalone to pick from the list;/sentinelsays whether the sentinel checks every pulse that finishes:ask(you are asked before it first opens),onoroff;/stackchooses the stack to build with, in a project whose backend and frontend each have their own testing scripts inconfig.turri.<stack>.yaml-/stack backend,/stack none- for the session (--stack <name>on the command line). The chat's model builds each part with its own stack by itself, pinned to that module's pulses.
Other things to ask for:
Add password reset to ***plain.
Regenerate the whole module, and conform every functionality with conformance tests.
Regenerate changes to ***plain with a faster model.
The last one holds for the rest of the session; the model can be chosen separately for changes to ***plain and for functionalities, and a name that fits more than one model is asked about rather than guessed.
Without a conversation, the same work is on the command line:
turri parse app.plain # parse ***plain, its syntax and structure - no model, no API key turri drift app.plain # what is left to regenerate - starts nothing turri regenerate app.plain # regenerate the code from ***plain: planned into jobs, run until it is done turri regenerate app.plain app:add-task # regenerate one functional spec again, changed or not
More: using turri; to regenerate ***plain overnight, see running unattended.
Documentation
Start at the documentation index, or go straight to a page:
| Installation | doctor, what turri needs of this machine, turri and pi, environment variables |
| Examples | projects to build with turri step by step: guestbook - a backend and a frontend in minutes - a CLI, and a backend service tested where it matters |
| Using turri | the conversation, skills, tools, pulses and regen, choosing models, the command line |
| The project config | config.turri.yaml and each stack's config.turri.<stack>.yaml: every key, models and their inheritance, conformance, the testing scripts, stacks and choosing one, the old config.yaml |
| Deploy | trying what is built: the last commit in dist/<module>, started on your machine, nothing installed without asking |
| Running unattended | regenerating ***plain overnight or in CI: the command, keeping it running, the results, resuming, rebuilding one functionality |
| Authoring ***plain | what ***plain is made of, the authoring rules, the skills that write and fix it, checking it |
| Regenerating | what each build does and in which order: functionalities, modules, regeneration, changes to ***plain, conformance and acceptance tests, working notes, what the code is built from |
| The sandbox | what agents can reach, the walls every command passes, time limits, the web tools |
| Skills and gates | the gate syntax, what the harness enforces, judges, rules |
| The ***plain parser | the TypeScript port, turri parse, fidelity to the reference parser |
| Theming | the two brand themes |
| Development | tests, layout, known edges |
| Contributing | reporting a bug, making a change, the conventions a pull request follows |
| Security | reporting a vulnerability, privately |
License
turri is open source, under the MIT licence.
