There's a common take floating around that software built with the help of an LLM is slop by default. And honestly, I'm not here to argue with that. Most of the time, it's true. The majority of AI-assisted code out there is rushed, misunderstood, and brittle. But here's what I want to push back on: that outcome isn't inevitable. It's a choice. It's the result of how you work, not the tools you use.

The difference between slop and something you're actually proud of comes down to one thing: discipline.

Read First. Build Second.

Before you touch a single prompt, you need to understand the codebase you're working in. Not a surface-level skim, but a real, thorough read. What patterns are already established? What conventions does this project follow? What are the existing dependencies, the data flow, the edge cases that have already been handled?

The most dangerous move you can make is asking an LLM to solve a problem you don't fully understand yet. You'll get code that looks right, compiles, maybe even passes a quick smoke test, and it'll be completely wrong for your situation. The model doesn't know your codebase. You do. Or you should. If you don't, that's step one.

Plan exhaustively. Ask clarifying questions of yourself before you ever open a chat window. The time you spend understanding the problem space is not wasted time. It's the foundation everything else gets built on.

TDD Is Non-Negotiable

If you're pairing with an LLM and you're not writing tests, you're flying blind. Test-driven development is a living technical document of how your application actually works, not just a safety net for future refactors. It captures intent. It captures behavior. It gives you something concrete to reason against when the generated code doesn't do what you thought it would.

Write the test first. Watch it fail. Then let the model help you make it pass. That process forces you to articulate what you actually need, and it gives you immediate, objective feedback on whether what you got is right.

Small, focused tests. Clear assertions. Coverage that grows incrementally as the feature does. This is how you stay sane when you're moving fast, and it's how you build something you can hand off without a six-hour knowledge transfer.

Slow Down. Seriously.

There's this idea that AI means ludicrous speed. That everything happens in an instant and you can ship in hours what used to take weeks. And sure, in some contexts that's real. But it comes with a cost that most people aren't accounting for.

Speed and slop have a very strong correlation. The faster you move, the less you understand what's actually happening. The less you understand, the more fragile the thing you're building becomes. Technical debt accrues silently, and then one day it all comes due at once.

Work in smaller batches. Solve one thing at a time. Resist the urge to boil the ocean. A well-understood, well-tested, well-reviewed piece of work that took twice as long is worth ten times more than a sprawling feature that kind of works until it doesn't.

Slowing down isn't a weakness. It's the discipline that separates good engineers from people who ship broken things quickly.

You Are Still the Developer

This is the one that matters most. The generated code is not your code until you understand it. Every line. Every function. Every decision that was made in that output.

If something is unclear, ask again. Ask twelve times if you have to. Dig in. Read the docs. Trace the logic. Don't let anything ship through your hands that you can't explain out loud to another engineer. That's not the bar for AI-assisted work, that's the bar for all work.

You are the architect. You are the reviewer. You are the last line of defense between generated code and production. That responsibility doesn't transfer to the model. It never does.

Once you understand the code, look for the smells. The places where something technically works but isn't right. Tight coupling. Vague naming. Logic that's too clever. Refactor it. Push the platform forward. That's your job. That will always be your job.

Your Reputation Is on the Line

At the end of the day, the software you ship says something about you. It's an expression of your values, your craft, your standards. Shipping AI slop, code you don't understand, code you didn't bother to review, erodes the trust of the people around you. The teammates who look to you for technical leadership. The users who depend on the stability of what you build. The people who gave you their trust.

That trust is hard to build and easy to lose. Trust is gained in drops and lost in buckets, as they say.

The tools are good. They're genuinely powerful and they change what's possible. But they don't change what it means to do this work well. Discipline, understanding, patience, craft. Those things still matter. They matter more now, not less, because it's so much easier to skip them.

Don't skip them. Please don't skip them.