What can AI safely change in a live app? A green, amber and red framework

I do not want founders to stop using AI once the product has paying customers.

That would remove one of the reasons the product exists at all. The founder knows the users, can describe the next improvement and can now turn that decision into working software much faster than before.

The risky part is giving every change the same path to production.

A label change and a billing migration should not need the same approval. They also should not receive the same amount of trust because both came from the same coding agent.

I use three lanes: green, amber and red.

The three lanes

These are not permanent labels attached to file types.

A frontend change can be red if it changes which customer's records an administrator can see. A database change can be green if it only adds an unused column through an established migration process. The classification belongs to the effect of the change inside this application.

Ask what the change can touch

Before choosing a lane, describe the change without naming the technology.

Bad description:

Update the Supabase function and React component.

Useful description:

Change how a canceled subscription removes access, then show the new state in the account screen.

The second version exposes the consequence. It touches billing state and customer access, so it does not belong in green even if the code diff looks small.

I use five questions to place a change:

1. Can it expose, delete or move customer data?
2. Can it charge somebody, change an entitlement or affect a contractually important workflow?
3. Can the failure stay hidden after the release?
4. Can the previous behavior be restored without losing new data?
5. Does the founder understand every system the change crosses?

One serious "yes" moves the change up a lane. Uncertainty does too.

You can lower it later when the product has evidence that the change is contained.

Green still has checks

Green work still needs a definition of done.

The founder can ask AI to change the work, but the repository should tell the agent which checks to run. Unit tests check the small pieces. End-to-end tests open the application and try the real flow. A visual change still needs a browser check at the widths customers use.

A green release might require:

• The normal build and test commands pass.
• The changed page opens without a console error.
• The focused user flow still works.
• No unrelated file or permission changed.
• The production diff matches the reviewed change.

If that list cannot be written, the change is not green yet.

Amber is where most product work lives

Amber is not a warning that the code is bad. It means the effect crosses a boundary the founder should not verify alone.

An integration can fail because the external provider changed, the network timed out or the application processed the same event twice. A background job can finish halfway. Shared application logic can fix one customer path and break another.

The amber path adds a separate environment and another pair of senior eyes:

1. Write the expected behavior, including failure cases.
2. Let the agent build against those checks.
3. Deploy the change to staging.
4. Try the real path with safe test data.
5. Review the diff and evidence.
6. Release during a period when somebody can observe it.

This is still a fast workflow. The review happens asynchronously. The founder does not need a meeting for every change.

Red starts with the release plan

Red changes touch the parts of the product where a plausible mistake creates a larger business problem.

Authentication and authorization belong here because being logged in does not mean a user may access every record. Billing belongs here because retries and out-of-order events happen. Data migrations belong here because application code and stored data must agree during the release. Secrets and infrastructure belong here because the change can affect the whole production environment.

The first artifact for red work is not code. It is a small release plan:

• What changes
• Which users and systems it can affect
• What happens to in-flight work
• How the old and new versions coexist during release
• Which signals show a problem
• When the release stops
• How the application returns to a safe state

Then the implementation can begin.

Senior ownership does not mean the human types every line. Codex or Claude can still prepare the migration, tests and candidate fix. The senior owner controls the assumptions and decides whether the evidence is enough to ship.

A lane can move as the system improves

The map should change over time.

Suppose every subscription change is red today because billing behavior is spread across several handlers and nobody knows which one wins. After the flow is mapped, duplicate events are handled, tests cover the important states and the rollback path is written, a narrow billing presentation change might move to amber.

The product earned that lower-friction path through evidence.

The opposite can happen too. A copy field that feeds a prompt, invoice or legal notice may move out of green once the team discovers the wider effect.

Review the map when the architecture changes, a new vendor enters the critical path or an incident proves the old classification wrong.

Put the map where the work happens

Do not leave the three lanes in a slide deck.

Add the current rules to the repository instructions or platform runbook. A small version can look like this:

GREEN
- isolated copy and presentation changes
- run: lint, unit tests, production build, focused browser flow

AMBER
- API integrations, background jobs, shared business logic
- deploy to staging and request senior review before production

RED
- auth, permissions, billing, data migrations, secrets, infrastructure
- stop after planning and request senior approval

Make the examples specific to the application. "Backend changes are red" is too broad to guide anyone. "Any change that can alter organization membership is red" is useful.

This map is one part of the AI Safe-Shipping System. The Production Takeover applies it to the actual system, adds the required verification and rollback paths and gives consequential changes a named owner.