Claude Codeand Cursor, and I've realized there is a dangerous divide between off toil and off 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 →