For codebases an AI wrote
The AI built it.
Now nobody wants to touch it.
Claude, ChatGPT, Cursor, Lovable, Bolt, Replit, v0 — whichever got you there. It works. But there are no tests, no review, no pipeline, and every change feels like a gamble. Capybari is not another coding assistant. It is the engineering layer your codebase skipped: it reads what exists, plans in plain English, builds on isolated branches, and ships only after you approve.
If the app still only lives in a chat thread, export or push it to git first — Capybari works on a repository.
You know exactly what happened here
The code is not the part that went wrong
You prompted your way to a working product. It does what you needed. But somewhere between the first commit and the last, the process that normally happens — tests, review, a real deploy, somebody who owns it when it breaks — got skipped. Not because you were careless. Because you were moving fast, and the AI made it possible to move fast without any of it. Now it works, you are the only person who understands it, and you are not certain you do.
The history tells on itself
Nothing between "initial commit" and production
Pick the one that is you
It shipped. That was never the hard part.
Shipped with Lovable
It is live and people use it. You have not opened the editor since, because you are not sure what a change would touch.
Cursor got it to production
Working product, real users, and CI never existed. Deploys are you, on a laptop, hoping.
ChatGPT built the MVP
Stripe is the next thing to add, and you do not trust the payments code enough to touch it.
If you could not implement the change yourself either way — you were never the engineer, AI or not — the page for that is here.
Engineering workflow for AI-built software
AI-generated code is not bad code
It is code written without the workflow that makes code safe to change. What it needs is not a rewrite. It needs the things that were skipped:
- Tests that catch a regression before a customer does.
- Review gates that stop a change before it merges.
- A security pass before anything reaches production.
- Isolated branches so parallel work cannot collide.
- A deployment pipeline with a health check and a rollback.
- Somebody watching after it ships, and an investigation when it breaks.
AI-generated codebase management
What Capy does with a codebase an AI wrote
The same pipeline every project gets. What is different here is only that step two has more to read and fewer conventions to rely on.
You attach the repository
Any git remote. Capy works on branches inside your repository — not on a copy in ours.
Capy reads the project
Architecture, the conventions the project actually follows rather than the ones it should, dependencies, and how it fits together. What it learns persists — you are not re-explaining your own codebase every session, which is the tax you are currently paying to a chat window.
You describe the outcome
"Add a monthly plan." "Fix the checkout bug on mobile." "The export button doesn't work." A sentence is enough. You never have to describe how to do it.
Capy plans the change in plain English
A request becomes tasks with an order, an owner and dependencies. You read it and can tell whether it understood you — approve, reject, or say what it missed.
Capy builds and tests it
Each task on its own branch in its own worktree. Tests, code review and a security pass before the merge, not after somebody notices in production.
Capy deploys it — and watches
To your own servers, with a health check and an automatic rollback. If something breaks at 2am an investigation opens on its own, read-only, and writes up the cause.
This is the workflow your AI skipped — not because it could not do it, but because you were not asking it to own the engineering process. That is the job this takes.
What the first week looks like
Small blast radius on purpose
Nothing here requires you to hand over the whole codebase on day one. The point of the first week is one gated change, so you can judge the process on something you chose.
Attach the repository
Read access is enough to start. No deployment target, no server credentials, nothing to configure on your infrastructure.
The first brief: what your app actually is
Architecture, dependencies, the conventions the code really follows, and where the sharp edges are. For a codebase assembled over months of prompting, this is frequently the most useful artefact of the week.
Name the change you have been avoiding
The one whose blast radius you cannot predict. That is the useful test, not a trivial one.
Read the plan and approve it
Tasks, order, owners, dependencies. If it misread the codebase, you will see that here — before anything runs.
One change through the whole gate
Isolated branch, tests, review, security pass, merge, deploy, health check. The first time that codebase has had any of it.
Everything stays on Manual unless you move it. Nothing dispatches on its own while you are deciding whether you like this.
Start with one change you have been avoiding
Read the plan it writes back. Nothing runs until you say so.
A git remote and one request. Nothing else to prepare.
If you already use Cursor, Copilot or Claude Code
Both are useful. The difference is who carries the work.
An assistant makes you faster at doing it yourself, and still needs you in the chair for every decision. Capybari is for when the work is no longer writing code — it is owning the engineering workflow around code that already exists.
| A coding assistant | Capybari |
|---|---|
| Helps you write code | Owns the engineering workflow |
| Needs you at every step | Asks only when it genuinely needs a decision |
| You break down the work | Plans the work, with dependencies and owners |
| You hold the context | Reads the project and keeps what it learns |
| New projects are easiest | Existing, legacy and AI-generated code is first-class |
| Stops when you stop typing | Keeps going while you do something else |
| You check the result | Tests, review and a security pass before merge |
| You deploy and watch | Deploys, health-checks, rolls back, investigates |
| The model is the product | Models are interchangeable intelligence |
Keep using the assistant. This is not a replacement for the thing that wrote your code — it is the process that was never put around it.
You approve. You don't supervise.
Nothing ships that you did not agree to
Four mechanisms, not four assurances — followed through one request: *stop failed Stripe webhooks from double-charging customers*. Each is a thing that happens whether or not you are watching.
It thinks before it changes
A plan before a diff
It does not let agents collide
One branch, one worktree, per task
It has people whose job is to say no
Architecture, security and review are gates
It verifies before shipping
And keeps watching afterwards
Merged 4 branches, no conflicts
Deployed to prod-web-1 over SSH
Health check failed — /healthz returned 503 twice
Rolled back to a3f91c2 — the last commit known healthy
Investigation INV-11 opened automatically
The full model, including exactly what an investigation may and may not touch: the security and governance page.
The autonomy question
A dial, not a switch
Projects start at Manual. Nothing runs until you press the button. Move to Supervised when the plans stop surprising you — planning starts on its own and work you have approved dispatches itself. Reach Autonomous when you trust the gates. Most teams take about three weeks.
Review gates and genuine escalations reach a human at every level. You never have to let it run on its own, and you can always turn it back down.
This is not a tool that asks you to trust it on day one. It earns it over three weeks, on your code, with your approval at every step.
The objections worth taking seriously
Questions about handing over AI-generated code
Can it really work on a codebase that was written by an AI?
That is the case it was built for. Agents read your conventions before they plan, and role contracts instruct every specialist to make the smallest safe change and reuse existing patterns rather than introduce new ones. AI-generated codebases are first-class, not an edge case.
What if the code is genuinely bad?
Capy does not judge it, and it will not quietly rewrite it either. It reads what is there, plans the smallest safe change, and verifies before shipping. If something is too risky to touch, that appears in the plan. You are not required to clean it up first — that is the opposite of the point.
Do I have to give it access to my production servers?
Only if you want it to deploy. Plenty of teams run Capybari for planning and building alone and never connect a server at all. A deployment target is an SSH host you define, with a deploy command, a health check and a rollback command you write. Write access is a separate, explicit grant and is never the default.
What happens if it breaks something?
Your health check fails, your rollback command runs, and an investigation opens on its own. An agent with read-only access reads the logs and diagnostics, writes up the cause, and opens a follow-up request containing the fix. It cannot change your server unless you grant that explicitly.
Is my code used to train models?
No. Your repositories are cloned so that agents can run the work you asked for, and for nothing else. We do not train models on your code, your requests, your plans or your reports. The detail is on the security page.
What does it cost to find out?
Nothing. The free plan carries one project and your own code, with no card required. The plans are here when you want the detail.
Start here
Give Capy one problem and see what comes back
Not the whole backlog. One thing — the fix you keep not doing because the blast radius is unknown, the feature you have been putting off because you would have to touch the part you understand least. Point Capy at the code and describe the outcome. Read the plan it writes back. If it has understood your codebase, you will know from the plan; if it has not, you have lost ten minutes. Nothing runs until you say so.