AI workflows for software delivery
Turn a GitHub issue into reviewed requirements, architecture, implementation, testing, and release artifacts through specialized AI roles and human approval gates.
No account, no GitHub access, and no AI provider spend to explore the demo. Sign in to run BinChicken against a real repository with your own AI credential.
Understand
BinChicken reads the repository before it touches it — real files and structure feeding every role, not a blank prompt.
Govern
Specialized AI roles, explicit artifacts, security review, testing, and a human approval gate turn output into a governed process.
Build
The task moves through the SDLC toward a real, reviewed GitHub pull request — never an unreviewed merge.
The problem
AI-assisted engineering has speed. It doesn't have a review structure.
Every team already trusts a review structure: scoped requirements, an architecture pass, security sign-off, code review, a test plan. AI coding assistants skip straight to a diff — collapsing all of that into one chat window and one person's judgment about when it's done.
BinChicken doesn't make the model smarter. It puts the review structure back — as software, not as a habit someone has to remember to follow.
How it works
Eight roles. One artifact each.
Artifact-first, not chat-first
A workflow run is, in full, the artifact graph it produced plus the approvals gating it. Every artifact is versioned, attributed to a role and a provider, and links to the artifacts it was built on — a real audit trail, not a transcript.
Try it without connecting anything
The demo runs the same eight-role SDLC workflow and the same artifact graph as the real product — with no account, no GitHub access, no AI provider credentials, and no provider cost. It's a simulated run against a simulated repository: nothing you do in the demo touches a real codebase or opens a real pull request.
BinChicken builds BinChicken.
We're using BinChicken to build BinChicken. Our own repository is the first test environment for the real, authenticated product — real GitHub connection, real BYOK Anthropic execution, real approval gates. We haven't completed a full self-build yet, and we won't claim one until it actually happens. Until then, every real run — success or failure — becomes evidence, and we publish it as it happens.
Human approval, on the record
Security and release gates block automatically. A decision — approve, reject, or request changes — is captured with who made it and when. Nothing ships past a gate because no one objected.
Governance principles
Provider-agnostic by design
BinChicken is designed to govern workflows across AI providers — no role, workflow, or artifact schema encodes a vendor. Anthropic BYOK is currently validated end to end; additional provider adapters are planned, not live.
Your repository stays yours
Your repository stays in your own GitHub environment. BinChicken connects through a GitHub App and retrieves the context a run actually needs — it does not need to permanently retain a copy of your source repository to operate. BYOK means your AI provider spend runs on your own credential, not a shared platform key. Engineering context is meant to stay explainable: what a role saw is what the audit trail shows.
BinChicken creates draft pull requests and does not implement the operations required to make them ready for review or merge them. Customer repository rules remain the final merge-control boundary.
Where BinChicken is headed
Your application isn't always one repository. BinChicken is being designed to understand systems composed of multiple repositories, services, and shared components — a frontend, an API, an auth service, shared packages, infrastructure — not just the one repo it's pointed at today.
A transparent engineering map of your system: a concise, version-controlled document describing repository structure, architecture, boundaries, technologies, testing conventions, and BinChicken-specific guidance — visible, reviewable, and editable alongside your code. It is not a copy of your source.