Who Approved This Code?

AI can generate software. Governance still owns production.

Charles S. Assaf, MSc IT

AI Systems Architect | AI Governance & Deterministic Orchestration

The software industry is quietly undergoing one of the largest shifts in its history.

For decades, the relationship between people and code was straightforward. A developer wrote software. Another developer reviewed it. The code was tested, deployed, monitored and maintained. The governance model was simple because authorship was simple. The person who wrote the code was responsible for the decisions embedded within it.

That assumption is no longer true.

Today, large language models routinely generate production-quality software. Claude Code, GitHub Copilot, GPT Codex and similar systems can produce entire applications, design database schemas, implement APIs, write infrastructure-as-code, generate tests and propose architectural changes. The productivity gains are real. The quality is often surprisingly high. The adoption curve is accelerating.

The question nobody seems particularly interested in asking is simple.

Who approved this code?

Not who generated it. Who approved it?

That distinction matters far more than most organisations realise.

The Governance Model We Inherited

Traditional software development followed a reasonably clear chain of accountability.

Developer

↓

Code

↓

Review

↓

Production

The author understood the requirements, implemented a solution and submitted it for review. Reviewers challenged assumptions, identified defects and validated that the implementation met organisational standards before approving deployment.

The model was imperfect, but it worked because responsibility remained relatively clear. The developer authored the code. The reviewer authorised the code. The organisation accepted the risk.

AI changes that relationship. The modern workflow increasingly looks like this.

Developer

↓

Prompt

↓

AI System

↓

Code

↓

Review

↓

Production

The developer increasingly becomes an editor rather than an author. The code arrives before the understanding does. That inversion introduces a governance problem that most organisations have not yet fully recognised.

The Illusion of Review

Human-written code is typically reviewed with a particular mindset. The reviewer assumes another engineer made deliberate design decisions. The review process therefore focuses on understanding those decisions, validating assumptions and challenging implementation choices.

AI-generated code often receives different treatment. The code appears quickly. It compiles. Unit tests pass. The implementation looks plausible. The reviewer scans the output, verifies the obvious pieces and moves on.

The review shifts from validation to confirmation. That difference sounds subtle. It isn’t.

A reviewer who assumes intentional design behaves differently from a reviewer who assumes the code is probably correct because a capable model generated it. The result is a dangerous illusion: the appearance of governance without the corresponding depth of scrutiny.

Most governance failures do not emerge because the code was obviously wrong. They emerge because the code was sufficiently plausible to avoid deeper inspection. AI systems are exceptionally good at producing plausible output. That is both their greatest strength and their greatest governance challenge.

AI Reviewing AI

Many organisations respond to this problem by introducing additional AI systems into the workflow. Claude generates the code. GitHub Copilot reviews it. GPT analyses security issues. Another model evaluates documentation quality. The architecture begins to look sophisticated.

Unfortunately, the governance model remains unchanged.

A probabilistic output reviewed by another probabilistic output is still a probabilistic process.

The same assumptions that created the original problem remain present. The organisation has increased confidence. It has not necessarily increased control.

This is not an argument against AI-assisted review. AI code review can be extremely effective when used correctly. Models frequently identify security vulnerabilities, design flaws and implementation mistakes that humans miss. The mistake is treating AI review as governance. It isn’t. Governance is not another opinion. Governance is authority.

Rules Without Enforcement Are Not Control

The software industry has spent years developing mechanisms for governing code before it reaches production. Static analysis. Dependency scanning. Security testing. Policy enforcement. Protected branches. Mandatory reviews. Change approval processes.

These controls exist because human judgement is imperfect. The exact same principle applies to AI-generated software.

Many organisations are embedding coding standards directly into prompts. Use TypeScript. Follow clean architecture. Write unit tests. Do not expose secrets. Apply OWASP guidelines.

These instructions are useful. They are not governance. A prompt is a request. Governance is an enforcement mechanism.

The distinction is identical to the one emerging throughout AI systems generally. Instructions influence behaviour. Controls determine what behaviour is permitted.

That is why tools such as npm audit, yarn audit, Dependabot, CodeQL, Semgrep, SonarQube, SAST platforms and CVE scanning pipelines remain critically important. None of these systems care how the code was produced. They evaluate what exists. More importantly, they do so deterministically. A vulnerability either exists or it does not. A policy violation either occurred, or it did not. The governance model is independent of authorship. That is exactly how it should be.

The Pull Request Is the New Governance Boundary

One of the more interesting consequences of AI-assisted development is that the pull request increasingly becomes the most important governance boundary in the software lifecycle.

The code generation phase is probabilistic. The review phase must not be.

Every pull request effectively becomes a capability request. The AI proposes a change. The organisation decides whether that change is permitted to affect production systems.

Viewed this way, the pull request stops being a collaboration mechanism and becomes an authorisation mechanism. The distinction is subtle but important. The reviewer is no longer simply validating implementation quality. The reviewer is authorising effects.

The same principle appears throughout AI governance. The question is never whether the system generated something plausible. The question is whether the organisation permits the consequences of that output.

The Accountability Question

Ultimately, the legal and operational reality remains unchanged. If an AI system introduces a security vulnerability, the organisation owns it. If an AI-generated migration corrupts production data, the organisation owns it. If a generated API leaks customer information, the organisation owns it.

Responsibility does not transfer to Anthropic, OpenAI, GitHub or any other model provider. The accountability chain remains exactly where it has always been.

What changes is the volume of code, the speed of generation and the ease with which software can enter a delivery pipeline. That makes governance more important, not less. The faster code can be generated, the more valuable deterministic controls become.

Deterministic Effects, Probabilistic Development

As I argued in ‘Rules Without Enforcement Are Not Control,’ rules encoded as instructions are not enforcement.

This is ultimately the same architectural problem appearing elsewhere in AI. The code generation layer is probabilistic. The governance layer must be deterministic.

AI-generated code is not inherently dangerous. Neither is AI-assisted development.

The risk emerges when probabilistic generation is allowed to flow directly into production systems without an intervening governance boundary.

The software industry spent decades building controls around human-generated code because humans make mistakes. There is no reason to assume probabilistic systems require fewer controls. Quite the opposite.

The future of software development is almost certainly AI-assisted. The future of software governance remains exactly what it has always been: explicit authority, deterministic controls and accountable decision-making.

The question organisations should be asking is not whether AI wrote the code. The question is much simpler.

Who approved it?

*Charles S. Assaf is an AI Systems Architect specialising in AI Governance and Deterministic Orchestration, and is a member of the OASIS Data Provenance Standards Technical Committee. VashOS — a research programme building the OS primitives for structurally trustworthy AI cognition — is his primary work. He writes at KAIRI on Medium.*