AI Code Is Not Slop. Bad Process Is.

AI code is not automatically slop. It is automatically untrusted.

I keep seeing versions of the same take: AI-generated code is sloppy, shallow, full of security holes, and beneath the standards of serious software engineering.

I get where that comes from. Earlier models often produced code that looked useful in isolation, then collapsed the second you asked it to handle edge cases, integrate with a real system, or explain the security model.

But I do not think that is a fair description of where we are now.

Modern models can generate pretty solid code, especially when they have real context, clear constraints, and a feedback loop. They still make mistakes. They still need review. They still need tests. They still need someone who understands the system to steer the work.

So did humans.

That is the part of the AI slop narrative that feels off to me. Anyone who has spent enough time in production systems has seen human written code much sloppier than what any LLM generates.

Not in toy repos. In real companies. In revenue paths. In systems with dashboards, on-call rotations, security reviews, and customers.

Slop was already in production

There is a convenient myth hiding inside a lot of AI criticism: before the machines showed up, professional software was mostly clean, thoughtful, well-tested, and secure.

I do not recognize that industry.

I have seen massive functions nobody wanted to touch. I have seen business-critical jobs held together by copied snippets and tribal knowledge. I have seen auth checks implemented three different ways in the same codebase. I have seen database migrations treated like vibes. I have seen TODOs old enough to vote.

Human code can be beautiful. It can also be rushed, political, under-specified, copy-pasted, deadline-driven, and full of weird local history.

That does not make human engineers bad. It means software quality has never come from the magical purity of the person typing the code.

Quality comes from the system around the code.

Standards. Tests. Review. Architecture. Security checks. Observability. Clear ownership. The boring stuff that turns a first draft into something you can responsibly run.

AI does not change that. It makes the need more obvious.

The first draft was never the hard part

A lot of programming culture is built around the feeling of producing code by hand. You think through the problem, type the implementation, run it, fix it, polish it, and eventually the thing works.

That loop is satisfying. I still enjoy it.

But the first implementation was never the whole job.

The real work is understanding what should exist, where it belongs, what it is allowed to touch, what could go wrong, how it fails, how it will be tested, how someone else will maintain it, and whether the design still makes sense six months from now.

LLMs are very good at collapsing the typing part of the loop. That feels destabilizing because typing code used to be the visible center of the job.

But it may not have been the highest-value part.

If the first draft gets cheaper, the review and judgment layers matter more. The engineer's role shifts toward specifying intent, constraining architecture, reading critically, building verification loops, and catching the places where the generated answer is plausible but wrong.

That is not a downgrade. It is a different kind of engineering.

Less sculpting every line from scratch. More designing the machine that reliably produces, tests, and improves the lines.

AI code should go through the same gates as human code

The right response to AI-generated code is not blind trust.

It is also not disgust.

The right response is process.

If a team is going to use AI seriously, the generated code should move through the same gates we already claim to care about for human work, and probably a few stronger ones.

Does it match the local style? Does it use the repo's established patterns? Are the inputs validated? Are auth and tenancy boundaries preserved? Are errors handled intentionally? Are dependencies justified? Are tests meaningful? Does the architecture still point in the same direction after the change?

This is not special treatment for AI. It is just software engineering.

We have always needed coding standards. We have always needed security review. We have always needed architecture review. We have always needed someone to ask whether a clever patch is quietly making the system harder to reason about.

The model changes who writes the first version. It does not remove the responsibility to understand the result.

Security is not solved by preferring humans

The security argument is the strongest version of the AI slop critique.

Models can introduce vulnerable patterns. They can miss authorization boundaries. They can suggest stale APIs. They can produce code that looks right while quietly mishandling secrets, user input, file paths, SQL queries, redirects, or object-level permissions.

That is real.

But humans do all of that too.

Security has never been guaranteed by human authorship. It comes from threat modeling, review, static analysis, dependency scanning, testing, least-privilege defaults, incident learning, and a culture where people are allowed to slow down when something feels wrong.

In some parts of this workflow, LLMs are already becoming useful reviewers. They can scan diffs for missing checks. They can compare a change against a written standard. They can ask annoyingly specific questions about edge cases. They can explain why a pattern is risky in plain language.

They are not perfect. I would not outsource final responsibility to a model.

But I also would not assume that a tired human doing a rushed review at 5:40 PM is the gold standard.

The future probably looks like layered review: humans, models, tests, scanners, policies, and runtime signals all checking each other. Not because any one layer is pure, but because serious systems need redundancy.

The identity part is real

I think some of the intensity around AI code comes from something deeper than code quality.

A lot of engineers built part of their identity around being able to make computers do things. I understand that completely.

I have been writing code since I was eight years old. It is one of the few things I have done for most of my life. I like it. I care about it. I think I am pretty good at it.

So yes, it is strange to watch a machine do in seconds what used to take me an afternoon.

But I have mostly made peace with it.

Writing code by hand is starting to look like riding horses to get somewhere or digging trenches with a shovel. Still useful in certain contexts and enjoyable to some people. But no longer the default way serious work gets done at scale.

That does not mean engineering stops mattering.

It means the scarce skill moves.

The scarce skill is not producing syntax. It is knowing what should be built, how to evaluate it, where the risks are, what tradeoffs are acceptable, and when the machine is confidently leading you into a bad decision.

If anything, that makes deep engineering experience more valuable in the near term. The better you understand software, the better you can steer the model. The better you can review its output. The better you can tell the difference between code that merely runs and code that belongs.

The bar should go up

The worst version of AI-assisted development is easy to imagine.

People generate huge piles of code, skim the output, merge it because the demo works, and leave future teams to clean up the mess.

That would be slop.

But again, that is not an AI problem. That is a management problem, a process problem, and a standards problem.

The better version is more interesting: AI makes implementation faster, so teams spend more energy on design, review, security, tests, documentation, and operational quality.

The bar should go up, not down.

If a model can write the first draft in five minutes, there is less excuse for skipping tests. Less excuse for ignoring the threat model. Less excuse for inconsistent style. Less excuse for leaving architecture as an accident.

We should judge AI code the same way we judge human code: by what it does, how well it fits the system, how safely it behaves, and how maintainable it is after the excitement of generation wears off.

Some AI-generated code is bad.

Some human-generated code is bad.

The interesting question is not whether the author was a person or a model.

The interesting question is whether the engineering system around the code is strong enough to turn a draft into software.

That has always been the job.