A software factory, in the sense Ivy Tendril uses the term, is a fixed sequence of stages with checkpoints that turns tickets into pull requests. A ticket or idea enters. An agent writes a plan. A human reviews and approves the plan. Agents execute it in isolated git worktrees. Automated verification runs tests, lint, and a diff inspection. A human reviews the resulting diff. A pull request is opened. The sequence is the same for every task, while the agent and model can change per task. There are exactly two human checkpoints, at the plan and at the diff, and nothing merges without sign-off.
The stages
Create plan
The input is a sentence typed into Tendril, a GitHub issue or jam.dev bug report received through a webhook, a voice note transcribed with Whisper, or files dropped into the prompt. The CreatePlan promptware reads the codebase and writes a plan: what to change, where, and how to verify it.
Draft
The plan is stored in Drafts. Nothing has been executed. It waits there until a person reads it.
Plan review
This is the first checkpoint. The reviewer reads the plan and does one of five things: approves it, runs ExpandPlan for more detail, runs SplitPlan to turn one large plan into several small ones, runs UpdatePlan to change it, or comments inline on the draft, after which the plan is rewritten. A plan that is not worth doing now goes to the Icebox.
Execute in worktrees
On approval, the ExecutePlan promptware starts the chosen agent, Claude Code, Codex CLI, Copilot CLI, Gemini CLI, OpenCode, or any other CLI agent, in its own git worktree on its own branch. Many plans execute at the same time. The Jobs view streams each agent's output. The main branch is not touched.
Verify
Tests, lint, and a diff inspection run against the worktree, and the results are attached to the plan. On Pro and Enterprise, verification results can also be imported from CI.
Diff review
This is the second checkpoint. The Review view shows the diff in one tab and the verification results in another. The reviewer approves, or updates the plan and runs it again.
Pull request
The CreatePr promptware opens a pull request on GitHub with a description of the change. Merging happens in GitHub as usual. Token usage and cost for the plan are recorded on the Dashboard.
Why two human checkpoints and not zero or ten
Zero checkpoints means an agent commits to main. Errors are discovered after they affect other people, and reverting a merged change costs more than reviewing it would have. It also means that the person accountable for the code never read it.
Ten checkpoints means approving each file edit or tool call. The human becomes the slowest step, agents wait for clicks, parallel execution gains nothing, and reviewers stop reading and start approving by habit.
Two checkpoints puts a person where their judgement changes the outcome most. The plan is where a misunderstanding is cheapest to correct: no code exists yet, and a plan is a page of text. The diff is where correctness is confirmed: verification has run, the change is complete, and a human decides whether it merges. Everything between the two is automated and produces a record. The lifecycle docs describe each transition.
What changes for a team
Throughput. Because plans execute in parallel and the human only appears at two points, a team's output is limited by review capacity rather than by typing speed. Ivy reports that its own team went from roughly 10 to more than 100 pull requests per day after adopting the workflow.
Predictability. Every task passes through the same stages, so status means the same thing for every task. The Dashboard shows how many plans are in each stage, cost per plan, a cost trend chart, and git activity. Estimating becomes counting plans in each stage rather than asking each developer how it is going.
Knowledge that accumulates. Each stage is run by a promptware unit: a Program.md with instructions, a Memory/ directory of learnings, Tools/ with scoped permissions, and Logs/ of every execution. Built-in promptwares are CreatePlan, ExpandPlan, ExecutePlan, UpdatePlan, SplitPlan, CreatePr, and CreateIssue. After a run, agents write what they learned about the codebase back to memory and revise their own program. The tenth plan against a repository runs with knowledge the first one did not have. Read more in promptware: agents that improve their own instructions.
What a software factory is not
- It is not autocomplete. Autocomplete suggests the next line while a person types; a factory takes a ticket and returns a reviewed pull request.
- It is not a chat window. A chat session has no queue, no isolation, no verification step, and no memory beyond the conversation.
- It is not an unattended agent that commits to main. Nothing merges without a person approving the plan and the diff.
- It is not a replacement for code review. It is a structure that puts review at the two points where it matters most.
- It is not a hosted service that holds your code. Tendril is local-first: code, plans, memory, and logs stay on your machine, and the only external calls are to the LLM API you choose and to GitHub.
- It is not tied to one agent or model vendor. You bring your own keys and switch per plan.
The eight levels
Steve Yegge's "8 Levels of AI-Assisted Development" (2025) is a useful reference for where a team is. Most teams are at levels 2 to 3: an assistant in the IDE and a single chat. Orchestration with parallel agents, memory, and review gates is level 8. The table below is our paraphrase of those levels, mapped to what a team runs day to day; read his essay for the original definitions.
| Level | What the team actually runs |
|---|---|
| 1 | No AI. Developers write and review all code by hand. |
| 2 | Autocomplete in the editor. Suggestions accepted line by line. |
| 3 | A chat assistant in the IDE. One conversation, one developer, one function at a time. Most teams are here. |
| 4 | An agent in the IDE that edits several files from one request. The developer watches and accepts. |
| 5 | A CLI agent in a terminal, given a task and left to run. One task at a time; the developer checks the result. |
| 6 | Several CLI agents in several terminals. The developer coordinates by hand, and two agents editing the same checkout is a weekly event. |
| 7 | Agents with a defined workflow and review gates, usually in a home-built tool. Memory is maintained by hand. |
| 8 | Orchestration: parallel agents in isolated worktrees, persistent memory, two review gates, and a queue of plans. This is what Ivy Tendril runs. |
Moving from level 3 to level 8 is not a matter of a better model. It is a matter of structure: worktrees, verification, memory, and two checkpoints.
How to start
Install Tendril on macOS or Linux:
curl -sSf https://cdn.ivy.app/install-tendril.sh | sh
Or on Windows:
irm https://cdn.ivy.app/install-tendril.ps1 | iex
Then connect a GitHub repository, add an API key for one model provider, and pick an agent. Create a plan from one small ticket, read the draft, approve it, and review the diff when verification finishes. When that first pull request has merged, create three plans at once and watch them execute in parallel. The installation guide covers each step.
Frequently asked questions
Does a software factory remove code review?
No. It moves review to two defined points, the plan and the diff, and puts verification results next to the diff so the reviewer has evidence, not only a change. Every pull request is still approved by a person.
Which agents can run inside it?
Claude Code, OpenAI Codex CLI, GitHub Copilot CLI, Google Gemini CLI, OpenCode, and any other CLI agent. You can switch agent or model per plan without changing the stages.
Is Ivy Tendril free?
Yes. The application is free and source-available under FSL-1.1-ALv2. Pro at $59 per user per month adds team features, on-prem hosting, SSO, verification imports from CI, and support; Enterprise plans are also available. See pricing.