My recent experience

Nothing clarifies the trajectory of modern software engineering quite like sudden contrast. After two weeks of AI-free development on private projects, returning to our enterprise codebase wasn't just a routine transition back to work; it was an immediate, unmistakable key moment that exposed how dramatically our code culture is shifting.

The problem hit me the moment I started reviewing the recent pull requests: our repository is drowning in synthetic bloat. Instead of deliberate code with human intent, I was met with walls of homogenized, autogenerated sludge. Code that can be described as generated and a bit 'off' and exhausting multi-line German comments. This really felt alien, like auditing clanker code that had technically met the acceptance criteria, but lacked any semblance of creativity, beauty or restraint.

The Boiling Frog and the Reset

To understand why this hit me so hard, you have to understand the boiling frog effect. When you are immersed in a modern enterprise team day in and day out, the degradation doesn't happen overnight. It creeps in commit by commit; pull request by pull request. You slowly adjust your baseline: an autogenerated helper here, a slightly verbose wrapper there, another pull request cluttered with generated multi-line German. You accept the slight drag on readability because everyone is doing it, convincing yourself this is just what velocity looks like now. The temperature rises, and you don't realize you are being boiled alive in mediocrity.

This is ever so accelerated by the few (hopefully staying a small number) AI hardliners in the team. They are 100% into agentic coding and do not see the obvious problems with it. Here is one example, of how this not only impacts the codebase long-term, but how it personally affected my mood:

Weaponized Velocity: The Agentic Sidecar PR

Before leaving for zero-AI vacation, I opened a substantial pull request, roughly 600 files touching multiple domains as part of a major subsystem rework. (Yes, 600 files is large, but it was a planned architectural refactor where the changes were coherent, domain-driven, and structurally consistent.) A change of that scale inevitably carries edge cases and subtle cross-domain implications that demand careful scrutiny.

When I returned, the difference between human collaboration and uncurated AI throughput was laid obviously.

One colleague did what great engineers do: he sat down, applied his deep domain expertise, and pointed out actual architectural gaps and subtle regressions that only a person with context could catch. That review was invaluable; it made the system meaningfully better.

Then came the AI hardliner.

Instead of reading through my work and providing targeted review comments with real improvements, he pointed an agentic coding workflow at my branch and opened a medium-sized, fully generated 'sidecar' pull request filled with purported 'improvements'.

Sifting through it felt like wading through mental fog. Roughly 80% of the diff consisted of purely subjective churn: stylistic reshuffling, unnecessary changes, and even new bugs and problems! Scattered inside the remaining 20% were genuinely interesting ideas, because if an LLM throws enough code at the wall, a few fragments will inevitably stick. Yet even those few salvageable concepts were implemented awkwardly, half-baked, and divorced from my overall idea and architecture of my PR.

I ended up cherry-picking the couple of good ideas and re-implementing them cleanly by hand. But the experience left a distinctly bitter taste.

Opening a thousand lines of unvetted, autogenerated changes against an already complex PR is not a contribution; it is lacking of any editorial responsibility. It drowned out genuine domain feedback in favor of synthetic volume. It took the author three minutes to prompt an agent to vomit out that diff, while offloading hours of tedious triage onto me just to separate the few nuggets of value from the surrounding sludge.

Example of some of the code changed in the side-car PR

To give you a taste of the kind of 'optimizations' I was wading through, consider this gem. I had written a straightforward, idiomatic static initialization:

public class ExampleClass
{
   public static readonly bool IsActive = CalculateDefault();
}

The AI agent, in its infinite, hallucinatory wisdom, decided this was far too simple and 'improved' it into this (Keep in mind the PR was titled to simplify some things):

public class ExampleClass
{
   public static readonly bool IsActive = Cache.IsActive;

   private static class Cache
   {
      public static readonly bool IsActiveCached = CalculateDefault();
   }
}

Read that again.

The agent essentially added an entire nested class to cache a static variable inside... another static variable. It applied a cargo pattern from .NET 1.1 meant for lazy initialization, except ExampleClass eagerly evaluates the nested field on load anyway! It accomplished absolutely nothing. It didn't make the runtime faster, it didn't save memory, and it didn't add safety.

The Asymmetry of Modern Code Review: Shifting the Cognitive Tax

What happened with that sidecar pull request wasn't an isolated incident; it was a symptom of a profound imbalance silently taking over engineering teams. Generative AI has broken the social contract of the code review by introducing a massive asymmetry between producing code and verifying it.

Before agentic workflows, writing code was inherently self-throttling. The cognitive effort required to design a solution, type it out, and shape it into a cohesive change acted as a natural filter against mindless volume. Even messy code represented deliberate human thought that could be engaged with on human terms.

Writing Models by hand and iterating over classes and designs until you are at your destination, gives code the human intent and thought. Something that is lost a lot with agentic code. At least how a lot of developers use it; I am not saying it could not be done with agentic, but I am yet to see someone actually achieving it with agentic

Today, it takes an author thirty seconds to type a prompt, five seconds to skim the output, and one click to open a pull request with hundreds of changed lines. The cost of creation has dropped to near zero. But the cost of auditing hasn't dropped a single percentage point.

This workflow is essentially an externality. The author gets to claim immense 'velocity' by generating massive diffs, while offloading the grueling cognitive labor of actual quality control onto their teammates.

When engineers are bombarded daily with sprawling, multi-hundred-line diffs of syntactically valid 'mush', their mental defenses inevitably wear down. Nobody has the stamina to forensically audit dozens of pages of mediocre boilerplate day in and day out. Eventually, standards slip. Reviews degrade into passive scans for formatting, superficial glances at test suites, and rubber-stamp approvals the moment the CI pipeline turns green.

