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 i...
For further actions, you may consider blocking this person and/or reporting abuse
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 😃
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.
It made my multi-tasking easier - while I understand something, behind the scenes AI types code for me or pulls answers for my questions etc., so it did help me to get more done.
I just want to be clear, multi-tasking here doesn't mean I spin 10 sessions - the most I can comprehend/context-switch without burn are 3, so I let 3 things run. Didn't loose touch with code, because - I review what it is doing, how it is doing and why it is doing before accept.
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.
If anything, AI made me busier than ever! 🤣
ANy doubt
nah, it is opposite
I think yes, I was good at debugging but now AI does for me :) Btw, check my product zyvop.com and share your valuable thoughts