The barrier to writing code has completely vanished with modern AI agents spinning up massive repository branches from a single prompt, but engineering teams are quickly realizing that writing lines of code and building scalable, trustworthy architecture are two entirely different things. Recent industry data shows that AI-generated pull requests sit waiting for review over four times longer and face massive rejection rates because while automated tools are brilliant at quick syntax, they are terrible at context—often passing basic local tests while silently violating end-to-end type safety and injecting technical debt that haunts a codebase for months. Most production crashes happen when the client frontend makes an assumption about data that the backend server or the database didn't actually fulfill, and if senior engineers have to manually patch these hallucinations every single time an automated assistant pushes a branch, they spend all day reviewing junk instead of shipping features. The modern invention that completely fixes this bottleneck is a strict architectural shift toward a unified schema layer using Next.js Server Functions paired with type-safe database engines like Supabase, which forces the frontend and backend to read from a single source of truth and creates a compilation-level brick wall that automatically fails a build before a human reviewer ever has to waste time opening the code panel.
Kenneth Macharia
Posted on
I Didn’t Become a Developer to Review AI Slop: The True Cost of "Almost Right" PRs
For further actions, you may consider blocking this person and/or reporting abuse
Top comments (1)
"Almost right" is the precise and painful word, because almost-right is the most expensive output there is - worse than obviously-wrong. Obviously-wrong you reject in five seconds; almost-right looks plausible, passes a skim, and forces a deep review to find the one subtle bug hidden in 200 confident lines. It inverts the work: the human went from author to forensic reviewer of code they didn't write, in a style that isn't theirs, and that's slower and more draining than writing it yourself. AI shifted the bottleneck from generation to verification, and dumping unreviewed almost-right PRs just relocates the cost onto whoever reviews - it doesn't remove it.
The fix isn't "stop using AI," it's making the AI's output get verified before it lands on a human - automated checks, gates, the model held to a standard, not waved through. That's the entire thesis behind how I build Moonshift, the thing I work on - a multi-agent pipeline that takes a prompt to a deployed SaaS, where a verify layer catches the almost-right before it reaches a person, so you're reviewing outcomes, not slop. The goal is to not make a human the slop filter. Multi-model routing keeps a build ~$3 flat, first run free no card. This rant needed writing. Where do you draw the line - reject AI PRs outright, or require the author to actually verify before submitting? I lean on the latter plus automated gates so "almost right" never reaches review.