What we didn't hand to AI

The approach: boundaries in the system, not trust in the AI

Our answer wasn't to trust the AI, but to build boundaries into the system that it can't cross. On the global automotive parts project we set five rules.

• Hard-to-undo actions stay closed — deleting requirements or work items and rolling back completion simply don't exist in the CLI the AI uses. People do them in the web UI.
• AI moves only within the owner's permissions — AI works with a token a person issued, and the server checks that person's permissions as-is. A developer can only edit items they registered or were assigned.
• The server enforces the order — a step can't start until the previous one is finished.
• Scope grows only through approval — approving a requirement is approving its scope, and only people with review rights can approve. Items added directly without a requirement also need separate scope approval from an approver.
• People approve merges — AI writes the code, but it can't review its own work. Passing automated checks is the minimum bar, not approval.

Credentials stayed with people too

People issue and configure tokens themselves, and AI never receives password or token values. Credentials don't appear on the command line or in command history either.

The result: speed built on boundaries

With clear boundaries, we could hand over the work inside them with confidence. Releasing three times a day at fixed times over those sixteen weeks rested on those boundaries (as of October 8, 2026).