Why human oversight is shifting from writing code to defining requirements

The article discusses a shift in human oversight from writing code to defining requirements. In the pipeline used by agents, a recorded scoping meeting is the first step, where teams from various departments discuss the intent and scope of a feature. This recording becomes the scoping document, which is then signed off by product managers and becomes the source of truth.

The scoping document breaks down the feature into release groups and numbered units, each with its own purpose, scope boundaries, functional requirements, architectural layers, dependencies, feature flags, and acceptance criteria. The scoping document is then synced into the issue tracker and assigned to developers. When a developer picks up a unit, they generate a unit spec from the scoping material, which includes named interfaces, method signatures, files to create or modify, error-handling matrices, query flows, and a list of what the unit deliberately will not do.

Developers review the spec against the scoping document to ensure that every requirement is covered and that nothing has been dropped during translation. Only then does an agent write code, which must cover the entire call path from entry point to service layer, including unit and integration tests. After the code is written, it goes through a standards check, automated PR review, a second developer's approval, QA reviews, and a release gate before being deployed on Thursdays.

The article highlights a flaw in this pipeline - a single bad requirement can slip through unnoticed, even with automated tests, QA, and release gates in place. This is because the instruction itself never goes on trial, and the focus is on whether the code conforms to its instructions, not on the validity of the requirements.