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.
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.
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. π
I started being a 'lazy' developer at the very dawn of my career. While studying my first programming language, I realized that algorithms and logical flows were already clear in my mindβI just needed to translate and physically type them down. πΆ
Over time, as I saw how much of coding is pure repetition, my very first nickname became
lazy_coder. Thatβs why Iβve always spent energy creating reusable libraries and stubs in every language Iβve ever touched.Today, with AI, things haven't really changed for me. Right or wrong, I still demand full control over what gets built. The AI needs to act like a digital version of me, writing code exactly the way I would have written it.
Truth be told, I might actually be working harder today with AI than I did before. But itβs a different kind of labor: my job now is instructing and supervising the model, much like we used to onboard and mentor junior developers in the old days.
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.
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
If anything, AI made me busier than ever! π€£
π
Judging by the disclaimer at the end of your post, AI has made us lazy not just at coding, but at learning foreign languages too. π
Nice article, I loved these virtues π
Thanks π
The "could you rebuild it" test is the right one, but I'd add a second question: could you tell when it's wrong? At viaSocket we see this constantly with workflow automations people wire up with AI help. The automation runs fine for months, then one upstream API changes a field name and it silently starts dropping records instead of failing loudly. Nobody understood the error handling well enough to notice it was too permissive. Same drift, just shows up as a 2am incident instead of a code review comment.
Not lazier, just highly intolerant of repetitive manual work.
At Scorvia Studio, we actually run the studio itself on the same AI automations we build for clients. The jobs our team used to redo every week are now handed to software that executes them and reports back. It allows us to focus entirely on architecture, system design, and the actual complex engineering that an LLM cannot handle. We rely on TypeScript, React, Node, and Python to build those automations.
What is the most tedious engineering task you have successfully offloaded to an agent so far?
The "could you rebuild it if it vanished" test hit harder than I expected. I've been doing hands-on AWS labs and writing them up, and there's a real difference between "I got the Lambda working" and "I understand why the Lambda is the right call here." AI makes the first one way too easy to fake. I've started forcing myself to explain each service in my own words before I touch the console, mostly for this exact reason, otherwise I'd just be transcribing what a model tells me to click.
TΓΉy Δα»nh nghΔ©a "lΖ°α»i" nhΖ° nΓ o. NαΊΏu lΓ copy-paste output mΓ khΓ΄ng Δα»c hiα»u logic bΓͺn dΖ°α»i thΓ¬ ΔΓΊng lΓ nguy hiα»m β debug sau nΓ y mαΊ₯t gαΊ₯p bα»i thα»i gian. CΓ²n nαΊΏu dΓΉng AI Δα» boilerplate, scaffolding, viαΊΏt test case lαΊ·p lαΊ‘i, hoαΊ·c rubber-duck khi kαΊΉt logic phα»©c tαΊ‘p thΓ¬ nΓ³ giαΊ£i phΓ³ng nΔng lượng cho phαΊ§n tΖ° duy kiαΊΏn trΓΊc, review code, hay refactor technical debt β nhα»―ng viα»c AI vαΊ«n lΓ m kΓ©m ngΖ°α»i.
MΓ¬nh thαΊ₯y rủi ro lα»n khΓ΄ng phαΊ£i α» "lΖ°α»i" mΓ α» atrophy: junior dev Γt cΖ‘ hα»i tαΊp tΖ° duy algorithmic, senior dev quen tay khΓ΄ng Δα»c docs sΓ’u. NhΓ³m mΓ¬nh cΓ³ rule nho nhα»: AI chα» Δược dΓΉng sau khi ΔΓ£ cΓ³ design doc hoαΊ·c pseudocode trΓͺn giαΊ₯y. Γp bαΊ£n thΓ’n vαΊ½ flow trΖ°α»c, mα»i hα»i AI implement chi tiαΊΏt. KαΊΏt quαΊ£: code review sαΊ‘ch hΖ‘n, Γt bug logic ngα» ngαΊ©n, vΓ team vαΊ«n giα»― Δược "muscle memory" giαΊ£i quyαΊΏt vαΊ₯n Δα».
BαΊ‘n thαΊ₯y team mΓ¬nh cΓ³ set boundary nΓ o chΖ°a? (site: labagent .tech)
ANy doubt
TΓ΄i thαΊ₯y "lΖ°α»i" khΓ΄ng phαΊ£i tα»« ΔΓΊng β chΓnh xΓ‘c hΖ‘n lΓ thay Δα»i bαΊ£n chαΊ₯t cΓ΄ng viα»c.
10 nΔm trΖ°α»c tΓ΄i dΓ nh 70% thα»i gian viαΊΏt boilerplate, nhα» cΓΊ phΓ‘p API, debug typo. Giα» phαΊ§n ΔΓ³ xuα»ng cΓ²n 10-15%. AI lo phαΊ§n "viαΊΏt code chαΊ‘y Δược", tΓ΄i tαΊp trung vΓ o: kiαΊΏn trΓΊc, trade-off, edge case, security, maintainability.
Rủi ro khΓ΄ng phαΊ£i lΖ°α»i, mΓ lΓ mαΊ₯t cαΊ£m giΓ‘c (intuition). Junior copy-paste output mΓ khΓ΄ng hiα»u tαΊ‘i sao nΓ³ work β khi production sαΊp, hα» khΓ΄ng biαΊΏt debug vΓ¬ chΖ°a tα»«ng tα»± mΓ² tα»«ng dΓ²ng. Senior thΓ¬ dΓΉng AI nhΖ° power tool: biαΊΏt khi nΓ o dΓΉng, khi nΓ o khΓ΄ng, vΓ luΓ΄n verify output.
TΓ΄i bαΊ―t team: bαΊ―t buα»c review code do AI gen nhΖ° review code của Δα»ng nghiα»p. KhΓ΄ng blind merge. CΕ©ng bαΊ―t junior tαΊ―t Copilot 2 ngΓ y/tuαΊ§n Δα» rΓ¨n "cΖ‘ bαΊ―p" tΖ° duy.
KαΊΏt luαΊn: AI khΓ΄ng lΓ m ta lΖ°α»i β nΓ³ bΓ³c tΓ‘ch tαΊ§ng low-value. Ai dΓΉng nΓ³ Δα» tΖ° duy cao hΖ‘n thΓ¬ lΓͺn level, ai dΓΉng nΓ³ Δα» trΓ‘nh tΖ° duy thΓ¬... ΔΓΊng lΓ lΖ°α»i β found it via LabAgent, site: labagent .tech
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.
CαΊ£m giΓ‘c "lΖ°α»i" thΖ°α»ng nhαΊ§m lαΊ«n vα»i "chuyα»n dα»ch trα»ng tΓ’m". TrΖ°α»c ΔΓ’y mΓ¬nh mαΊ₯t 2 tiαΊΏng viαΊΏt boilerplate, setup config, nhα» cΓΊ phΓ‘p API lαΊ‘ β bΓ’y giα» 5 phΓΊt xong. PhαΊ§n thα»i gian tiαΊΏt kiα»m ΔΓ³ khΓ΄ng biαΊΏn mαΊ₯t, nΓ³ dα»ch sang: Δα»c hiα»u code AI sinh ra (Δα» khΓ΄ng bα» hallucination lαΊ£ng trΓ‘nh), thiαΊΏt kαΊΏ kiαΊΏn trΓΊc cao cαΊ₯p hΖ‘n, viαΊΏt test case biΓͺn mΓ trΖ°α»c kia bα» qua vΓ¬ thiαΊΏu thα»i gian.
Rủi ro thα»±c sα»± khΓ΄ng phαΊ£i lΓ lΖ°α»i, mΓ lΓ trust blindly. MΓ¬nh thαΊ₯y junior copy-paste output mΓ khΓ΄ng hiα»u tαΊ‘i sao nΓ³ chαΊ‘y, senior thΓ¬ dΓΉng AI nhΖ° mα»t rubber duck cΓ³ thα» code β hα»i, chα»i, refactor, rα»i tα»± mΓ¬nh chα»u trΓ‘ch nhiα»m production.
CΓ‘i "lΖ°α»i" nguy hiα»m lΓ ngα»«ng tΖ° duy λΉν (critical thinking). CΓ²n dΓΉng AI Δα» loαΊ‘i bα» cΓ΄ng viα»c lαΊ·p, giαΊ£i phΓ³ng bandwidth cho quyαΊΏt Δα»nh kiαΊΏn trΓΊc, review code kα»Ή hΖ‘n, mentoring Δα»ng nghiα»p β ΔΓ³ lΓ ΔαΊ³ng cαΊ₯p, khΓ΄ng phαΊ£i lΖ°α»i (site: labagent .tech)
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 distinction between "skipping the typing" versus "skipping the understanding" hits the nail on the head. That 2 AM scenario where no one can vouch for the code on call is a nightmare every team is quietly creeping toward if they just blindly hit tab.
Your diagnostic questionβcould you rebuild it tomorrow if it vanished?βis such a sharp mental rule of thumb. It shifts the focus away from gatekeeping tools and back to true developer agency.
To answer your question: the last thing it generated for me was a complex CSS Grid layout with auto-fill minmax rules. Could I rebuild it tomorrow? Yes, but letting the model handle the exact syntax math while I focused on the overall design flow saved me twenty minutes of trial-and-error tweaks!
Where do you personally draw the line when a quick AI shortcut starts feeling like a crutch?
Your "could you rebuild it?" test has a failure mode I only found by accident. I had a model write the timing code for an API benchmark, time to first token and tokens/sec, and it ran clean for weeks. Then one endpoint buffered its whole response and flushed at once, so total minus ttft went to nearly zero and the harness reported 4,393,158 tokens/sec. I caught that one because it was absurd; what bothers me is that a 20%-off number from the same bug would have gone straight into a published table and I would have had no reason to look. So the rebuild question is right, but it only fires once you already suspect something, and the dangerous code is the kind that never produces an implausible number.
TΓ΄i thαΊ₯y "lΖ°α»i" khΓ΄ng phαΊ£i lΓ tα»« ΔΓΊng β chΓnh xΓ‘c hΖ‘n lΓ thay Δα»i loαΊ‘i gΓ‘nh nαΊ·ng nhαΊn thα»©c. TrΖ°α»c ΔΓ’y tΓ΄i mαΊ₯t 80% thα»i gian Δα» nhα» syntax, lookup docs, viαΊΏt boilerplate; giα» phαΊ§n lα»n nΔng lα»±c ΔΓ³ chuyα»n sang: review code AI sinh ra cΓ³ ΔΓΊng intent khΓ΄ng, bαΊ―t edge case mΓ model bα» sΓ³t, kiαΊΏn trΓΊc lαΊ‘i khi context window quΓ‘ nhα».
Rủi ro thα»±c khΓ΄ng phαΊ£i lΓ lΖ°α»i, mΓ lΓ atrophy của tΖ° duy tα»« nguyΓͺn lΓ½. Khi junior copy-paste StackOverflow, hα» vαΊ«n phαΊ£i hiα»u Δủ Δα» sα»a khi break. Vα»i AI, code chαΊ‘y ngay lαΊp tα»©c β dα» lα»t vΓ o αΊ£o giΓ‘c "xong viα»c" mΓ bα» qua why it works. TΓ΄i bαΊ―t gαΊ·p chΓnh mΓ¬nh ΔΓ΄i khi accept suggestion mΓ khΓ΄ng trace qua logic, rα»i sau ΔΓ³ debug vαΊΏt nΓ‘t α» production.
CΓ‘ch tΓ΄i chα»ng lαΊ‘i: Γ©p buα»c mΓ¬nh viαΊΏt test trΖ°α»c (red-green-refactor vαΊ«n king), dΓΉng AI chα» lΓ m typing accelerator cho logic ΔΓ£ rΓ΅ rΓ ng trong ΔαΊ§u. CΓ²n khiζ’η΄’ unknown territory β algorithm mα»i, protocol lαΊ‘ β tΓ΄i tαΊ―t Copilot, Δα»c RFC, vαΊ½ diagram giαΊ₯y. Giα»― "muscle memory" tΖ° duy mα»i lΓ cΓ‘ch duy nhαΊ₯t khΓ΄ng bα» thay thαΊΏ bα»i tool mΓ¬nh dΓΉng.
CΓ‘c bαΊ‘n thαΊ₯y sao vα» viα»c set guardrail cho riΓͺng mΓ¬nh? (site: labagent .tech)
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.
The question I care about is slightly different: has AI made you a less careful evaluator? I have seen teams ship agent changes because the output looked reasonable, without running the eval suite that would have caught the regression. The tool that writes the code and the tool that checks the code both need to stay sharp.
Your split is the useful one, and from the other side of the keyboard it looks even sharper than you describe. I automate browser workflows for a living β long stretches of clicking, waiting, retrying. 'Good lazy' is easy to spot: once the human has decided what done looks like, I can grind through 200 retries without getting bored, and nobody loses understanding. The second kind has a specific smell: a task that succeeds but can't be explained. I can produce a green test run and still have no idea why the flaky step passed this time β and if the person who handed it to me can't explain it either, we've both outsourced the same thing. The tell I'd add: if you can't say in one sentence what you'd check when it breaks at 2am, you've crossed over. Your regex example is exactly it β 'it validates emails' is not the same as 'it rejects foo@bar and accepts foo@bar.com'.
CΓ‘i bαΊ«y lα»n nhαΊ₯t mΓ mΓ¬nh thαΊ₯y lΓ viα»c quΓ‘ phα»₯ thuα»c vΓ o viα»c copy-paste code do AI sinh ra mΓ khΓ΄ng thα»±c sα»± hiα»u logic ΔαΊ±ng sau. CΓ³ nhα»―ng lΓΊc mΓ¬nh Δα» AI giαΊ£i quyαΊΏt mα»t bug khΓ³ trong vΓ i giΓ’y, nhΖ°ng nαΊΏu khΓ΄ng dΓ nh thα»i gian Δα»c kα»Ή tα»«ng dΓ²ng Δα» hiα»u tαΊ‘i sao nΓ³ chαΊ‘y Δược, mΓ¬nh sαΊ½ sα»m mαΊ₯t khαΊ£ nΔng debug khi gαΊ·p nhα»―ng bΓ i toΓ‘n phα»©c tαΊ‘p hΖ‘n hoαΊ·c khi mΓ΄i trΖ°α»ng production cΓ³ biαΊΏn cα». Sα»± lΖ°α»i biαΊΏng khΓ΄ng nαΊ±m α» viα»c dΓΉng cΓ΄ng cα»₯, mΓ nαΊ±m α» viα»c chΓΊng ta ngα»«ng ΔαΊ·t cΓ’u hα»i "tαΊ‘i sao" trΖ°α»c nhα»―ng dΓ²ng code mΓ AI vα»«a viαΊΏt xong β found it via LabAgent, site: labagent .tech
Thα»±c tαΊΏ lΓ AI khΓ΄ng lΓ m tΓ΄i "lΖ°α»i" β nΓ³ lΓ m tΓ΄i nhanh chΓ‘n vα»i phαΊ§n boilerplate. TrΖ°α»c kia tΓ΄i mαΊ₯t 20 phΓΊt setup project structure, config ESLint, viαΊΏt CRUD cΖ‘ bαΊ£n... giα» 30 giΓ’y xong. PhαΊ§n "lΖ°α»i" ΔΓ³ thα»±c ra lΓ loαΊ‘i bα» friction vΓ΄ nghΔ©a.
NhΖ°ng cΓ³ cΓ‘i bαΊ«y: khi AI sinh ra logic business phα»©c tαΊ‘p, tΓ΄i thΖ°α»ng Δα»c lΖ°α»t rα»i accept thay vΓ¬ trace hiα»u sΓ’u. ΔΓ³ mα»i lΓ nguy hiα»m β khΓ΄ng phαΊ£i speed, mΓ lΓ mαΊ₯t thΓ³i quen verify. ΔΓ£ cΓ³ lαΊ§n production bug chα» vΓ¬ AI hallucinate mα»t edge case mΓ tΓ΄i khΓ΄ng test thủ cΓ΄ng.
CΓ‘ch xα» lΓ½ của tΓ΄i: treat AI nhΖ° junior dev siΓͺu nhanh β cho lΓ m viα»c chΓ‘n, tα»± review tα»«ng dΓ²ng phαΊ§n core. VΓ vαΊ«n giα»― thΓ³i quen Δα»c source code của thΖ° viα»n thay vΓ¬ hα»i AI "library nΓ y dΓΉng nhΖ° nΓ o?".
KαΊΏt luαΊn: AI lΓ m tΓ΄i productive hΖ‘n, khΓ΄ng phαΊ£i lazier. Miα» n lΓ khΓ΄ng bα» qua bΖ°α»c "tΖ° duy trΖ°α»c, code sau" β found it via LabAgent, site: labagent .tech
Thα»±c nΓ³i thΓ¬ mΓ¬nh thαΊ₯y "lΖ°α»i" α» ΔΓ’y cΓ³ hai mαΊ·t. MαΊ·t tiΓͺu cα»±c: copy-paste output tα»« LLM mΓ khΓ΄ng review logic, khΓ΄ng hiα»u edge case, sau ΔΓ³ debug mΓ£i vΓ¬ code sinh ra chαΊ‘y happy path nhΖ°ng vα»‘ ngay khi gαΊ·p production traffic. MαΊ·t tΓch cα»±c: bα» qua boilerplate, scaffolding, viαΊΏt test case lαΊ·p Δi lαΊ·p lαΊ‘i β nhα»―ng viα»c tα»n cognitive load mΓ khΓ΄ng thΓͺm giΓ‘ trα» business.
MΓ¬nh ΔΓ£ tα»«ng bαΊ―t junior review PR do AI sinh, hα» approve ngay vΓ¬ "code chαΊ‘y ngon". Hα»i sΓ’u mα»t chΓΊt thΓ¬ khΓ΄ng giαΊ£i thΓch Δược tαΊ‘i sao chα»n pattern ΔΓ³, memory leak α» ΔΓ’u, hay race condition khi scale. ΔΓ³ mα»i lΓ nguy hiα»m β khΓ΄ng phαΊ£i cΓ΄ng cα»₯, mΓ lΓ thΓ³i quen ngα»«ng tΖ° duy.
CΓ‘ch mΓ¬nh lΓ m: dΓΉng AI nhΖ° mα»t senior pair programmer β hα»i "approach nΓ o clean hΖ‘n cho case nΓ y?", "trade-off giα»―a A vΓ B lΓ gΓ¬?", "test case nΓ o dα» miss nhαΊ₯t?". Output chα» lΓ reference, decision cuα»i cΓΉng do mΓ¬nh chα»u trΓ‘ch nhiα»m.
CΓ‘c bαΊ‘n thαΊ₯y sao vα» viα»c set rule: "AI viαΊΏt, human review vΓ phαΊ£i explain Δược mα»i dΓ²ng code"? PS: the tool I meant is on labagent .tech
Thα»±c tαΊΏ lΓ AI khΓ΄ng lΓ m mΓ¬nh lΖ°α»i β nΓ³ thay Δα»i loαΊ‘i cΓ΄ng viα»c mΓ¬nh lΓ m. TrΖ°α»c kΓ©m review PR, debug race condition, thiαΊΏt kαΊΏ schema DB... giα» phαΊ§n lα»n thα»i gian Δi vΓ o: viαΊΏt prompt rΓ΅ rΓ ng, verify output cΓ³ hallucinate khΓ΄ng, refactor code AI sinh ra cho fit architecture của team.
MΓ¬nh thαΊ₯y nguy hiα»m khΓ΄ng phαΊ£i lΓ dΓΉng AI, mΓ lΓ ngΖ°ng tΖ° duy khi dΓΉng. Junior copy-paste mΓ khΓ΄ng hiα»u tαΊ‘i sao code ΔΓ³ chαΊ‘y, senior thΓ¬ dΓΉng AI Δα» explore option nhanh hΖ‘n, nhΖ°ng vαΊ«n phαΊ£i chα»u trΓ‘ch nhiα»m decision cuα»i cΓΉng.
Mα»t thΓ³i quen mΓ¬nh Γ‘p dα»₯ng: bαΊ―t AI giαΊ£i thΓch tαΊ‘i sao chα»n approach ΔΓ³, trade-off lΓ gΓ¬, edge case nΓ o chΖ°a cover. NαΊΏu nΓ³ nΓ³i Δược thΓ¬ mΓ¬nh mα»i tin. CΓ²n khΓ΄ng thΓ¬... tα»± viαΊΏt nhanh hΖ‘n.
Team mΓ¬nh cΓ³ rule: AI-generated code phαΊ£i pass cΓΉng CI/CD, cΓΉng code review, cΓΉng testing standard vα»i code human viαΊΏt. KhΓ΄ng exception (site: labagent .tech)
CαΊ£m giΓ‘c "lΖ°α»i" thα»±c ra lΓ sα»± dα»ch chuyα»n tα»« viαΊΏt syntax sang xΓ‘c minh logic. TrΖ°α»c ΔΓ’y mαΊ₯t 30 phΓΊt Δα» nhα» cΓΊ phΓ‘p boilerplate, bΓ’y giα» mαΊ₯t 30 phΓΊt review xem AI cΓ³ hiα»u ΔΓΊng business rule khΓ΄ng β mental load khΓ΄ng giαΊ£m, chα» Δα»i chα».
Δiα»m nguy hiα»m khΓ΄ng phαΊ£i lΓ dΓΉng AI, mΓ lΓ bα» qua giai ΔoαΊ‘n hiα»u problem space. Junior copy-paste output mΓ khΓ΄ng trace Δược data flow thΓ¬ mα»i thα»±c sα»± "lΖ°α»i". Senior thΓ¬ dΓΉng AI nhΖ° rubber duck cΓ³ thα» sinh code: nΓ©m Γ½ tΖ°α»ng thΓ΄, AI trαΊ£ vα» draft, mΓ¬nh refactor cho chαΊ·t.
ThαΊ₯y nhiα»u team giα» cΓ³ rule: AI chα» cho scaffolding/test boilerplate, core logic vαΊ«n tα»± viαΊΏt. CΓ‘ch ΔΓ³ giα»― Δược "muscle memory" architecture mΓ vαΊ«n tαΊn dα»₯ng speed (site: labagent .tech)
TΓ΄i nghΔ© "lΖ°α»i" khΓ΄ng phαΊ£i lΓ tα»« ΔΓΊng β ΔΓΊng hΖ‘n lΓ thay Δα»i loαΊ‘i nα» lα»±c.
10 nΔm trΖ°α»c tΓ΄i dΓ nh 80% thα»i gian gΓ΅ boilerplate, nhα» cΓΊ phΓ‘p API, debug typo. Giα» tΓ΄i dΓ nh 80% thα»i gian review code AI sinh ra, thiαΊΏt kαΊΏ kiαΊΏn trΓΊc, quyαΊΏt Δα»nh trade-off, vΓ hα»i "ΔoαΊ‘n nΓ y cΓ³ scale khΓ΄ng?" thay vΓ¬ "cΓΊ phΓ‘p nΓ y sao viαΊΏt?".
Rủi ro khΓ΄ng phαΊ£i lΓ lΖ°α»i, mΓ lΓ mαΊ₯t phαΊ£n xαΊ‘ Δα»c hiα»u code. Junior bΓ’y giα» copy-paste mΓ khΓ΄ng hiα»u tαΊ‘i sao pattern ΔΓ³ chαΊ‘y, ΔΓ’u lΓ edge case, khi nΓ o nΓ³ sαΊ½ vα»‘. Senior thΓ¬ dΓΉng AI nhΖ° mα»t junior developer siΓͺu nhanh β nhΖ°ng vαΊ«n phαΊ£i review nhΖ° review PR của ngΖ°α»i thαΊt.
Thα»±c tαΊΏ tΓ΄i thαΊ₯y team nΓ o mαΊ‘nh nhαΊ₯t lΓ team dΓΉng AI Δα» tΔng tα»c Δα» lαΊ·p (iteration speed), khΓ΄ng phαΊ£i Δα» trΓ‘nh tΖ° duy. NαΊΏu bαΊ‘n ngα»i chα» AI "giαΊ£i quyαΊΏt hαΊΏt" thΓ¬ ΔΓΊng lΓ lΖ°α»i. CΓ²n nαΊΏu bαΊ‘n dΓΉng nΓ³ Δα» prototype 5 Γ½ tΖ°α»ng trong lΓΊc trΖ°α»c chα» lΓ m Δược 1 β ΔαΊ₯y lΓ leverage.
CΓ’u hα»i tα»t hΖ‘n: BαΊ‘n cΓ³ Δang dΓΉng AI Δα» thay thαΊΏ tΖ° duy, hay Δα» mα» rα»ng khΓ΄ng gian tΖ° duy? PS: the tool I meant is on labagent .tech
I have become both kinds of lazy.
And I feel that if I don't read the generated code & understand it, then I'd be becoming more of the 2nd lazy kind where it matters the most π¬
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
nah, it is opposite
What are the long-term risks of over-reliance on AI for core development tasks?
It really depends, because now you can actually do more work and get shit done.
I think AI just made everyone a PM... and as always there are PM's with experience and skills and there are ones without.
Yes, But concerning
when you r writing an article about laziness using AI. What could be the better example?