# Stop treating "lazy" as a bad word in AI coding > Source: > Published: 2026-09-08 16:01:32+00:00 # Stop treating "lazy" as a bad word in AI coding [Claude Code](/en/tags/claude%20code/)and Cursor, and I've realized there is a dangerous divide between offloading toil and offloading actual comprehension. ## The "Good Lazy" is just automation If we are being honest, the entire history of software engineering is a quest for the right kind of laziness. We didn't write assembly by hand for decades because someone decided that was a waste of human energy; that's why we have compilers. Using an LLM to generate a boilerplate Dockerfile or a repetitive test scaffold isn't "lazy" in a negative sense—it's just moving the effort to a more efficient layer. For example, if I need a basic Express middleware to handle JWT validation, I know exactly how it works. I could write it from scratch in five minutes, but why would I? Let the model dump the 20 lines of code. I'm skipping the typing, not the thinking. If a developer in 2026 is still insisting on typing every single bracket of a config file by hand, they aren't "diligent"—they're just inefficient. ## The "Bad Lazy" creates technical debt The real problem starts when you offload the understanding. This is where the AI workflow becomes a liability. You prompt the model, it spits out a complex regex or a tricky asynchronous loop, the tests pass, and the PR gets merged. Everything looks green. But now you have a piece of code in production that nobody on the team actually understands. The risk isn't apparent during the deployment; it manifests at 2 AM when that specific function crashes and the engineer on call is staring at a block of code they can't vouch for. The difference is invisible to your CI/CD pipeline. Take a regex that validates an email address: - **Scenario A:** I know exactly how that regex works, but I let the AI write it to save 30 seconds. (Good lazy) - **Scenario B:** I have no idea how that regex works, but it passed the test cases, so I merged it. (Bad lazy) On the screen, the code is identical. In the head, one is a tool and the other is a black box. ## Moving from copy-paste to "vibe coding" Some might argue this is just the old Stack Overflow problem, but it's actually worse. With Stack Overflow, there was friction. You had to search, read a thread of strangers arguing, and manually adapt the snippet to your context. That friction forced a level of engagement. With an inline suggestion, the code appears already indented and perfectly formatted. It doesn't ask to be understood; it just asks to be accepted. To avoid this trap, I've started applying a mental stress test to my AI-generated commits. I ask myself: "If this file vanished right now, could I rebuild the logic from scratch?" I don't mean remembering the exact syntax, but understanding the *why* behind the implementation. If the answer is no, then it doesn't matter how fast the feature shipped; I've just traded a short-term productivity gain for a long-term maintenance nightmare. This is the only way to maintain a real-world AI workflow without losing the ability to actually engineer. [Next Stop treating LLM engagement as a metric since most of it is →](/en/threads/8988/)