Is AI Slop Ruining Engineering?

This week, developers are drowning in AI-generated PRs, and they’re sick of it. One engineer put it bluntly: what's my purpose as an engineer if I'm just reviewing AI slop?

I asked our engineering leadership team what's actually going on. Here's what they said.

Every Industrial Revolution Has a Messy Transition Phase

Hari Chandrasekhar (SVP of Engineering, Core)

The integration of AI is undeniably shifting the nature of software engineering, offloading the routine work of writing code to AI systems. Consequently, the developer's role is elevating from mere code creation to high-level system design, focusing on architecture, framework resilience, and scalability.

This is a natural technological progression similar to the Industrial Revolution's shift from hand-weaving to the mechanized power loom. Early textile workers went from manually threading every single line to operating and troubleshooting complex machines. 

While those early machines often tangled or snapped threads, requiring intense and frustrating oversight, the worker's role ultimately and permanently evolved from manual labor to system orchestration.

That said, the engineer's responsibility hasn't fully transferred. AI is groundbreaking, but a great deal of context in the development cycle is implicit knowledge shared among product managers, analysts, designers, and developers that may not be obvious to an AI orchestrating the work. 

Until that context gap is closed, there will be a transition period where engineers must actively steer AI towards expected results; bad output and slowness will cause real frustration in the meantime. The more context the system has, the better the results.

"There will be a transition period where engineers must actively steer AI towards expected results; bad output and slowness will cause real frustration in the meantime."

Hari Chandrasekhar

SVP of Engineering, Core

This growing pain is very similar to the automotive transition from manual to automatic transmissions. Early drivers of automatic cars often felt the vehicle wasn't shifting efficiently, and constantly wanted to manually override the gears. At the time, this instinct was probably right. 

However, as automotive engineering improved, drivers stopped caring about the internal mechanics of the transmission. They just wanted a smooth, efficient drive. 

As AI systems mature and context windows deepen, the granular, line-by-line internal workings of the generated code won't matter nearly as much. The ultimate measure of an engineer's success will simply be whether the end product is reliable, scalable, and built to meet the needs of the business.

AI Isn’t an Engineer, and We Need To Stop Treating It Like One

Nikhil Gopinath Kurup (SVP of Engineering, ML)

The real issue underlying the AI code bottleneck is trust. We review code because we don't trust it. We don't trust other humans completely, and we certainly don't trust AI to grasp architecture, design principles, or business requirements.

For instance, I wouldn't feel the need to review code written by Fabrice Bellard (nor would I feel qualified to do so) because the trust in his capability is absolute. Similarly, we never review the binary code a compiler outputs because we trust the tool to faithfully and unambiguously translate our intent.

Our current mistake is treating AI as the equivalent of a human developer and forcing it into standard peer-review processes. AI code has distinct merits and severe weaknesses. Forcing engineers to babysit an endless stream of context-free PRs just shows that our current workflow is broken.

"AI code has distinct merits and severe weaknesses. Forcing engineers to babysit an endless stream of context-free PRs just shows that our current workflow is broken."

Nikhil Gopinath Kurup

SVP of Engineering, ML

The solution isn't to force AI into our old ways of working. We need to build entirely new engineering processes, better automated tooling, and a fundamentally new way of delivering software. The goal is to evolve our methodology until AI output becomes as predictable, reliable, and trusted as a compiler.

Once that workflow is established, the role of the engineer moves one level higher. Instead of doing the grunt work of writing code and checking syntax, developers will focus entirely on design, specifications, and architecture.

Personally, I hate that this removes the raw creativity and fun of writing code line-by-line. But practically, it is the only way forward. If developers are trapped reviewing AI slop, we are stuck in a poorly managed transition phase. The future engineer isn't a coder; they are a solution builder who owns the pipeline from the starting problem to the working product.

Review Fatigue Sucks, but It Won’t Last Forever

Benjamin Thomas (Co-Founder & CTO)

Yes, developers are spending more time reviewing code right now, but I think the current bottleneck is a transitional problem, not a permanent one. A few shifts are already underway that will shorten that cycle significantly.

First, planning and design will move upstream, similar to how traditional design reviews worked — where AI-generated approaches get vetted early, before a single PR is ever opened. 

Second, senior engineers will start building their own skills, playbooks, and spec files that encode their standards and architectural context. This will make reviews progressively faster over time. 

"PR reviews will evolve to be AI-assisted, evaluating design, approach, and implementation together, rather than treating code as the only artifact that matters."

Benjamin Thomas

Co-Founder & CTO

Third, teams can now realistically demand 100% unit and integration test coverage for far more scenarios than was ever practical before. That alone changes the quality bar at the point of submission. 

And finally, PR reviews themselves will evolve to be AI-assisted, evaluating design, approach, and implementation together, rather than treating code as the only artifact that matters.

Each of these shifts individually helps. Together, they compress the review cycle in a meaningful way. The frustration people are feeling today is real, but it's a symptom of old processes meeting new tools. It’s not a signal that the tools don't work.

Engineering Is Becoming About Judgement, Not Writing Code

Shankar Jothi (VP of Engineering, ML)

In the near term, I expect review and judgment to become even more important engineering skills. The bottleneck is moving from code creation to code validation. That doesn't necessarily mean developers become full-time reviewers, but it does mean the value of context, system knowledge, architectural thinking, and accountability increases. 

AI can help produce code quickly, but someone still needs to understand how that code fits into a larger system and whether it should exist in the first place.

I also think we're still in a transitional period. Many teams are experimenting with AI-assisted development, but the surrounding processes haven't fully adapted yet. 

"Developers won’t become full-time reviewers, but the value of context, system knowledge, architectural thinking, and accountability is increasing."

Shankar Jothi

VP of Engineering, ML

Code review workflows, testing practices, ownership, and engineering standards were largely designed around humans writing code. As AI becomes a larger contributor, teams will likely need new ways to establish trust and quality without creating review bottlenecks that slow everyone down.

For me, the role of the developer is not becoming less important; it's becoming more focused on higher-leverage decisions. Writing code will remain part of the job, but understanding systems, defining requirements, evaluating trade-offs, and ensuring quality across increasingly automated workflows may become an even larger part of engineering. 

The tools are changing rapidly, but the need for technical judgment and accountability remains constant.

Code Quality Is Collapsing in the Age of Infinite PRs

Suresh Mathew (CEO)

The real problem isn't that developers are becoming reviewers, it’s that the bar for code submissions has collapsed. When generating a PR costs nothing, and everyone submits, the quality of our code disintegrates. 

And there's no going back. METR's follow-up study couldn't get clean data on whether AI actually makes developers more productive — no one would work without it long enough to form a control group. 

The dependency on AI is structural now, and moving forward means figuring out how to keep reviews rigorous without becoming the bottleneck.

The way your team reviews and ships code is changing fast. See how Sedai helps engineering teams keep up.