What AI-Generated Schemas Reveal About the Limits of Coding Agents in Production Codebases

The velocity narrative around AI coding agents is well-established at this point. Benchmarks circulate, productivity claims accumulate, and engineering leaders face mounting pressure to extend agent autonomy deeper into the delivery pipeline. What receives far less attention is what happens when you audit the artefacts those agents actually produce, particularly at the data layer, where structural decisions compound over time and bad choices are expensive to reverse.

Schema generation is a useful diagnostic surface precisely because it sits at the intersection of syntax, semantics, and domain knowledge. An agent that produces syntactically valid SQL with well-named columns and appropriate foreign key constraints is demonstrating genuine capability. The question worth asking is whether that capability holds under the conditions that actually define production software: write-heavy workloads, evolving requirements, multi-tenant access patterns, and the implicit conventions of a codebase the agent has never seen before.

Where Agents Demonstrate Genuine Craft

At the level of isolated schema construction, current coding agents perform credibly. Given a clear domain description, they produce normalised table structures, apply reasonable type choices, and surface constraint logic that a junior engineer might miss. This reflects the density of well-structured SQL in public training corpora.

The same pattern holds for boilerplate migration scaffolding. Agents can generate Alembic or Flyway migration files with accurate up and down operations when the change is additive and the context is explicit. For greenfield work with a narrow scope, this is genuinely useful and the quality holds up under review.

The craft breaks down as soon as the task requires reasoning about what already exists. Agents working from partial repository context will generate schemas that conflict with existing conventions, duplicate lookup tables that already exist under different names, or miss soft-delete patterns that the team has applied consistently elsewhere in the codebase.

The Index Over-Generation Problem

One of the more consistent failure modes we observe in agent-generated schemas is index proliferation. Agents tend to index liberally, applying indexes to foreign keys, frequently filtered columns, and join candidates in a way that looks thorough on inspection but creates real overhead at write time.

The mechanism is straightforward: agents are optimising for read-query plausibility because read patterns are more visible in training data than write-load consequences. An index that makes a SELECT faster is immediately legible. The cost of that index on INSERT and UPDATE throughput requires reasoning about workload distribution that the agent cannot perform without explicit context.

For OLTP systems under sustained write pressure, this is not a minor inefficiency. Index maintenance overhead accumulates, and schemas that were generated without write-load awareness can require significant rework once the system is under realistic load.

Why Public Benchmarks Do Not Transfer

The benchmarks most commonly cited to support agent capability are evaluated against synthetic or well-documented public codebases. These environments are structurally different from enterprise production codebases in ways that matter for schema work specifically.

Public benchmark codebases have consistent naming conventions, explicit documentation, and no accumulated technical debt. Enterprise codebases have none of these properties reliably. They contain legacy tables with opaque names, implicit business rules encoded in application logic rather than constraints, and multi-year migration histories that an agent has no way to reconstruct from the files it can see.

The performance gap between benchmark environments and private codebases is not primarily a model capability problem. It is a context problem. Agents operating without access to the full semantic history of a codebase are making structural decisions with incomplete information, and schema generation is particularly sensitive to that gap because the consequences are durable.

What Engineering Leaders Should Actually Measure

The practical question for a VP Engineering deciding how far to extend agent autonomy is not whether the agent can produce a valid schema. It is whether the agent's output degrades gracefully as context completeness decreases and write pressure increases.

A useful evaluation framework has three dimensions. First, measure schema coherence against the existing codebase: do the generated tables conflict with existing conventions, and does the agent surface those conflicts rather than silently overriding them? Second, measure index appropriateness under a realistic write workload, not just query correctness. Third, measure migration safety: does the agent generate reversible migrations, and does it flag destructive operations explicitly?

None of these dimensions are captured by standard code generation benchmarks. Engineering leaders who rely on published benchmark performance to calibrate agent autonomy are measuring the wrong thing for the decisions they are making.

Setting the Right Autonomy Boundary

The appropriate boundary for agent autonomy in schema work is not a fixed line. It depends on the maturity of the codebase, the quality of the context infrastructure feeding the agent, and the review processes sitting downstream. Agents are well-suited to generating first-draft schemas for new bounded contexts where the conventions are explicit and the write patterns are known. They are poorly suited to modifying existing schemas in systems where the business rules are implicit and the workload characteristics are undocumented.

The practical implication is that extending agent autonomy without first investing in context infrastructure is inverting the right order of operations. An agent with poor repository context will produce plausible-looking schemas that embed subtle structural problems. Those problems will survive code review if reviewers are assessing syntax rather than semantic coherence against the broader system.

The more durable investment is in the evaluation instrumentation: the tooling that lets engineering teams measure agent output quality against production-relevant criteria rather than benchmark proxies. That instrumentation is what makes it possible to extend autonomy deliberately, with a clear picture of where the boundaries actually sit.

Companion piece to our broader work on AI coding agent failure modes in enterprise contexts. See Repository Context: The AI Coding Stack Bottleneck for a detailed treatment of how context architecture determines agent reliability at scale.