Restricting code touch to engineers turns AI into a bottleneck amplifier

AI makes shipping faster, but if only engineers can touch the code, that speed does not spread across the team. The team can run experiments and ship improvements in minutes, yet everything still funnels into the same small group for implementation. Instead of removing the bottleneck, you feed it, and AI becomes a bottleneck amplifier.

The fix is not to lock the code away. The fix is to separate participation from final control. Give the entire team access to the code so people (with or without agents) can work on it. Keep merges limited to engineers. Then add clear guardrails for the category of changes that can break external consumers and integrations.

One of the main concerns about giving code access to non-technical people is external breakage. A simple contract-marker system helps prevent it, including for technical people who are new to the project.

External contracts

External contracts are promises to external consumers. Public endpoints, webhooks, public schemas, and any output that third parties depend on. Changing those shapes can break real integrations, and review alone is not a reliable safety net, especially when AI speeds up the volume of changes.

So you encode the risk in the codebase itself and you teach agents to pause.

Below is a minimal code example, aligned with what the screenshot shows.

AGENTS.md - Keep it short and operational:

# AGENTS.md

Everyone (tech and non-tech people) can work on the code and open pull requests.
Only engineers can approve and merge.

## External contracts
Mark external contracts with @external_contract.
@external_contract
consumers="<free text>"
description="<free text with usage>"

Example marker
@external_contract
consumers="Acme partner clients"
description="GET /v1/invoices/{id}. Partners depend on the response JSON fields and error shape."

## Agent rule
If a change modifies an external contract shape or returned data, stop before editing.

Show `consumers` and `description` from the marker, then propose:

1. A non-breaking alternative (preferred).
2. The breaking change, only if both are explicitly confirmed:
   - The impacted team has been informed and agrees.
   - An engineer is supervising.

Without both confirmations, do not proceed.

Breaking changes include field add/remove/rename, type or enum changes, and error payload shape changes.
Non-breaking internal work includes refactors, logging, performance, and internal reorganization that keep the same returned structure and data.

app.js - Example snippet:

/*
@external_contract
consumers="Acme partner clients"
description="GET /v1/invoices/{id}. Partners depend on response JSON fields and error shape."
*/
export function getInvoice(req, res) {
  const invoice = buildInvoice(req.params.id)
  res.json({
    id: invoice.id,
    status: invoice.status,
    total: invoice.total,
  })
}

function buildInvoice(id) {
  return {
    id,
    status: "paid",
    total: 1250,
  }
}

This setup is one practical step that helps keep the repository accessible to everyone in the team with sufficient product context to make informed decisions, reduces the chance of accidental external breakage, and should be combined with other safeguards.