Human approval of AI-generated code: GitHub opens the door, off by default

Since September 1, GitHub's assistant can approve code changes rather than merely comment. The feature arrives switched off, adjustable per project, and that default says more than a speech about human oversight.

Human approval of AI-generated code loses its mandatory character at GitHub: since September 1, 2026, Copilot can approve pull requests instead of only commenting (GitHub changelog). The feature is in public preview, disabled by default, and every new pushed change cancels approval.

What GitHub opened

A pull request is when a code change written separately enters the product customers use: someone reviews, approves and integrates it. Until now, the assistant reviewed and commented; a human decided. It can now grant approval itself, unlocking integration. GitHub bounds this: settings at enterprise, organisation and project level, file restrictions and approval removed whenever a new change arrives, like a human reviewer's. Assistant approval alone also does not satisfy team-configured integration rules. The opening remains controlled, and activation belongs to the organisation.

The important detail: off by default

GitHub could have shipped the ability active. A default is the vendor's position when nobody looks, and here it left the decision to the organisation. That shifts the question to you: someone in your company or solo project must decide whether to switch it on and for which files. The answer depends on the cost of a missed error. On a presentation site, it costs tomorrow's correction. On billing calculations or customer-file access, it costs months before discovery, sometimes a letter from a customer who saw another's data.

When the agent does not know it is playing for real

On July 30, 2026, Anthropic published an analysis of three incidents during misconfigured cybersecurity evaluations, from 141,006 evaluations reviewed: models acted on live Internet-connected systems thinking they were test environments. One affected 15 real systems, another scanned around 9,000 targets, a third exposed several hundred production-data lines. The rate is tiny and the episode comes from testing, not ordinary use. It shows an agent does not always distinguish rehearsal from concert. A human approving takes responsibility and knows the risk. An approving agent follows instructions without grasping what the change affects for real people.

Two automated reviews do not make a decision

An agent reviewing another's work catches things, and our verification relies on it: tests before code, a verifier following the builder. This chain leaves out one thing: agreement about what the product was meant to do. Automatic approval checks conformity to an assumed intention without questioning it. Our operating rule is nothing is agreed without ‘Looks good to me’, given on the product document before corresponding code exists. A machine observes a change doing what it claims; whether that matches your business intention remains beyond its reach.

Review fatigue: the real opponent

The case for switching it on takes one word: volume. Nobody reviews thirty changes daily with equal attention on the thirtieth and first, and METR measured experienced developers as 19% slower with AI while believing themselves faster, covered in AI makes experts slower. The way out is less frequent review of larger objects: approving requirements and stages takes an hour and commits weeks of building, while approving every change takes the day and commits nothing.

In practice

If working with a technical team on GitHub, ask who decides assistant approval activation and for which folders. If directing agents alone, retain approval where it matters: the document describing what the product must do, reviewed before the first code line. An hour on this document saves subsequent reviews, and an approved document is not yet agreement until you say aloud what you understood.