AI 슬롭 증명

Why does McDonald's taste the same in every country? How have they managed to reliably produce hamburgers all over the world with employees who come and go and imperfect machines? I'll tell you how: they've exactly defined the work that needs to be done to produce those burgers. They detail every aspect of the business, creating a replicable model for everything from keeping the kitchen clean to verifying that every ingredient is fresh1. Sometimes they use automation, like fryers that automatically control the temperature of the oil, and other times they rely on good processes, like double-checking the ingredients of the burger before wrapping it. Enough about burgers. I'm getting hungry already, so let's get back to software. There's been a lot of noise about AI, especially about AI slop. What is AI slop anyway? Overcomplicated code? Unreliable code? If you struggle to define it, you will struggle to deal with it. Before AI started producing bad-quality code, every line of code was perfect and software was reliable from the get-go. I mean, sometimes databases in production got deleted randomly, critical bugs in the most important security libraries went unnoticed for years or a firewall update crashed 8 million devices. But these are just minor exceptions... who are we trying to fool? As humans, we constantly make mistakes. Now AI allows us to generate code faster and thus also make mistakes faster. Coding agents without the full context and without guardrails will indeed produce massive amounts of code that can quickly become unmanageable. This used to be called "spaghetti code" or "big ball of mud" before we could blame AI. AI slop is not just ugly code. It is code that is hard to trust, hard to change, and hard to recover when something breaks. It's not all bad. NASA's Space Shuttle Flight Software ran for 30 years with close to no defects. SQLite, the database of choice in billions of devices, has also been running for decades with a spotless record. And the Linux kernel, even at the massive scale of 30+ million lines of code and thousands of contributors, powers most of the world's servers with impressive stability. All of these projects have achieved McDonald's-like levels of stability and reliability. How do these great projects deal with race conditions, type errors, missing bounds checks, or architectural blind spots? With rigorous testing, peer review, and monitoring, but most importantly, by setting a culture that treats correctness as the default and speed as a constraint, not the ultimate goal. If you are a solo builder or part of a small team, you do not need enterprise process to get there. But you do need guardrails. The goal is not perfect code. The goal is to ship useful software that is reliable and easy to change a few weeks down the road. My default is to enforce these guardrails with a pre-commit hook or, if you are working with a team, a CI run that blocks PRs from being merged if they don't pass. My default is that good code is simple and direct; that usually makes it easier to read, review, maintain, and change. This matters not only for humans but also for AI. If your codebase is split into reasonably sized files, logic is kept in the right place, and naming is consistent, the agent gets better context, makes fewer wrong assumptions, and has a much better chance of editing the right thing without creating new messes somewhere else. Readable code is also better context for AI. Let's try to put processes in place to achieve that goal. Let's start with the most basic stuff. A consistent format makes code easier to read. Every language nowadays has its formatter. In JavaScript, you can rely on Prettier: prettier --check . . It isn't important whether you prefer double quotes or single quotes. We just need to be consistent, so I would usually stick to the defaults. Every programming language has its good and bad parts. For example, JavaScript silently coerces types when comparing values: 0 == "0" is true , but 0 == "" is also true , while "0" == "" is false . We can avoid that by using the strict equality check === . You can also easily silence errors with catch (error) {} or define infinite loops with while (true) . In rare cases, you may need these language features, but my default is to avoid them with a linter, which will catch common issues and help prevent shooting yourself in the foot. There are many linters out there. For example, in a web-based project you could use ESLint and StyleLint: eslint . && stylelint . Typed languages allow you to find mistakes early, like trying to access properties that don't exist or calling functions with missing arguments. Even if you aren't using a typed language, you can use tools to check the implied types. My default is to use some kind of type checking unless the project is still in a very early exploratory phase. For example, in JavaScript you can use TypeScript to check the JavaScript code (Sorbet for Ruby, Python type hints, etc.). Types