Two years ago, I could still review AI-assisted work line by line.

Today, I can't.

During the week of August 2, 2026, I used 5.6 billion tokens with a single AI provider.

To be clear, that is not 5.6 billion tokens of production code. It includes prompts, context, plans, tool calls, tests, retries, research, documentation, and work that never became a final result. Token volume is not a productivity score. It simply shows the scale.

I'm still not a software developer, and I'm not an AI developer either. My background is IT infrastructure and corporate IT. "AI experimenter" is the most honest label I have. I use these systems heavily, push on their limits, and pay attention to what works and what breaks.

That distinction matters. This is not a developer arguing that code review is obsolete. The AI work I see is broader than application code. It can include scripts, infrastructure configurations, change plans, incident analysis, documentation, research, communications, and actions taken through tools.

At this scale, reviewing every line of generated code is impossible. So is retracing every piece of analysis, checking every draft sentence, and watching every tool call by hand.

Manual review still matters. A manual-first review process is no longer mature or realistic.

Review the work, not every word

The answer is not to trust whatever the AI produces. It is to be clearer about what review is supposed to prove.

Whether the output is a script, a configuration, a runbook, or a change plan, I want to know:

  • Did the AI understand the request and the business context?
  • Did it check the real environment, source, or interface instead of guessing?
  • Did it stay inside the scope and authority it was given?
  • Did it follow the organisation's security, architecture, and change rules?
  • What evidence shows the result is correct?
  • What failed, remains uncertain, or needs a rollback plan?

Those questions matter more than whether every sentence looks polished.

Some work still deserves deep human inspection. Identity, access, production infrastructure, data deletion, major cost decisions, and customer-facing changes can have a large blast radius. People should review those decisions and the consequential details.

Routine, well-bounded work can be checked automatically and sampled. Review should follow risk, not spread human attention equally across everything just so we can say it was reviewed.

Build review into the workflow

There is no single replacement for manual review. The practical answer is to put several controls around the work.

Rules set the boundaries. Reuse the existing process. Protect secrets. Do not weaken security. Do not make destructive changes without approval. Do not claim something worked without checking the real outcome.

Skills capture how recurring work should be done. A migration skill can require compatibility checks, validation, communication, and a rollback plan. An incident skill can require timestamps, impact, evidence, and escalation criteria. This is operational knowledge made reusable, not just a longer prompt.

Hooks create automatic checkpoints. Before an action, confirm scope and approval. After an action, validate the result. Scan scripts and configurations, record tool activity, and stop when a protected system or risky change is involved.

Workflows should route work by risk. Drafting internal notes should not follow the same path as changing tenant-wide identity policy. Higher-risk work needs stronger checks, clearer evidence, and an explicit human decision.

Permissions should also stay narrow. An AI preparing documentation does not need production access. A tool used for diagnosis does not automatically need authority to make changes. The same mistake has very different consequences depending on the access behind it.

Finally, I want evidence: what the AI was asked to do, which sources it used, what actions it took, what it checked, what failed, what remains uncertain, and how to recover. A confident summary is useful, but it is not proof.

This is where human review becomes more valuable, not less. People can focus on intent, business context, risk, exceptions, and whether the evidence actually supports the conclusion.

The workflow is not mature yet

The models are moving quickly. The workflows around them still have a long way to go.

Here is a recent example from ChatGPT:

A ChatGPT composer UI bug rendering its placeholder text backwards

The ChatGPT composer rendered its placeholder text backwards.

This bug was harmless and a little funny. It did not corrupt data or make a production change. But it is a visible reminder that a capable model does not automatically create a mature product or workflow.

The more serious failures are often harder to see. State can be lost. A tool call can stop halfway through. An approval can apply to the wrong scope. A summary can hide a skipped check. Context can go stale. Evidence can belong to an earlier version of the work.

None of those problems would be caught by reading generated code line by line.

AI workflows need clearer state, dependable gates, durable audit trails, recovery paths, and interfaces that make failures hard to miss. We are not there yet. The workflow itself still belongs inside the review boundary.

What I can honestly claim

More automation does not remove responsibility. Someone still owns the decision and the outcome. "The model approved it" is not an answer when something goes wrong.

At more than 20 billion tokens a week, I cannot responsibly claim to review every line or every output AI generates.

What I can do is set the boundaries, build the rules and skills, install the hooks, limit authority, demand evidence, and personally review the decisions that can hurt people, systems, or the business.

That is not a lower standard. It is a more honest one for the way I actually use AI today.