Your coding agents can write the code.
The hard part is knowing what to trust.
BGOOD Driver is a free and open-source orchestration engine for coding agents that runs in your repository. It decides what is safe to delegate, verifies each stage against repository evidence, and stops when a person needs to decide. It is in closed beta, and we are looking for teams already running agents against real repositories.
You keep control of merge and deployment. BGOOD Driver takes on the mechanical supervision work in between.
BGOOD is the product family. Driver is its local delivery engine; any future, optional enterprise management layer would be a separate external surface, not a product available today.
Does this sound familiar?
You still have to drive every step.
Start the story, watch the session, notice the stall, restart the work, and kick off the review yourself.
A green suite can still validate the wrong thing.
Tests can pass while the specification contradicts itself or quietly drifts from what was asked.
Finished-looking is not the same as finished.
An agent can report success without proving that the committed result is complete, reviewable, and the one that was actually checked.
More agents can mean more supervision.
Increasing agent volume increases coordination, recovery, and review effort unless the workflow can carry its own evidence.
The orchestration engine around your agents.
Your existing agent still writes the code. BGOOD Driver runs the delivery process around it: choosing eligible work, launching each stage, checking validated handoffs and repository state, resuming bounded failures, and parking the decisions that need a person.
Before
A story is sized and checked for contradictory or oversized scope before an agent is dispatched.
During
Each stage must produce the evidence its next stage needs; a timeout costs a stage, not the whole story.
After
Completion is established from the verified commit and its repository evidence, not from an agent saying “done.”
A first pilot is a low-risk bug fix or isolated feature in an existing repository—small enough to review, real enough to expose where the machinery is wrong. The outcome to assess is a reviewed candidate change with its repository-grounded execution evidence. BGOOD Driver works around your existing harnesses, tests, CI, pull requests, and review practice.
Apply for the early-access pilotWhy BGOOD exists
I wanted to queue a sprint on a Friday and read a pull request on Monday. That was the whole of it.
Even with a good workflow framework, I was still the one invoking every step, watching for stalls, and deciding whether what came back was finished or merely finished-looking. Automating the sequence for throughput would remove the reviewer along with the driver, because an agent reports success the same way whether or not it succeeded.
Writing the code stopped being the constraint. Checking it became the job. The mechanical questions — did the story make sense, did its criteria contradict each other, did the tests run against the commit under review — have right answers. They should not consume the attention needed for design, architecture, and the decisions that have no mechanical answer.
That is what everything here that looks like governance is: machine- executable checks grounded in the repository, evidence instead of assurances, and a refusal to call something done that has not been measured as done. A machine vouching for a machine is the problem, not the solution.
More throughput is the intent. Whether it materialises on your work is something to measure, not something for us to claim.
The controls are not the point. They are the price of the point.
Join the early-access pilot.
If your team is already running coding agents against real repositories and feeling what it costs to supervise them, we would like to run one bounded story with you and learn where the machinery is wrong. This is an early-access pilot, not a sales demo: there is nothing to buy, and your team keeps merge and deployment authority. BGOOD Driver runs locally in your repository while we learn whether it earns a place in your process.
Questions worth asking
Answered from what BGOOD Driver does today, not what we intend it to do. The product boundary and the gaps are stated plainly.
Before the pilot
BGOOD Driver is in closed beta, and we are inviting a small number of teams to test the local engine on real work.
- Can I use it today?
- Not yet. BGOOD Driver is available to selected closed-beta pilot teams, not through a public install. We’re looking for teams ready to try it on real work in their own repository.
- Is BGOOD Driver free and open source?
- Yes. Driver is the free, open-source engine that runs in your repository. A future optional enterprise layer will provide cross-project management and governance, but Driver remains usable without it.
Whether the machinery can be trusted
The questions we would ask first, and the ones the code was mostly written to answer.
- Doesn't TDD already solve this?
- TDD is valuable, but tests can only prove that code matches the specification they test. BGOOD Driver also checks whether the work itself is coherent before implementation, so a contradictory requirement can be caught before it produces confidently wrong code.
- How can I trust an agent that writes its own tests and its own review evidence?
- You do not have to take an agent’s word for it. Driver requires evidence that the work meets the agreed criteria before it moves on; when it cannot establish that, it stops the work for correction or review.
- What stops a plausible but incomplete result from passing?
- Driver checks that the work is ready before it starts and that the reviewed change is the change that was actually verified. A convincing status update or a green command alone is not enough.
- If one model family judges its own work, isn't that a monoculture?
- It can be. Where independent judgement matters, Driver can use a different model or harness and records what actually ran, so reviewers can see whether the checks were genuinely independent.
- How does it know a story is done rather than looking done?
- Completion is measured, not claimed. Driver ties its evidence to the exact change sent for review and stops if that change has moved underneath it.
- Your gates run inside the agent's worktree. Can they actually see what was committed?
- Not automatically. Driver verifies the committed result separately, so a reviewer is not asked to trust what happened only inside an agent’s working area.
- What happens on a timeout?
- Driver retries only the failed step. Work from earlier steps is preserved, so a stalled session does not automatically restart the whole story.
- Does it have self-healing?
- It can recover from defined, bounded failures. When it cannot establish a safe recovery—or a human decision is needed—it pauses with a clear reason instead of pretending the work is complete.
- What if a run damages my repository?
- Each story runs separately from your main checkout. If a run fails, its working state is preserved for inspection and recovery rather than discarded.
- Can it roll work back safely?
- Rollback starts a separate recovery run from a known good point. You review the plan first; the original run remains intact, and nothing already deployed is changed.
Fitting the process you already have
BGOOD Driver is meant to be additive: a local orchestration engine around the workflow you already use.
- We already use BMad. Why would we need this as well?
- BGOOD Driver has first-class support for BMad workflows, but does not depend on BMad. BMad helps shape the work; Driver decides what is safe to delegate, carries it through delivery, and makes the result reviewable. If supervision is not a problem for your team today, you may not need another layer.
- Which agent harnesses and models are supported by BGOOD Driver?
- BGOOD Driver supports Claude Code, Codex, and Copilot, using the models available to your team. It records what ran and makes any integration limitation visible rather than silently weakening a check.
- Does this weaken my pull request review, or my CI?
- No. Driver prepares a better-evidenced candidate for your existing pull request, CI, and reviewers. Those controls remain authoritative; people still merge and deploy.
- Does it force me into your workflow or your agent harness?
- No. Driver works around the tools and workflow you already use. Your team chooses the allowed integrations and checks; if a required control is unavailable, Driver makes that limitation explicit.
- What does a reviewer actually receive?
- A normal pull request plus a concise review brief: what ran, what each check found, and any retries or uncertainty. Machine-readable evidence is included for teams that want to inspect it further.
- Where does the evidence live once the run is gone?
- With the change in your repository. The evidence travels with the story commit, using the history, backup, and access controls your team already relies on.
- Can I actually queue an epic and walk away?
- Yes—when every story is eligible, its prerequisites are met, and no human decision is needed, BGOOD Driver can work through an epic unattended, around the clock. It pauses only when work is blocked, a decision needs human judgement, or it reaches a human authority boundary such as merge or deployment. A pilot establishes how often your work can safely stay in that lane.
- How do we stop people delegating work that should not be delegated?
- Before work starts, Driver decides whether it is ready to proceed, needs to be split, or should be blocked. Splitting or blocking unsuitable work is a successful safety outcome, not a failure.
- Does it re-specify work that is not deliverable as written?
- It can send work back for revision, but it cannot quietly change the intent to make a task easier. Changes to requirements, business rules, risk, or acceptance criteria remain human decisions.
- How much setup and ongoing maintenance does this need?
- There is real setup: your team defines the rules, checks, evidence, and risk tolerance that matter in your repository. In return, Driver applies those rules consistently instead of guessing.
Cost, risk and accountability
The questions an engineering leader has to be able to answer to someone else.
- Does it use more tokens? Is it cost-efficient?
- Often, yes: Driver spends extra effort on checking and evidence. Its value is avoiding bad specifications, unnecessary work, and full restarts. The right measure is total cost per accepted change, compared with your current workflow.
- How would we know this is better than what we do now?
- You would measure it against your current process: lead time, supervision, restarts, rework, review acceptance, and incidents. Expand only if your own results show less coordination without more risk.
- Will this create audit, security or accountability problems?
- Driver is designed to improve accountability by keeping the run, decisions, evidence, and delivered change connected. It does not replace your security controls, CI, or approval policy.
- Is this just automating developers out of the process?
- No. Driver removes mechanical checking work, not engineering judgement. People retain decisions, merge, and deployment—freeing more attention for design, architecture, and exceptions.