AI Coding Governance Hub

Use this hub when AI is allowed to draft code, tests, or specs, but the team still needs accountable delivery. The important control is not the model name. It is whether the prompt carries a written scope, whether the generated diff stays inside that scope, and whether reviewers receive evidence instead of confidence.

Start by writing the allowed change set before opening the assistant: files, public contracts, data writes, test expectations, and non-goals. Then require the generated output to map back to the acceptance criteria. If a diff changes behavior that the spec did not mention, treat it as scope expansion, even when the code looks useful.

The review step should be stricter for AI-generated work that touches permissions, migrations, billing, API responses, background jobs, or rollback paths. These are the places where plausible code hides the most expensive mistakes. Evidence should be attached before merge, not promised as a follow-up.

• The assistant is asked to “clean up while you are there.”
• Generated tests only prove the generated implementation, not the original behavior requirement.
• A risky file changes without a rollback note.
• Reviewers approve the PR because the diff looks tidy, not because evidence maps to criteria.

The handoff artifact should travel with the PR: prompt boundary, acceptance mapping, risk register, test evidence, and human sign-off. That gives incident reviewers a trail when a generated change behaves differently in production.

A typical AI-assisted change begins with a prompt such as “add workspace admin bulk disable.” The governance pass should turn that into allowed files, forbidden public API changes, permission rules, audit events, and test evidence. The assistant can draft code, but it should not decide whether suspended users keep API tokens or whether disabling one account cascades to invited seats.

The reviewer should compare the diff with the prompt boundary before reading style. If the assistant edited files outside scope, added a new abstraction, or changed response shape without approval, the PR needs a new spec decision. This is how the team keeps AI useful without letting the tool quietly become the product owner.

A common AI failure is not a syntax error. It is a plausible extra refactor that changes behavior outside the approved spec. The governance packet should make that visible before merge.

Before treating this hub as complete for a real team, run a short audit. First, confirm the reader can leave the page with one artifact copied into their workflow. Second, confirm every linked article answers a different question instead of repeating the same definition. Third, confirm the page names a failure mode that would matter in production, not only during planning.

The most useful hubs behave like workbenches. A reader should be able to open the page, choose the relevant path, copy the block, and know what evidence to attach before review. If a hub only explains the topic, it becomes another article. If it helps the reader decide what to do next, it becomes a resource.