The tragic irony is that codebases don't decay because agents fail to write working code. They decay because they generate so much superficially acceptable noise that the humans responsible for protecting the architecture simply give up trying to change it to a human acceptable range.

Restoring Software Craft: A Call for Editorial Discipline

Critiquing this trend is not about anti-tech Luddism or romanticizing punch cards. Generative models and agents are remarkable technical feats. But confusing generative raw output with finished software engineering is slowly choking codebases around the world.

If it were entirely up to me, unvetted generative code simply wouldn't be allowed in production repositories. Realistically, though, tools like this aren't going away. If teams want to survive this wave without turning their systems into unmaintainable landfills of cognitive sludge, we must re-anchor ourselves to what software craft actually means:

True software craft isn't code that merely passes tests. It is code that is cognitively cheap to read, predictable to reason about, and merciful to debug when a production incident fires.

(There are of course more targets like performance etc. depending on the code and use-case)

If you choose to leverage generative AI in your development workflow, the fundamental nature of your day-to-day role shifts. Your primary job is no longer typing; Best case: it is aggressive editing (I doubt that everyone even bothers editing it a lot).

To protect codebases from death by synthetic sludge, teams need clear, non-negotiable boundaries:

• Zero Unedited Agent Output in Pull Requests
  A pull request must reflect the author’s conscious intent, not an agent’s raw token stream. If a diff looks like a prompt regurgitation, it should be closed without review.
• Mandatory Removal of Generated Noise
  Eliminate redundant, auto-generated comment bloat. If a two-line Linq query or basic variable initialization requires a five-line comment explaining trivial mechanics, either rewrite the code to make it self-evident or delete the comment entirely.
• Total Ownership of Every Line
  An author must be able to defend why every line, class, and abstraction exists in their PR. "The AI suggested it" or "the agent generated this optimization" are immediate red flags indicating the author has outsourced their critical thinking.
• Respect the Review Queue
  Reviewers are colleagues, not human linters. Do not offload your testing, formatting, or architectural triage onto someone else simply because an agent made it effortless to generate the diff.

Generative velocity is a vanity metric if it leaves behind code that nobody wants to maintain. Real speed comes from clarity, cohesion, and restraint.

If you want to dive deeper into how I approach writing software without succumbing to this gradual erosion of quality, I put together a companion piece: How I Stay a Good Software Engineer Despite AI.

The Uncomfortable Reality: These Rules will not save us

Having laid out all these rules and principles, I have to be completely honest with myself: it probably won't work.

Rules require enforcement, and enforcement requires energy; the exact resource that this endless flood of synthetic code systematically drains from teams. When an organization incentivizes raw output and celebrates 'AI-driven velocity', the social pressure flips. The engineer demanding high craft and rejecting unedited sludge becomes labeled a bottleneck, a grumpy gatekeeper slowing down the sprint metrics.

Stand Your Ground

Yet despite the fatigue and the cynicism, not everyone is giving up.

There are still developers who care deeply about what they ship. Engineers who take pride in elegant architecture, clean abstractions, and writing code meant to be read by human beings, not just ingested by compilers. People who recognize that true speed comes from clarity and restraint, not from hitting a prompt and drowning their teammates in cognitive sludge.

To everyone out there refusing to rubber-stamp the noise, pushing back on uncurated agent dumps, and protecting the craft: stay strong, brothers and sisters.

It can feel exhausting and increasingly lonely to swim against the current of mindless generative hype. But software craft matters, domain intent matters, and the human thought you put into your systems matters. Keep your standards high, keep pruning the bloat, and don't let the clankers take the wheel.

A Love Letter to the Craft

Strip away the sprint burndowns, the agentic tooling, the corporate velocity metrics, and the endless pull request queues.

Why did we choose this work in the first place?

We started writing software because programming, at its core, is a deeply human act of creative logic.

There is an quiet joy in taking an amorphous, chaotic problem and shaping it into something crisp, minimal, and clear. It is the satisfaction of finding just the right abstraction; not because a framework demands it, but because it brings instant clarity to a domain. It is staring at a complicated subsystem for three days, realizing you can delete half of it, and feeling the tangible lightness of the codebase afterward.

Programming has never just been about generating tokens or moving tickets across a board. It is the thrill of understanding. It is holding a complex mental model entirely in your mind, feeling the gears interlock, and translating human intent into deterministic behavior.

Code is written for compilers to execute, but it is authored for humans to read, understand, and shepherd through time. It is an intellectual signature. When someone inspects a well-crafted codebase, they can feel the empathy of the engineers who walked those paths before them: the deliberate boundaries, the restrained patterns, the quiet avoidance of unnecessary noise.

Generative agents can spit out thousands of syntactically valid lines in seconds, but they cannot care about what they build. They don't feel the pride of a clean design, the weight of an unaddressed edge case, or the mercy of writing code that won't ruin a teammate's weekend when an alert fires.

That care belongs entirely to us.

Tools will evolve, workflows will shift, and the pressure to trade depth for volume will only intensify. But the craft remains. Keep pruning the bloat, protect the architecture, and refuse to surrender the joy of deliberate thought.

The code we write still matters.

Long after the hype fades and the synthetic noise clears, a truly great codebase will still be what it has always been at its best: not a mechanical output to be endured, but a quiet sanctuary of human intent; a canvas painted with care, meant to offer shelter to the next developer who walks inside.