# 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.

Source: https://brocs.fyi/build/idea-to-production/
Part of the surface: B · Build. Enable people to make things.
Framework: BROCS (Build, Run, Observe, Control, Secure), brocs.fyi. CC BY 4.0, attribute to brocs.fyi.

---

## The Build surface

- Tooling: IDEs, agent CLIs, notebooks, chat surfaces
- Access: who gets which tools, and how fast
- Keys and models: distribution, scoping, rotation, BYOK
- Data access: without handing out production credentials
- Idea to production: golden paths, templates, scaffolds


The last part of Build is the path itself: what a person actually does between having an
idea and having something running that other people use. If that path is undocumented,
every project rediscovers it, and most give up somewhere in the middle.

## Make the compliant path the fast path

This is the whole of platform engineering compressed into one sentence, and it is the
only governance strategy that survives contact with people under deadline.

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, then the unapproved way, which is a personal cloud account and a share link,
will win. Not because anyone is reckless, but because it works today and the other one
works in three weeks.

A golden path is the same set of controls delivered as a template instead of a queue. The
review happened once, when the template was built. Using the template is how you inherit
it.

## What a golden path actually contains

A usable scaffold for AI work covers, at minimum:

- **A runtime** it deploys to, with the environment already wired. See [Run](/run/runtime/).
- **Model access** through the gateway, with no key in the repository. See
  [keys and models](/build/keys-and-models/).
- **Data access** as the calling user, not as a service account. See
  [data access](/build/data-access/).
- **Telemetry on by default**: traces, cost attribution, and errors, without the builder
  configuring anything. See [Observe](/observe/).
- **Ingress and SSO** so the thing has a URL and only the right people can open it. See
  [Control](/control/ingress/).
- **An eval harness**, even a trivial one, so there is somewhere to put the first test
  case when quality becomes a question.

The list is unremarkable. The point is that it is one command rather than six tickets,
and that the person shipping did not have to know any of it existed.

## Lead time, measured honestly

Borrow the DORA metric directly and apply it to AI work: how long from a stated idea to
something running that a real user can reach. Measure the whole thing, including the
waiting, because the waiting is the finding.

Two refinements make it more useful:

**Measure by population.** The engineer's lead time and the analyst's lead time are
different numbers, and the second one is usually the one nobody has looked at.

**Measure the second change, not just the first.** Getting something into production once
is a project. Changing it on Thursday because a user complained on Wednesday is a
platform. If the second number is much worse than the first, you have a demo pipeline
rather than a production path.

{{< aside title="How DORA thinks about this" >}}
The DevOps Research and Assessment program's finding, repeated across years of data, is
that lead time, deployment frequency, change failure rate, and time to restore move
together, and that they are properties of the system rather than of the people in it.
Applied here: if AI projects are slow at your organization, the productive question is
which stage of the path is queueing, not which team is underperforming.
{{< /aside >}}

## Non-engineers building real things

The interesting growth in AI usage is not engineers writing code faster. It is people who
were never going to write code producing working tools for their own team.

That is genuinely valuable and it is also where governance usually breaks, because the
tools those people reach for are the ones with no organizational boundary at all. The
answer is not to stop them. It is to provide a path with the same guardrails and a much
lower floor:

- A builder surface they can actually use, where the hard parts are already decided.
- The same identity, data scoping, and telemetry as the engineering path, inherited from
  the template rather than configured.
- A clear line between "useful for my team" and "load-bearing for the company", with a
  real process for crossing it. Something that starts as a personal tool and quietly
  becomes a dependency is a known way to acquire an outage.

## Production means someone owns it

The last checkpoint is ownership. A running application with no named owner is an
incident waiting for a trigger, and AI applications acquire this status faster than most,
because the person who built it in an afternoon did not think of it as a system.

Ownership means a name, an escalation path, and alerts that reach that person. That is an
[Observe](/observe/alerts/) capability, and it is the difference between a pilot and
production.

{{< failure id="replit-prod-db" >}}

{{< checklist >}}
- 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 load-bearing, what process notices?
- Is development separated from production by more than a naming convention?
{{< /checklist >}}