Use cases
Bring AI-assisted engineering to your existing codebase
Not a new repo. Yours. Custom sandboxes wrap your Rails, Java, Go, Python or Node backend, and every AI-assisted change lands through governed branches with human approval.
Bringing AI-assisted engineering to an existing codebase means running AI-driven changes through a full software development lifecycle on the code you already operate. Ciao does this with custom sandbox images that wrap Rails, Java, Go, Python, Node and multi-process backends. Unlike coding assistants that mainly edit files, Ciao adds the delivery loop around the edit: governed branches with recorded human approvals, automated QA, live security testing and an append-only audit trail.
Published 2026-07-03 · Last updated 2026-07-03
The edit was never the hard part
Most engineering organizations have already tried AI on their codebase: an assistant in the editor, faster autocomplete, a chatbot that explains old functions. Useful — and yet delivery barely moved. Because in an established codebase, writing the change was never the bottleneck. The bottleneck is everything around it: understanding blast radius, review, testing, security checks, change approval and the deployment window. An AI that accelerates only the edit accelerates the shortest segment of the pipeline.
There is also the trust problem. Handing an AI write access to the system that runs your revenue is a different decision than letting it suggest lines in an editor. Engineering leaders want the speed, but not at the price of unreviewed machine-generated changes drifting into payment logic — and they need to show an audit trail when someone asks how a change shipped.
Ciao's answer is to bring the whole software development lifecycle, not just the editing, to your existing code. Custom sandbox images wrap AI-assisted engineering around Rails, Java, Go, Python, Node and multi-process backends — the platform works on your stack as it actually is. Guardrails maps the codebase into business areas and applies plain-English policies. Changes move through governed branches where risky ones are flagged and human approval is recorded. QA and security gate every merge, and an append-only audit trail sits behind all of it. Your code is never used to train models, and inference runs under zero-retention contracts.
What governed AI on existing code requires
Before AI touches a production codebase, engineering leadership typically requires:
- Real stack support — The codebase is Rails, Java, Go, Python, Node or a multi-process combination — custom sandbox images wrap the stack you run, not an idealized one.
- A map of the code — Guardrails maps code into business areas, so everyone can see which parts are routine and which are payout logic, pricing or compliance-critical.
- Branch discipline — Branch-native git with governed branches: AI-proposed changes are isolated, inspectable and reversible before they go anywhere near main.
- Human approvals — Risky changes detected automatically, plain-English policies applied, and human review recorded — approval is a logged act, not a rubber stamp.
- Testing and security gates — Deterministic QA replays with smoke gates, plus security scanning whose findings are confirmed against the live app before they are flagged.
- IP and data protection — Customer code never used for model training, zero-retention inference contracts, and SOC 2 Type II reports available under NDA.
How it runs on your repo
1. Wrap the codebase
A custom sandbox image is built around your stack — Rails, Java, Go, Python, Node or multi-process — so the AI works in an environment that matches production reality.
2. Map and protect
Guardrails maps the code into business areas and identifies protected zones. The dangerous parts of the codebase become visible instead of tribal knowledge.
3. Write the policies in plain English
For example: changes under /billing require human review; dependency upgrades need a security pass. Policies read like sentences, not regex.
4. Request changes in plain language
Features, fixes and refactors are described conversationally; the prompt queue keeps a stream of work moving through the AI software organization.
5. Review on governed branches
Each change arrives on a branch with its risk assessment. Your engineers approve, request changes or reject — and the review is recorded.
6. Gate with QA and security
Browser replays and smoke gates catch regressions; static scanning, dependency checks and access-control probes run with live confirmation.
7. Merge with a trail, deploy on your terms
Every merge carries its audit record. Deployment targets include your own AWS, Azure or GCP account, private VPC or on-prem under separate terms.
Security and governance checklist
- ✓ Custom sandbox image matching your production stack
- ✓ Business-area map with protected zones before the first AI change
- ✓ Plain-English policies enforced on risky paths
- ✓ Recorded human approval on every flagged change before merge
- ✓ QA smoke gates and live-confirmed security findings on every branch
- ✓ Append-only audit trail across prompts, merges, deploys and admin actions
- ✓ No training on your code; zero-retention model contracts; SOC 2 Type II under NDA
Where teams apply it first
Feature delivery on a Rails monolith
The backlog of well-understood features moves through AI-assisted branches while senior engineers keep approval authority.
Bug-fix flow on a Java service
Reported defects become proposed fixes with tests, reviewed and merged with a recorded trail.
Python data platform changes
Pipeline adjustments and new transforms delivered under policies that protect the models and metrics downstream teams rely on.
Node backend with multiple processes
Multi-process backends wrapped in one sandbox image, so changes are built and tested against the real topology.
Go services behind an API gateway
Service-level changes with contract tests at the boundary, gated by the same QA and security loop.
Frontend refresh on an existing product
Modern React screens delivered against the existing backend, one governed branch at a time.
Requirements and how Ciao covers them
Engineering leaders evaluating AI on production code tend to ask the same seven questions. Here is each one mapped to the specific platform capability that answers it.
| Requirement | How Ciao covers it |
|---|---|
| Works on our stack | Custom sandboxes wrap Rails, Java, Go, Python, Node, multi-process |
| No silent AI merges | Governed branches; risky changes require recorded human approval |
| Blast-radius visibility | Guardrails maps business areas and protected zones |
| Regression safety | Deterministic QA replays and smoke gates on every branch |
| Security beyond linting | Findings confirmed against the live app before flagging |
| Change-control evidence | Append-only audit trail behind every merge |
| IP protection | No training on customer code; zero-retention inference contracts |
Frequently asked questions
Which stacks can Ciao work on?
Custom sandbox images wrap AI-assisted engineering around Rails, Java, Go, Python, Node and multi-process backends. If your system combines several of these, the sandbox is built to match the real topology rather than forcing a single-runtime assumption.
How is this different from giving engineers a coding copilot?
Ciao is built for the whole delivery loop, not just the edit: changes arrive on governed branches with risk assessment, pass QA replays and live-confirmed security testing, require recorded human approval when risky, and merge with an audit trail. A copilot accelerates typing; this governs shipping.
Who approves AI-proposed changes?
Your people. Guardrails detects risky changes and applies plain-English policies you define, and the flagged changes wait for recorded human review. Approval authority stays exactly where your engineering organization puts it.
Can non-engineers request changes safely?
Yes — that is one of the main effects. Product managers and operations leads describe changes in plain language, and the same governed pipeline applies: branch, tests, security, human approval on anything risky. The request path widens; the merge bar does not drop.
Is our codebase used to train models?
No. Customer code is never used to train models, and inference runs under zero-retention model contracts. SOC 2 Type II reports are available under NDA, and deployment can sit in your own cloud, private VPC or on-prem under separate terms.
How do we start, and what does it cost?
Engagements start by wrapping one codebase and running a bounded set of changes through the governed loop. This is enterprise work: development programs start at USD 10,000 per year, and sales will scope the sandbox build against your stack.