Calling AI Code Slop Is Lazy

The script barely changes

When Twitter hit scaling problems in the late 2000s, the narrative wrote itself. Rails can't handle real production. It's a toy framework for people who don't understand systems engineering. Twitter's fail whale became the symbol of an entire class of criticism: that Ruby on Rails was fundamentally unsuited to serious work, and that anyone building on it was accumulating technical debt they would eventually have to pay in full.^[1]

The criticism was specific and technical. Rails was slow. It didn't scale. It encouraged sloppy architecture. It let people who didn't understand database indexing or connection pooling ship production applications. The complaints came from experienced engineers who had legitimate concerns about a new tool that was rapidly lowering the barrier to web development.

Now replace "Rails" with "AI coding tools" and the script barely changes. Code that looks right but isn't. Newcomers skipping fundamentals. A flood of low-quality output from people who can't explain what they shipped. The concerns are legitimate. Independent academic research has found higher vulnerability rates in AI-generated code than in human-written code, with one widely cited study reporting roughly 14% of AI-generated snippets containing security vulnerabilities compared with about 9% in human-written code.^[2] Developer trust in AI-generated code accuracy has fallen from 40% to 29%.^[3] Open source maintainers report being inundated with low-quality AI-generated pull requests.^[4]

The quality concerns are real. But the conclusion people draw from them is where the Rails parallel becomes instructive.

What actually happened with Rails

Twitter migrated off Rails between 2010 and 2011, moving to Java and Scala on the JVM. The performance gains were dramatic: from 200 to 300 requests per second per host to 10,000 to 20,000 requests per second.^[1] The fail whale was eventually retired in 2015. Case closed, apparently: Rails couldn't scale.

Except it wasn't case closed, because while Twitter was migrating away from Rails, other companies were building on it.

GitHub launched on Rails in 2008. Its main web application still runs on Rails today, serving one of the largest developer platforms in the world, and the team has been incrementally evolving the architecture through Ruby 3.x and Rails 7+ while decomposing performance-critical components into Go, Rust, and TypeScript.^[5] Shopify has been running on Rails since 2006. Their monolith is one of the oldest and largest Rails codebases under continuous development: 2.8+ million lines of Ruby, 500,000+ commits, over 3,100 engineers scaling a single monolith that handled roughly 489 million requests per minute at peak and over 53 million database queries per second on Black Friday 2025, with the broader BFCM weekend generating about $14.6 billion in merchant sales.^[6][7]

Airbnb built on Rails and grew to serve 150+ million users.^[8] Kickstarter, Twitch, and Square followed the same path. The "toy framework" produced some of the most successful technology companies of the 2010s.

The Rails naysayers were not wrong about the problems. Spaghetti codebases happened. Scaling nightmares happened. Junior developers built applications they could not maintain. But they were wrong about the trajectory. The community adapted. Patterns emerged. Best practices solidified. The framework matured. And the baseline of what a small team could build went up, not down.

The democratisation pattern

Rails was not the first technology to draw this kind of criticism, and it was not the last. The pattern is older than web development itself.

PHP lowered the barrier to server-side web programming in the late 1990s. The criticism was immediate: spaghetti code, SQL injection vulnerabilities, developers who didn't understand the HTTP request cycle building production applications. PHP was "the BASIC of the web." And PHP went on to power WordPress, which runs a significant share of the web's content management layer, and Facebook, which scaled PHP through custom compilation (HipHop, then HHVM) rather than abandoning it.

Visual Basic democratised Windows application development in the early 1990s. Professional C++ developers dismissed it as a toy. VB applications were slow, poorly architected, and written by people who, in the critics' view, had no business building software. Visual Basic went on to become the dominant language for business application development for a decade, and its descendants (VB.NET, VBA in Excel) remain embedded in enterprise workflows today.

In each case, the criticism followed the same structure. A new tool lowers the barrier to entry. The volume of low-quality output increases. Experienced practitioners conclude that the tool is the problem. And in each case, the experienced practitioners were right about the quality floor dropping, but wrong about what happened next. The quality floor dropped, but the ceiling rose. The skilled practitioners who learned to use the new tool effectively became more productive, not less. And the ecosystem matured around the tool, producing patterns, conventions, linting, testing frameworks, and community standards that gradually raised the floor back up.

Where the AI parallel holds

The adoption numbers for AI coding tools in 2025 and 2026 look remarkably like Rails adoption in 2006 and 2007: exponential growth driven by a genuine productivity advantage, accompanied by legitimate quality concerns.

GitHub Copilot crossed 20 million users by mid-2025, with 4.7 million paid subscribers by January 2026 and 90% of Fortune 100 companies using it.^[9][10] Cursor reached over 1 million daily active users and crossed $2 billion in annualised revenue by February 2026, used across more than half of the Fortune 500.^[11] The 2025 Stack Overflow Developer Survey found that 84% of developers are using or planning to use AI coding tools, with 51% using them daily.^[12]

