AI agents build the feature. You decide when it ships.
Describe what you need in plain text. BuildBit plans it, builds it on its own branch and tests it against your real git repository. Nothing is built before you approve the plan, and nothing is merged before you click.
Run it on your own servers with the AI you choose, even a model on your own hardware, or let us host it in EU data centres.
Early access for teams. You'll get one email to confirm, then only updates about BuildBit.
Example run: invoice export
-
You
Accounting wants to export invoices for a date range as CSV that opens straight in Excel.
-
Architect agent Plan v1
- Approach
- A new export endpoint that reuses the invoice list's filters and streams the rows.
- Decision
- Semicolons and a UTF-8 BOM, because German Excel opens a comma file as one column.
-
You
Approve plan
-
QA agent Report v1
- Build Passed 0 warnings, 0 errors
- Test suite Passed 214 passed, 0 failed
-
You
Merge now
Coding agents are powerful. Supervising them is hard.
An agent in a terminal leaves you with a wall of text and one question: can you trust the result? BuildBit turns that around. The plan comes before the code, the test report comes before the merge, and both are still readable months later.
Plan first, code after
The architect agent reads your real code and proposes a plan. Implementation only starts when you approve it.
A report you can check
Every change comes with a list of individual checks and the evidence for each one.
Each agent has one job
The agent that plans can't write code, and the agent that tests can't fix anything.
A complete history
Every status change is stored with who triggered it, when and which agent run it belongs to.
How a feature gets built
Two of the six steps are yours. Everything in between runs on its own.
-
You
Describe what you need
Write it the way you'd tell a colleague. BuildBit asks follow-up questions and suggests how to split the work into features. Bug reports get a diagnosis step first that tries to reproduce the fault.
-
Architect agent
Get a plan
The plan names the approach, the affected parts of your code, its decisions and the risks, with a diagram and screen designs when the change needs them.
-
You
Review the plan
Highlight any passage to ask a question, answered right there without a new version. Or leave change requests, which go back as a new version of the plan.
-
Developer agent
It gets built on a branch
Each feature gets its own branch. The developer agent writes the code and its tests there and builds it, but never touches your main branch.
-
QA agent
It gets tested
Build, tests, a check in a real browser when your project has a UI, and a comparison with the approved plan. If a check fails, the work goes back to the developer agent with the report.
-
You
Merge or send it back
One click merges and pushes. Not happy with the result? Ask for changes and it goes back into development.
Every change comes with a QA report
Not a green light that hides the details. Each check is listed with what was run and what came out, including the ones that passed.
QA report, version 2: invoice export
| Check | Result | Evidence |
|---|---|---|
| Build | Passed | dotnet build: 0 warnings, 0 errors |
| Test suite | Passed | 214 passed, 0 failed, 0 skipped |
| Semicolons and BOM are covered by tests | Passed | UsesSemicolonSeparator, WritesUtf8Bom: passed |
| Row limit | Passed | 10,001 rows return HTTP 400 instead of a cut-off file |
| Export in the browser | Passed | Filtered by month, clicked Export, 1,284 rows downloaded. Screenshot attached |
| Matches the approved plan | Passed | All 3 decisions implemented, no new package added |
Version 1 failed the row limit check: the file was silently cut off at 10,000 rows. That report went back to the developer agent and is still kept.
- Reports are kept for good, also after the feature is merged.
- A new QA run adds a new version. Failed versions stay readable.
- The QA agent can't edit code. It builds, tests and judges. Fixing is the developer agent's job.
Guardrails built into how agents run
An instruction in a prompt is a request. BuildBit's limits are enforced by the system on every run, so they hold even when an agent gets something wrong or is misled by content in your repository.
Tools per role
Every agent gets exactly the tools its job needs. No agent can go from plan to merge on its own.
A fresh container per run
Each run starts in a new, single-use container with a fresh copy of the code and is removed afterwards. Nothing carries over between runs or projects.
Only you can push to main
The push to your main branch is the one step that can't be undone. It runs from BuildBit's own code right after your click, with no AI involved. Agents never have push credentials.
One branch per feature
An agent works on its feature's branch and nowhere else. If something goes wrong, the damage stays on that branch.
Everything is recorded
The full transcript of every run is kept, including the actions that were blocked. You can see what an agent tried, not just what it managed to do.
Limits on time and money
Every run has a time limit, and a monthly budget pauses new runs when it's reached. You can also pause any feature yourself.
| Who | Can | Can't |
|---|---|---|
| Architect agent | Read the code and propose a plan | Change any file |
| Developer agent | Write code and tests, build on its branch | Run the tests or push to main |
| QA agent | Build, run tests, check the UI in a browser | Edit any code |
| Merge | Merge and push, without AI | Run before you click "Merge now" |
| Every agent | Use the tools of its role | Push, change the git remote or the git configuration |
Built for the GDPR
Choose where BuildBit runs and which AI it works with. Run it on your own servers with a model on your own hardware, and your code never leaves your network.
Any AI provider
Use Claude Code, an OpenAI subscription or another provider, per project and per agent. No markup: you see what every run and every feature cost.
Models on your own hardware
Connect an open model running on your own servers. Code, prompts and answers stay inside your network.
Your repository
BuildBit works directly on your git remote. No import, no copy.
Your stack
Anything that runs in a container works: Node, Python, Go, Java, .NET or a mix, including tests that start their own containers.
| Setup | Code and history are stored | Model calls go to |
|---|---|---|
| Your servers, local model | On your servers | Your servers Nothing leaves your network |
| Your servers, cloud AI | On your servers | The provider you choose |
| Hosted by us | In EU data centres | The provider you choose |
What teams use it for
Working through a backlog
Many small, clearly scoped tickets run at the same time while you work on something else. You step in at the two points that matter.
Fixing bugs from a description
Describe the fault and get back a fix that was reproduced first and tested afterwards, with the cause written down.
Trying agents on real code
Use AI agents on your actual repository while approval and merge stay with you.
Questions
What teams usually ask before they try BuildBit.
Can an AI write to my repository unchecked?
No. Agents only work on their own feature's branch. The push to your main branch happens only from BuildBit's own code after you click "Merge now".
Agents never have push credentials, and push, remote and config commands are blocked for every agent.
How much do I have to read before I approve?
The plan is short and always has the same parts: the problem, the approach, affected areas, decisions, risks and scope.
If something is unclear, highlight it and ask. A read-only agent answers right there, without creating a new version of the plan.
What happens if I don't approve a plan?
Nothing. The feature waits until you decide, for as long as it takes. No agent runs while it waits, so waiting costs nothing.
What if an agent goes in circles?
Every run has a time limit, and the monthly budget pauses new runs once it's reached. You can also pause any feature yourself at any time.
A paused feature keeps its place and continues where it stopped when you resume it.
Where does my code go?
BuildBit stores your code, plans, reports and transcripts where it runs: in your own Kubernetes cluster, or in your own instance in an EU data centre when we host it.
The agents send code only to the AI you connect. With a model on your own hardware, it never leaves your network.
Agents can also read the web, but they're instructed never to send your code or credentials anywhere else.
Is BuildBit GDPR-compliant?
Yes. Run it on your own servers and everything BuildBit stores stays with you. Our hosted version runs only in EU data centres.
For the strictest requirements, connect a model running on your own hardware. Then no code, prompt or answer leaves your network. See where your data goes in each setup.
Can I report bugs the same way as features?
Yes. A bug first goes through a diagnosis step that tries to reproduce it and records the cause. After that it follows the same path as a feature.
If it can't be reproduced, that result stays attached as context and doesn't block anything.
Can I skip the approval for small changes?
Yes, per project. With automatic approval turned on, a plan with no open questions or change requests is approved as soon as it's ready. It's off by default.
Merging always needs your click.
Does BuildBit open pull requests?
No. BuildBit pushes each feature's branch to your repository. After you click "Merge now", it merges that branch into your main branch and pushes it.
Your CI runs on those pushes the way it always does.
Can several features run at the same time?
Yes. Every agent run gets its own container, so many features can be in progress at once. You can set a limit on simultaneous runs, and runs above it wait for a free slot.
Merges into the same main branch happen one after another.
What happens when the merge runs into a conflict?
An agent merges your main branch into the feature branch, resolves the conflict and pushes the feature branch only.
The result goes through QA again before "Merge now" is offered.
Which git hosts work?
Any git repository BuildBit can reach over HTTPS, for example on GitHub, GitLab or Azure DevOps. You add an access token for each project.
One project is one repository. A monorepo works as a single project.
Which languages and tools are supported?
Anything that runs in a container. Build and test commands are plain text in your project settings, and the container image can be extended with whatever your build needs.
If a tool is missing, the agent reports it and BuildBit suggests the change to the image.
Which AI models can I use?
The one you choose. BuildBit works with Claude Code, an OpenAI subscription, other providers and open models running on your own hardware.
You can choose per project and per agent, for example a different model for planning than for writing code.
What does a feature cost?
It depends on its size. BuildBit shows the cost of every run and adds it up per feature, so after a few features you'll know what to expect.
Model usage is billed by your AI provider to your own account. A model on your own hardware has no usage fees.
Is the app available in German?
Yes. The app is available in German and English.
How do I get access?
BuildBit is in early access. Join the waitlist and we'll get in touch when there's a place for your team, hosted by us or on your own infrastructure.
Get early access
BuildBit is being tested with a small number of teams. Join the waitlist and we'll let you know when there's a place for you.