You Still Need Software Engineers

AI coding tools are the best thing to happen to software in a decade. They’re also the fastest way to flood your codebase with garbage you’ll pay to clean up later.

Both of those are true at the same time, and most of the takes I read online pick one and ignore the other.

The slop problem

Ask a model to add a feature. It adds the feature. It also adds a helper function you didn’t need, a config flag nobody will ever flip, a new abstraction “for flexibility,” and a utility file that duplicates something already living three folders over.

None of it is wrong. All of it is slop.

Slop is code that compiles, passes tests, ships to production, and makes your system a little worse. A little slower. A little harder to reason about. Slightly more expensive to change next time.

One slop commit is invisible. A hundred of them is a codebase nobody wants to touch.

Why models generate slop

Coding models optimize for the prompt in front of them. Not the system, not the product, not the team that will inherit this code in eighteen months.

You ask for a login button. You get a login button, a ButtonFactory, a theme provider, and a new directory called components/auth/shared/. The model isn’t being malicious. It’s pattern-matching on “how professional React code looks” and giving you the full kit.

Multiply this by every ticket, every bug fix, every small tweak. That’s how a clean repo becomes a swamp in six months.

Humans do this too. The difference is throughput. A model can generate more slop in an afternoon than a junior developer produces in a quarter.

A concrete example

Recently I looked at a small marketing site a client had “vibe-coded” with an AI assistant. Fifteen pages. Should have been a weekend.

What I found: four different ways of handling form submissions. Three overlapping utility libraries. A state management solution installed but never used. Two component libraries fighting each other. An image optimization pipeline built from scratch next to the built-in one the framework already provided.

Every individual decision made sense when it was made. The sum was a site that loaded slowly, failed accessibility audits, and cost three times what it should to modify.

Nobody had been at the wheel. The model was helpful every single prompt. The product was a mess.

What engineers actually do now

The job has changed. It’s no longer mostly about typing code. Models are faster typists than we are. Fine.

The job is:

Saying no. The model proposes an abstraction. The engineer deletes it. The feature ships with fifty fewer lines.

Holding the shape. Knowing when a module is straining under too much responsibility, and splitting it before it becomes a liability. Models don’t feel this. Engineers do.

Reviewing at the system level. Not “does this code work”, models handle that. But “does this code belong, given what we’re building and where we’re going”. That question requires a human who has held the product in their head for longer than a context window.

Deleting. The most valuable commit of the week is often the one with a negative line count. Models almost never suggest it.

The business case

If you’re running a business and wondering whether this matters to you: it does.

Slop has a price. You pay it as slower page loads that lose you conversions. As a site that breaks on mobile because nobody noticed the bundle ballooned. As a rebuild in two years because the codebase you generated in a weekend is too tangled to extend.

The cheap version now is the expensive version later. AI tools didn’t change that, they just let you ring up the bill faster.

The “it won’t matter soon” argument

Some people will tell you the models will handle all of this in a year or two. Full ownership of the codebase. No humans required.

Maybe. I’m not betting my clients’ businesses on it.

Today, models lose the thread across large systems. They don’t hold your product vision. They don’t know which compromises you made last quarter and why. They don’t know your customers. Until they do, reliably, across months of work, you need someone who does.

And even when that day comes, the people best positioned to supervise it will be the engineers who know what good looks like. The ones who learned to recognize slop when they saw it.

The real shift

The question isn’t “do we still need engineers”. It’s “do we need as many, and doing what”.

Fewer people writing boilerplate. More people thinking about systems, products, and the long-term health of the code. Less typing, more judgment.

At LiberateWeb, this is exactly how we work. We use modern AI tooling aggressively, it’s how we ship fast and keep costs sane. But every line of code that goes into a client site is there because an engineer decided it should be. Not because a model suggested it and nobody pushed back.

That’s the difference between a website that runs your business and a website that becomes one of its problems.