The quality concerns are equally real. The academic research on AI code vulnerabilities raises legitimate concerns.^[2] Roughly one in five AI suggestions contains factual errors or misleading code, according to developer surveys.^[3] The cURL project reported that 20% of bug bounty submissions were AI-generated by 2025, with only a 5% validity rate.^[4] There is evidence that experienced teams can lose productivity when applying AI to complex tasks, as the overhead of reviewing and correcting AI output exceeds the time saved in generating it.^[3]

But none of this is evidence that AI coding tools are a dead end. It is evidence that they are in the early phase of the democratisation pattern, the phase where the quality floor has dropped and the ecosystem has not yet matured to compensate.

Where the AI parallel breaks down

The honest version of this argument requires acknowledging where the Rails analogy has limits. Rails was a framework: a set of conventions and abstractions that structured how developers wrote code. Developers still wrote the code. They still understood (or failed to understand) what their code did. The failure mode was poor architecture, not code they couldn't read.

AI coding tools introduce a qualitatively different failure mode: code that the developer who shipped it does not fully understand. When Copilot generates a function, the developer may accept it without tracing the logic, without understanding the edge cases, without recognising the security implications. This is different from writing bad code yourself. It is closer to deploying code written by a contractor you cannot interview.

This distinction matters for operational reliability. A developer who wrote bad Rails code could, with effort, learn to understand and fix it. A developer who accepted AI-generated code they did not understand is in a fundamentally different position when that code fails in production at 3am. The debugging surface is larger because the developer's mental model of the system has gaps that correspond exactly to the places where they deferred to the AI.

The counter-argument is that this gap is temporary. AI tools are improving rapidly at explaining their output, test generation is becoming more integrated into the generation process, and the developer tooling ecosystem around AI code is maturing in the same way that testing frameworks and linting tools matured around Rails. This counter-argument is probably correct in trajectory, but it is not yet correct in practice. The tooling maturation has not caught up with the adoption curve.

What the Rails story actually teaches

The useful lesson from Rails is not that the critics were wrong. Many of them were right about specific technical problems. The useful lesson is that they were right about the problems and wrong about the conclusion they drew from those problems.

The conclusion the Rails critics drew was: this tool produces bad code, therefore this tool is bad, therefore serious engineers should avoid it. The conclusion the market reached was: this tool produces bad code now, but it also produces more code faster, and the ecosystem will mature to address the quality problems, and the net effect will be that more things get built by smaller teams at lower cost.

The developers who were still arguing that Rails couldn't scale in 2015, five years after Shopify had proven otherwise, had confused a snapshot of the technology's current state with a prediction about its trajectory. They were indexing on Twitter's migration as definitive evidence while ignoring GitHub's continued scaling on Rails as a counter-example.

The developers writing "AI code is slop" in 2025 and 2026 are making the same category of error. They are indexing on the quality of AI-generated code today and concluding that AI coding tools are fundamentally flawed, rather than recognising that they are observing the early phase of a technology adoption curve that has historically resolved its quality problems through ecosystem maturation.

The operational implication

For teams that run production infrastructure, the practical question is not whether AI-generated code is good or bad. It is whether your operational tooling can handle a codebase where an increasing proportion of the code was generated rather than written.

This has specific consequences for database operations. AI coding tools generate database queries, schema migrations, ORM configurations, and connection handling code. Some of that code works correctly. Some of it introduces subtle performance problems: N+1 queries that don't surface until traffic scales, missing indexes on columns that the AI-generated code queries by, connection pool configurations that work in development but exhaust connections under production load.

The default-driven adoption pattern we see with PostgreSQL is about to get a second layer. It is not just that developers end up on PostgreSQL without choosing it. It is that the code interacting with that PostgreSQL instance was generated by a tool that optimised for plausibility rather than performance. The database was chosen by a toolchain, and the queries against it were generated by an AI. The human in the loop may have reviewed neither decision.

For database reliability engineers, this means the observability layer becomes more important, not less. When the developer who shipped the code can explain their intent, debugging is a conversation. When the code was generated and accepted without deep understanding, debugging is forensic analysis. The cost of database incidents does not decrease because the code was generated faster. If anything, it increases, because the path from symptom to root cause now passes through code that the on-call engineer may not have a mental model for.

Riding the wave, not dismissing it

The developers who thrived during the Rails era were not the ones who dismissed it as a toy, and they were not the ones who adopted it uncritically. They were the ones who understood what Rails was good at (rapid prototyping, convention over configuration, developer productivity) and what it was bad at (CPU-intensive computation, real-time systems, workloads that exceeded the framework's architectural assumptions), and who built accordingly.

The same approach applies to AI coding tools. The question is not whether they produce slop. They do, some of the time, just as Rails produced spaghetti code some of the time. The question is whether you understand the failure modes well enough to use the tool effectively, and whether your operational infrastructure (testing, monitoring, observability, incident response) is built to catch the problems that AI-generated code introduces before they reach production.

Dismissing the entire category as "slop" is the 2026 equivalent of dismissing Rails as a toy in 2008. It feels correct in the moment. It ages poorly.