Haven't you ever wondered if this AI vibe coding has made us lazy? Who's been solving problems on LeetCode lately? š
I've noticed that accepting is easier than thinking, by a margin so small that no single accept feels like anything, and it adds up anyway. Part of why it's hard to notice is that it feels faster even when it isn't.
But I've come to think "lazy" is the right worry aimed at the wrong thing. There are two kinds of lazy and only one of them is a problem.
I'm going to go into a little background here, because I didn't come up with this, and I didn't reach this conclusion on my own.
Lazy is why we have compilers
Larry Wall, who created Perl, put laziness first on his list of the three great virtues of a programmer, and his definition is the whole argument: "the quality that makes you go to great effort to reduce overall energy expenditure." Great effort. Good lazy isn't the absence of work, it's work moved somewhere better, and it's more or less why compilers exist (somebody got tired of writing the same assembly by hand and decided, reasonably, that the machine could do that part) and why every abstraction we lean on all day is really someone's laziness done properly.
Handing that kind of toil to a model is nothing new. The config I've written a hundred times and the regex I could write but would rather not and the Dockerfile I could recite and the test scaffolding that comes out identical in every project I've ever started: I understand all of it and I'm simply declining to type it again and I feel no guilt about that whatsoever (honestly I'd be more worried about a developer who insisted on typing all of it out by hand in 2026, on principle, one character at a time, while the rest of the team went home). That's not skipping the thinking. That's skipping the typing after the thinking was already done.
The other kind skips the understanding
The second kind of lazy offloads the understanding itself. The model writes the thing and it runs and the tests are green and the PR gets merged and somewhere in that chain there's now a piece of code nobody on the team could explain or fix, and that's the kind that costs, not today but on the day it breaks and somebody on call opens the file at 2am and finds a function nobody can vouch for.
The smallest illustration I can think of, made up on purpose: say the model writes a regex that validates email addresses at sign-up. If I could have written it and chose not to, that's the first kind of lazy, and if I couldn't have and it's now the thing deciding who gets an account, that's the second kind, and it's the same regex on the same line of the same diff either way. The reviewer can't tell the difference and neither can CI. The only place the two kinds differ is inside my head.
Okay, but isn't this just the old Stack Overflow copy-paste problem with a faster clipboard? Mostly yes. And I think that's what makes it worse. Stack Overflow made me go find the answer and read a thread of strangers arguing about it (sometimes with the accepted answer being wrong and the better one three comments down with a tenth of the votes) and then adapt it to my code. The friction was doing quiet work. The suggestion just appears in my file already indented and nothing about it asks to be understood.
Could you rebuild it if it vanished?
I don't have a rulebook for this and I'm suspicious of anyone who does. What I have is one question. Take the last thing the model wrote for you and imagine the file is gone. I don't mean the exact characters, nobody remembers those. Could you sit down and produce something that does the job, and would you know why it works?
If yes, that was the good kind of lazy and it's worth keeping. If no, it doesn't matter how fast it shipped.
That's the honest answer to the title, at least for me. It depends on the week. Some weeks every accept is toil I understand. Other weeks I'm not sure, which is a polite way of saying no. The drift never announces itself. It just gets a little easier to press tab each time.
So I'm asking. I want the real answer, not the one that sounds good. What was the last thing AI wrote for you, and could you rebuild it tomorrow? š
Thanks for reading! English isn't my first language, so I use AI to polish the grammar. Everything else here - the ideas, the opinions - is mine.
Enjoyed this one? Let's stay in touch ā I'm on LinkedIn, always happy to chat, swap ideas, or just say hi. š
Top comments (23)
Not lazy, but my raw coding skills have definitely begun fading. I have new skills in managing my agents etc and in many ways I have a broader systematic understanding than I used to (because some blind spots of my technical skills are easier to learn in the age of AI).
Same here, and I suspect that's most of us now, whether we admit it or not.
"Begun fading" is the part I'd want a number for. Nobody has one, including me. We can measure agent throughput to three decimal places and the thing that's actually changing is currently unmeasured.
I was always lazy; that's why I'm a programmer š . But to be honest, AI made me LESS lazy, because now it's much easier to turn ideas into working code. So it totally varies!
š š š so, AI has helped you overcome your laziness... You definitely need to ask for a raise. š My laziness only goes away when my weekly AI tokens run out in the middle of the week and I have to save up for extra tokens. š
Honestly, it hasnt made me lazy. Do I write less? Definitely. Do I output more? Undoubtably. Did I scale horizontally, handling more projects at once than I used to? Yes. And that's why what sounds like lazy, is actually a redistribution of labor. I spend my time orchestrating between 16 separate agents, on 4 separate systems, on 8 separate projects. Can I write every single one of them by hand? Sure, but it'd take me a year. So the better question is, if AI built it today, would you ever need to build it by hand? So how about this, "Can you rebuild it with AI, exactly the same again?" - Short answer, unless it's HelloWorld, answer is no, you cant. That's the scary bit... We could rewrite it, but we'd never rewrite it the same, take 100 instances, recreate the exact same codebase, all 100 would output different variations of the same thing and only 1 is optimal.
Thanks for the detailed answer and I think we agree more than it looks. The redistribution of labor you describe is what I called the good kind of lazy, and I have no problem with it at all. The part I keep thinking about is your last point: if 100 runs give you 100 different codebases and only one is optimal, how do you know which one landed in your repo? That's really all my gut-check is about, not whether you'd ever retype it by hand, but whether you'd know why the version you got works when one of those 8 projects breaks at 2am. With 16 agents in flight, I'd genuinely like to hear how you keep that in your head.
Honestly, by being granular.
So 16 agents in flight, each has a defined purpose. So when you switch between them, it's like switching frontend to backend, it's a mind shift from Eg. LLM harness development, to universal MCP server, to IDE, to remote desktop, etc. As long as the tasks they run are granular, you just have a small scope to pay attention to.
As for how you'd know what version you got, it's a bit more difficult when dealing with GC languages, python, I wouldnt know how to determine properly, but Rust, you have a few key metrics: What's the theoretical max, are you within 90% of it? While running, does memory usage stay stable (zero-alloc)? Are your benchmarks granular (per-step) and is there any outlier taking more more than it should? With those few questions, you can determine if the setup is optimal, beyond that it's testability and test coverage. If you cover those 2, then you know your system is within margin of error of as fast as it can get, it's fully tested and benchmarked. If values seem... Off... You know there's a bug, usually work being skipped, eg. you get measurements that are in nanoseconds, when the amount of work being done is meant to be more, or running 2 separate sets of data through it, the value stays stable (it's not using the data).
Other than that, it's just keeping track of what's scoped and what isnt
Hi Nazar š I like the distinction between skipping the typing and skipping the understanding. Your rebuild question made me think about the next change, too.
Say AI writes a retry loop. I may not remember the exact syntax, but I'd like to know which failures are retryable, whether the operation is safe to repeat, and what happens when retries run out. A payment API can be surprisingly unenthusiastic about our persistence.
I suppose that's the part I'd want to keep, even if the loop itself has long since left my head.
Nice article, I loved these virtues š
Thanks š
For me, AI hasn't made me a lazier developer. I definitely write less code now, but I spend more time exploring ideas and different ways to approach a problem.
I use AI to bounce ideas around, but I still make the call. That's not something I want to outsource.
I totally get what you described as the first type of laziness. Itās exactly what Iāve been doing throughout my career. I love finding ways to cut tedious manual work. If something can be deployed automatically, donāt do it by hand. If tests can run automatically, skip manual testing. I messed around with Python and all kinds of frameworks, and actually built several usable testing tools and platforms integrated into our company workflow. Then came endless new feature requests from teammates, plus ongoing maintenance and upgrades. It felt like I was trying to take shortcuts, yet somehow I ended up even busier, hahaha.š¤£
Now in the AI era, thereās even more room to offload work. Iāve caught myself multiple times wishing AI could handle even clicking "Next" when I doubleāclick an EXE installer. Thatās definitely a dangerous mindsetš±. Still, as a QA, I always look at AI outputs with skepticism. I never feel confident until I verify everything myself.
This distinction between reducing toil and outsourcing understanding is spot on. š
I think the real engineering risk with AI isnāt writing less codeāitās losing debuggability and system ownership. If AI generates a component, the important question isnāt ācould I type this from scratch?ā but ācan I reason about its failure modes when production breaks at 2 AM?ā š„
AI should reduce keystrokes, not reduce technical judgment. The best workflow Iāve found is: delegate implementation, retain verification, architecture, and ownership.
The ālazy aimed at the wrong thingā split is useful ā accepting a patch that looks done is a different habit than refusing to invent a compiler.
What I watch for now is whether I can still name the failure mode before I hit accept. If I canāt say what would prove the suggestion wrong in under ten seconds, Iām not being lazy in the good sense ā Iām outsourcing the judgment call.
Curious where you draw the line between āskip the boilerplateā and āskip the proof.ā For me itās usually: generate freely, but the test or the invariant still has to come from a human sentence I wrote first.
If anything, AI made me busier than ever! š¤£
Some comments may only be visible to logged-in visitors. Sign in to view all comments.