Idea to production
Golden paths, templates, and scaffolds. DORA lead time applied to AI work, and what it takes for non-engineers to build like engineers.
An undocumented route from idea to production makes each project rediscover access, deployment, review, and ownership. A supported route gives builders a repeatable way to ship.
A fast compliant path
If the approved way to ship an AI application involves a design review, a security questionnaire, a ticket for a database, a ticket for a secret, and a ticket for a hostname, a personal cloud account will look much faster. Deliver the same controls through a supported template and a short exception process.
A golden path packages reviewed defaults into a template. Builders inherit those decisions each time they use it.
Golden path contents
A usable scaffold for AI work includes:
- A runtime with the environment already wired.
- Model access through the gateway, with no key in the repository.
- Data access under the calling user's permissions.
- Default telemetry for traces, cost attribution, and errors, with no builder setup required.
- Ingress and SSO so the application has a URL and authorized users can open it.
- An evaluation runner, even a small one, with a place for the first quality test case when quality becomes a question.
Expose these capabilities through one command or workflow instead of separate ticket queues. Builders should not need to configure each control themselves.
End-to-end lead time
Measure two intervals for AI work. DORA change lead time runs from a version-control commit to production. The broader value-stream measure runs from a stated idea to a change that a real user can reach and includes queue time.
Measure lead time separately for engineers and analysts because they use different routes. Also measure the next change after launch. A supported production route should handle routine updates without recreating the initial project.
Non-engineer builders
AI builder tools let people outside engineering produce working tools for their teams.
Those builders need a supported route with appropriate controls and a lower technical barrier:
- A builder interface they can use without configuring the infrastructure.
- The same identity, data scoping, and telemetry as the engineering path, inherited from the template rather than configured.
- A review process for tools that move from team use into a critical company dependency. Ownership and operating requirements should change with that role.
Production ownership
A production application needs a named owner. Small tools can become dependencies before their builders establish an operating process.
Record the owner, escalation path, and alert route. Observe covers the supporting alert capability.
An agent dropped the production database during a code freeze
Nine days into a public vibe-coding experiment, SaaStr founder Jason Lemkin declared a code freeze. The Replit agent dropped the production tables anyway, destroying records on roughly 1,200 companies and a similar number of executives.
The skipped letter. Run, then Control. Production and development were the same database with the same credentials. There was no separation to violate, so the instruction not to touch it was a request rather than a control.
The Register: Replit deleted user's production database / AI Incident Database, incident 1152
Questions to ask your vendor, or your own team
- What is the actual command or click that starts a new AI application here? Can you demonstrate it in this meeting?
- How long from idea to a URL a colleague can open, for an engineer and for an analyst?
- What does the template give you for free: runtime, keys, data, telemetry, ingress, evals? Which are missing?
- How many AI applications are running right now with no named owner?
- When something built by a non-engineer becomes a critical dependency, what process notices?
- Is development separated from production by more than a naming convention?
See accelerating enterprise AI delivery for the cross-capability constraints and measures around this path.