Five-stage human-in-the-loop framework for AI-written database code: declare, classify, route, gate, log

A workable human-in-the-loop framework for AI-written database code has five stages: the agent declares scope and blast radius before generating the change, an automated classifier assigns a risk tier, the tier routes the change to autonomous execution, async review, or a blocking approval gate, the gate uses a structured checklist instead of a free-text “LGTM,” and every outcome — approved or autonomous — writes an immutable log entry. Skip any one of the five and the framework degrades back into either a rubber stamp or a bottleneck.

Why “have a human review it” already isn’t the answer

Reviewer attention was never infinite, and AI-generated database code is arriving faster than any team can look at it closely. SmartBear’s analysis of 2,500 code reviews across 3.2 million lines at Cisco found that a reviewer’s ability to catch defects drops sharply past 200–400 lines in a single sitting, or roughly 500 lines an hour, regardless of skill level as reported by Cortex. AI agents blow past that ceiling routinely. A 2026 study cited in the same piece found that as reviewers saw more AI-authored pull requests, their approval rate climbed from 30.1% to 36.8% while the inline comments they left dropped 22% — the signature pattern of rubber-stamping, not genuine scrutiny.

Database code makes this worse than application code, not better. A bad application PR usually fails a test or throws an error a user notices quickly. A bad schema change can pass every existing test, merge cleanly, and only reveal itself hours or days later as a locking problem, a broken index, or — as covered in the risk of parallel AI agents merging schemas — a conflict with another change nobody else saw coming. “A human reviewed it” is not the same claim as “a human reviewed it well,” and for database changes specifically, the gap between those two claims is where the damage happens.

This post picks up directly from AI agent guardrails for databases, which argued that database changes need a tiered autonomy model with a human “last word” on the riskiest tier. This post is the operational framework underneath that argument — the actual stages a change moves through, and what a real approval gate looks like when it isn’t a meeting or a rubber stamp.

Key takeaways

  • Reviewer defect detection collapses past 200–400 lines per sitting; AI-generated database code routinely exceeds that volume, so uniform “have someone review it” review doesn’t scale
  • The framework has five stages: declare, classify, route, gate, log — skipping any one turns it back into either a bottleneck or a rubber stamp
  • Approval gates work better as a structured checklist (intent, lineage, permissions, blast radius, rollback) than as a free-text approve/reject decision
  • Regulators are starting to require proof of human oversight by name — the EU AI Act’s Article 14 and NIST’s AI Risk Management Framework both expect oversight that’s trained, measurable, and logged, not just present in a diagram
  • Time-boxed decision lanes (matching SLA to risk tier) keep the gate from becoming the new bottleneck once volume grows

Stage 1: Declare

Before an agent’s proposed database change goes anywhere, it has to produce a structured declaration of what it’s about to do — not just the DDL or DML itself, but metadata a downstream system can act on automatically: which tables and columns are touched, whether the operation is additive (new column, new index) or destructive (dropped column, truncated table, altered constraint), what environment it targets, and whether the change is reversible without a restore. This is the same information a senior DBA used to hold in their head before approving anything. Making the agent state it explicitly, in a consistent format, is what makes the next four stages possible to automate.

Stage 2: Classify

A classifier reads the declaration plus a handful of static signals — is this a production or shared environment, does the diff match a destructive pattern (DROP, TRUNCATE, an unscoped DELETE), does it touch a table with no test coverage, does it change a public schema contract other services depend on — and assigns a risk tier. This mirrors the blast-radius-and-reversibility logic several teams are already formalizing for AI-generated code review generally per Cortex’s reporting: changes to shared, hard-to-reverse structures get a mandatory gate, additive and reversible changes get lighter treatment, and purely read-only or sandboxed operations need no human gate at all.

Stage 3: Route

The tier determines the path, not a person’s judgment call in the moment — that judgment already happened when the tiering rules were written, which is what makes this stage fast instead of political:

Low risk — autonomous, logged only. Read-only queries, schema introspection, changes confined to a disposable sandbox or the agent’s own scratch branch. Nothing here needs a human in the room.

Medium risk — human-on-the-loop, asynchronous. Reversible, scoped changes to shared but non-production environments. A human is watching the pattern of activity and can intervene, but nothing blocks on their response.

High risk — human-in-the-loop, blocking. Anything touching production or a shared schema with real dependents, anything destructive, anything outside the agent’s normal working pattern. Execution waits for explicit approval.

That three-way split — human-in-the-loop for blocking approval, human-on-the-loop for monitoring with intervention rights, and fully autonomous for genuinely low-risk work — is a distinction worth keeping precise, because conflating them is exactly how “someone’s watching” gets mistaken for “someone approved this” as one 2026 human-oversight guide puts it plainly.

Stage 4: Gate

This is the stage most frameworks get wrong by treating it as a single approve/reject button. A better model replaces the free-text “LGTM” with a checklist the approver has to positively work through: what is the agent’s stated intent, where did the data or schema context come from, what does the change’s permission chain actually touch, what is the realistic blast radius if the rollback fails, and what is the rollback plan specifically — not “we can restore from backup,” but the actual reversal statement or script. Forcing acknowledgment of each item is slower than clicking approve, by design — it’s meant to interrupt the automation-bias pattern where a confident-looking AI-generated explanation gets nodded through without anyone actually checking it.

Speed still matters, so pair the checklist with a time-boxed decision lane matched to risk: a short window for a scoped, reversible change; a longer window for something touching a shared production table; and a defined fail-safe (deny by default, not approve by default) if the window expires with no response. This keeps the gate from turning into the next bottleneck once agent-generated change volume climbs — which, per Databricks’ own reported usage data on agent-driven database creation and branching, it already has in agent-heavy environments.

Stage 5: Log

Every outcome from stage 3 — autonomous, async-reviewed, or gated — writes to the same immutable record: what changed, what tier it was classified into, who or what approved it, what checklist responses were given if it went through the gate, and how to reverse it. This is the piece that turns “we have a review process” into something an auditor, or a postmortem, can actually verify after the fact instead of reconstructing from Git history and Slack threads. It’s also increasingly not optional: the EU AI Act’s Article 14 and NIST’s AI Risk Management Framework both move toward requiring oversight that’s demonstrable, not just described in a policy document.

What this framework doesn’t solve on its own

None of this replaces good judgment about where to draw the tier boundaries in the first place, and it doesn’t eliminate the need for a human who understands the schema well enough to know when a “reversible” change isn’t really reversible in practice. The framework’s job is narrower: make sure the right changes reach a human’s attention, in a form they can actually evaluate, fast enough that the gate doesn’t become the reason teams route around it. That’s a solvable engineering problem. Deciding who has the authority to set the tier boundaries, and revisiting them as the system’s blast radius changes, stays a human and organizational one.

If your team is generating database code with AI agents faster than your current review process can keep up, this framework — declare, classify, route, gate, log — is a concrete starting point rather than a policy document nobody follows. Get in touch if you want help building the classifier and gate logic for your own environment.

Ivan Lima is a data engineer specializing in database modernization for AI systems. Get in touch if your database needs to be ready for what’s next.