Build1 distinct publisher3 min readPublished Updated
A dev.to post walks through an eighty-line ALTER TABLE that no reviewer can judge from text, which is the argument for moving the gate off reading and onto a restored copy with real row counts and a clock on the lock.
The Engineer · Build desk
Compiled by The EngineerSomething wrong?How this is made
Take the three questions the post says the diff cannot answer and ask what artifact would answer each one [2]. The NOT NULL without a default is a count: how many rows in `biz_order` hold a null in that column right now. The lock on the type change is a duration: run the statement against a copy carrying production row counts and time it. The down migration is a round trip: apply, revert, diff the resulting schema against the starting state. None of the three is a matter of taste. All three are outputs, and none of them can appear in a character diff.
That is why a reading-based gate loses by construction. Eighty lines of ALTER in three seconds [6] is roughly twenty-seven lines per second [18], against a reviewer whose speed did not change [5]. The screen space goes to `VARCHAR(64)` becoming `VARCHAR(128)`, while the foreign key pointing at the wrong parent sits in the middle looking like any other edit [7]. Stale-schema hallucination lands the same way: an invented join table, or a default on `del_flag` the team never uses, each line executing cleanly and the set of them breaking a query nobody thought to test [8].
The load-bearing constraint in the piece is that you cannot spin up a database for every PR [4]. That is a budget claim, and budgets move. It also sits awkwardly next to the post's own red line, which is production credentials in the IDE, alongside 240-table dumps blowing context and permission-filtered schema producing its own hallucinations [13]. A restored snapshot in CI is not credentials in an editor. And the lock question specifically requires production-shaped row counts, which is exactly why the model's polite "low risk" is worth nothing: it never ran the ALTER against them [10].
On the alternatives, the post's reasoning holds. Filename lints, required down files and sqlfluff confirm format and parseability, not whether the table locks for ten minutes at Tuesday peak [9]. Prisma and Atlas move the reviewed object off raw SQL, but the migration that reaches production can diverge from the declaration, and field-level diffs are still noise [11]. Two approvers gets you two signatures on the same unexecuted statement [12].
Where I part company slightly: the post's target is semantic drift, and it is right that soft-delete conventions, valid status codes and whether an FK should point at `sys_user` rather than `biz_user` live in notes and approved versions, not `information_schema` [14]. Its framing is that the wrong artifact is under review, with no approved intent to align against [15]. Fine. But intent review only becomes cheap once the mechanical questions are answered by a machine, which is the step nobody is funding.
One caution on the source. It is a numbered series, and the text breaks off as it starts describing its own write path, from dumping SQL to declaring intent [17]. The diagnosis is legible. The proposed fix is not something I can evaluate from what was published.
Ranked by verification strength, evidence, and original report placement.
A dev.to post by erdonline describes a Tuesday 3 p.m. PR notification in Slack where a junior asks for review of a migration generated by Cursor, roughly eighty lines of ALTER TABLE with added columns, type changes, indexes and foreign keys.
The post lists three questions the reviewer cannot answer from the diff: whether a NOT NULL on biz_order with no default will pass on existing rows, how long the type change on sys_user locks the table, and whether the down migration actually restores the previous schema.
The PR description in the scenario reads "Agent self-review: should be fine", which the post calls not evidence.
The post argues stricter CI, meaning linting migration file names, requiring down files and running sqlfluff, checks format and parseability rather than whether the change will lock a table for ten minutes at Tuesday peak traffic, so green does not mean approval.
The post says agent self-review returns "low risk" without having run the ALTER against the team's real row counts, making self-review tone rather than acceptance.
The post credits declarative diff tools such as Prisma and Atlas for reporting what changed in the model versus the last revision, but notes the migration that lands in production can diverge from the declaration and that field-level diffs are still noise.
Distinct publishers with included, body-backed reporting in this cluster.
dev.to
1 article · August 29, 2026
Follow any of these and your For You feed starts watching them — no settings page required.
build
Two ways to point Claude at production, and only one of them keeps the password1 distinct publisher
build
255 tool schemas, 91K tokens: pricing the two MCP costs nobody budgets1 distinct publisher
build
AI-written code fails the same four ways, and every gate you own reports green1 distinct publisher
build
Rate limit your MCP servers, because a retrying agent turns one error into a billing incident1 distinct publisher
Evidence-backed comparisons of source perspectives and observed adoption signals. Read the methodology
Which Builder, Operator, and Investor concerns the observed source mix emphasized—not a truth score.
Evidence, demonstrated adoption, hype gap, incentives, and confidence are assessed independently, each on its own current evidence. How these are measured.
One practitioner post, no numbers
Everything traces to a single dev.to essay, and its central scene is a set piece: Tuesday 3 p.m., eighty lines, three seconds. No row counts, no measured lock, no postmortem anyone can pull up. The claims that survive scrutiny do so on their own logic — sqlfluff genuinely cannot tell you how long a type change blocks writes, and a diff genuinely cannot tell you whether a NOT NULL passes on existing rows. The sweeping ones, "no human can review at this speed" and "you cannot spin up a database for every PR", are asserted and left standing. The text also stops mid-sentence, so even the author's own remedy is only partly on the page.
Nothing yet to count
Nobody is counted. The nearest thing to a deployment fact is erdonline describing its own tooling — create_version as the single write path an agent gets — which tells you what the product permits, not that one team has put it in front of a migration. No installs, no named users, no before-and-after on a real schema.
Diagnosis earned, cure asserted
The gap is not in the problem, it is in the fix. Reviewers waving through generated DDL they cannot evaluate is a believable failure, and the post describes it better than most. But "you are reviewing the wrong artifact" is delivered as settled, and the cure — declare intent, save a named version, diff in the designer — arrives with no evidence that a semantic diff catches the missing join table any more reliably than a slow SQL read by someone who knows the schema. The alternatives get less scrutiny than the conclusion: per-pull-request databases are denied in a sentence, Atlas and Prisma are credited and then waved off.
The byline is the product
This runs on erdonline's own account, the argument lands on erdonline's designer and its create_version endpoint, and the line built to be remembered — "API 200 is not human approval" — is positioning for that workflow. None of which makes the observation about blind-signing wrong. It does mean the problem was framed by someone who already knew which product would close it, and the reader is never told so.
Solid on the text, untested on the world
Confidence splits cleanly by claim type. What the post says, including what it says about its own MCP surface, is fixed and checkable by reading it. Whether agent-written migrations are actually breaking production more often, and whether intent-diffing prevents that, is untested here and uncorroborated anywhere else in our coverage — one publisher, one author, one interest, and half a proposal.