The Slop Coding Era

Open LinkedIn on any given day and you'll find dozens of posts proudly declaring: "I don't write code anymore, AI does it all for me." Scroll through the comments, and you'll see a chorus of agreement. We've entered what I call the slop coding era, where quantity of output is celebrated and quality and outcome is an afterthought.

The hype machine

Let's start with the terminology. The industry keeps calling it "AI" as if we're dealing with actual intelligence. We're not. These are generative language models trained on statistical patterns. Calling it AI is arguably the biggest marketing scam of our decade. It sounds impressive, it sells tokens, and it makes everyone feel like the future has arrived. But precision in language matters, especially for engineers.

Now look at who's pushing the "I never code anymore" narrative. Most of them carry titles like "AI Engineer", "AI Trainer", or "AI Consultant." Their livelihood depends on the hype. Are they being honest, or is this only self-marketing? It's hard to tell. And that's part of the problem.

Then there are the AI providers themselves. They have every incentive to make us believe that coding is becoming obsolete. More belief in full automation means more token consumption. Are they being honest about what their tools can and can't do? You can decide for yourself.

Sometimes also it feels like this is the revenge of low-skill developers. Those who never invested in understanding software design, architecture, or maintainability now claim the playing field has been leveled. But producing code and engineering software are two very different things. These are the same people who produce spaghetti code in record time, which makes managers so happy. However, they leave the company after a few months, leaving behind a huge technical debt. Continuous illusion of hardworking and productive managers and “experts“.

The danger hidden in the darkness

Here's something that should concern every serious developer: the more you rely on GenAI to write your code, the more your own skills degrade. It's a slow process. You stop thinking through problems because the tool gives you an answer in seconds. You stop learning patterns because you never need to write them from scratch. One day you realize you can't debug the code your own tool generated or even you can't prompt because you no longer deeply understand what's happening.

And the code itself? It's not always good. GenAI doesn't understand your domain, your constraints, or the long-term consequences of its choices. As the codebase grows, the generated code becomes a nightmare to maintain and debug.

This has a broader consequence that few people discuss: innovation and open-source could suffer from this. GenAI struggles with anything outside the well-trodden path. It works best with mainstream frameworks and popular libraries because that's what it was trained on. If developers increasingly depend on it, who will build the next unconventional framework or library? Who will challenge existing paradigms? The tools are biased toward the average, and they'll push us all in that direction if we let them.

The false promise of techniques

"Just use agentic loops." "Just write specs and let the AI implement them." "Just do test-driven development with AI." "Just follow the latest Anthropic hype" I've heard all of these, and I've tried most of them. They work for some cases, but they are not sustainable for everything.

These techniques add layers of complexity. You end up spending as much time steering the GenAI, reviewing its output, fixing its mistakes, and re-prompting as you would have spent writing the code yourself. Sometimes more. The illusion of productivity is strong, but the reality is often different.

What GenAI actually does

I believe GenAI is not intended to generate code for humans. It generates code that is statistically close to what you ask for. It's reproducing patterns it has seen before, not solving problems. It doesn't reason about your architecture. It doesn't understand why a particular design decision matters.

But is this a problem? Not always. For some use cases, "statistically close" is perfectly fine. It's OK to have a verbose and twisted code as long as the LLM can understand it with minimal token consumption.

And that's where we need to be strategic.

Domain Driven Design to the rescue, again

If you're familiar with Strategic Domain Driven Design, you know that not all parts of a software system carry the same weight. DDD distinguishes between:

• Core domains: where your business differentiates itself. This is where competitive advantage lives and where the deepest understanding of the problem is required.

• Supporting domains: necessary but not differentiating. They support the core but don't define your business.

• Generic domains: solved problems. Authentication, email sending, CRUD operations, standard integrations.

This distinction is exactly what we need to decide where GenAI belongs.

Supporting domains, sometimes generic domains, or small microservices are good candidates for GenAI-assisted development. The patterns are known, the stakes are lower, and "good enough" is truly good enough. You don't even need to read or fully understand every line of the generated code, as long as it works and passes tests, it serves its purpose. Let the tool do the heavy lifting there.

But for core domains, it's the opposite. We should absolutely resist the temptation to hand over control. This is where your deepest business logic lives. This is where subtle bugs cost real money. This is where you need to understand every line of code, and where "statistically close" is not acceptable.

In core domains, GenAI should be limited to:

• Completing a function you've already started writing

• Simplifying or optimizing an existing piece of code

• Replicating a well-written feature following patterns you've established

• Handling repetitive code that follows a clear, validated structure

In other words, you lead, the tool follows. Not the other way around.

I wrote previously about the right way to code with GenAI that you can check out.

Stop following the hype

I'm tired of the trends. I'm tired of the breathless LinkedIn posts. After testing many solutions and approaches, I've found my own way of using GenAI, and it starts with being honest about what it can and can't do.

The developers who will build lasting software are those who keep their skills sharp, think critically about their tools, and refuse to let marketing narratives dictate how they work. GenAI is useful. It's not magic. And treating it as magic is how you end up with a codebase nobody can maintain, not even the GenAI itself.