Over the past couple of months, I've read a lot of articles about the consequences of AI dependency and one prominent finding is cognitive atrophy....
For further actions, you may consider blocking this person and/or reporting abuse
Great work Elmar!
I seen a lot of articles that talks about very similar aspects when it comes of using AI. This article in particular made me realized that "I have been using AI as my Step 1 instead of me thinking it first".
I realized that I have used AI immediately without me thinking of a solution first. This goes the same before AI where one relies on StackOverFlow for answers. I realized that relying decay my thought of thinking independently and prevented me from explaining the thing I built. Right now, I am currently trying to think of a solution myself before using AI or other tools to help me solve the problem. That way, I can be the person who is able to explain and help other peers on the project I am confident in.
Great write up and nice use of images lol. Student like Master haha
Thanks @francistrdev! Recently, I've been doing a lot in my power to bring more people to the responsible and disciplined side of using AI. Mostly through commenting on posts. This time, I'm just glad that I got to share my two cents in an article post.
When I notice atrophy it's hard for me to be sure if it's an over-reliance on AI tools or being in my late 30s and not always having the room in my head for all this stuff 🫠
@ben I'm 100% sure it's not about the age 🤣 My grandmother is 90+ years old and still as sharp as ever (though she never programmed, but she was a teacher).
Think first, prompt later. Thanks for this post.
Your welcome @devmount
What caught mine was distrusting any tool's summary of a diff. A CLI proxy I route git through reported two files as identical when they were not, and only re-running /usr/bin/diff showed the change. Reading the real diff is the review step I stopped skipping.
Woah, never encountered this AI error before. Thanks for the heads up!
The review step is necessary, but it can still become ceremonial if the engineer only checks whether the output looks plausible. One useful habit is to predict the failure modes before asking the model, then compare its result against those predictions. That keeps problem framing, test selection, and debugging muscles active while still letting the tool handle mechanical work. The skill worth protecting is not typing syntax; it is forming and revising a model of the system.
Thanks for this in-depth insight. Personally, I haven't thought about predicting the failure modes first. I always think about what I want my feature to look. I'll be sure to add that in my arsenal during development.
W article Elmar!
Avengers fan here!
Thank you for the support!
Make review start with predictions. Write expected behavior and failure cases before reading generated code then test those claims.
Yep, this is a much robust approach too. It has clear intentions, I like it!
Stop using AI for everything. For at least one task everyday you should totally write the code yourself. The only intelligence you're allowed to use for that task comes from between your ears. Even if that task is only 10% of what you're completing per day, you are still manually writing code and preventing loss of programming skills. Don't let your hard-earned coding prowess erode!
Yes, be consistent and don't let your skills rust to oblivion!
Awesome post. To be fair, I’m struggling right now to decide whether spec-driven development is moving us toward the “atrophy of other skills.” For now, I’d say it has let me develop other types of skills. I focus more than ever on theory and good practices. When I want to make sure the output of an AI agent chain is possible to debug, verify, and validate, I find myself learning a whole other set of tools and practices. I’m still solving problems, but the problems are bigger, wider, and more global.
A disclaimer: I’ve been developing software for more than 12 years before the AI era, and now for two years within it. That experience lets me put my attention on specific problems and correct AI decisions when my own instincts tell me something is off. For example, I can ask an agent to build a Java solution with a recent version of Spring Boot, using a simple layered design after reading the specs. If the solution involves multiple sources, I might choose a hexagonal design. Then I go through the files, understand them, correct and clean things here and there, and shape my constitution file. That becomes the first stone of the project.
From there, much of the work becomes mechanical. Agents can pick up that foundation and handle problems that, in many office projects, are repetitive and boring. We’re often not developing something entirely new. My attention shifts to the constitution, then the specs, then the skills and documentation needed to work with the latest frameworks and technologies.
UI/UX is a big exception for me. There, my mindset turns more than ever toward the people who will use the app. AI and tools like Playwright can help automate checks, but they also free up more attention for the features and the experience itself. That feels like a different approach altogether, and I’m still figuring out what it means for our skills.
Interesting points really. Also, those 12+ years of developing software is so inspiring (I hope I can also reach that milestone for my career). But from what I picked up, that experience you mentioned is now what's lacking today. AI, if misused, could easily take away that chance for growth. You are able to "correct" AI because you have that "instinct" honed from years of solo experience without the convenience of AI. This is what I'm trying to obtain for myself. I still use AI but not to the point I become a yes-man to it.
Again, thank you for your points!
Thanks, I’m still learning myself, the tools change fast, and some of our habits change with them, but curiosity and the willingness to question a solution remain valuable
Yep, it is really valuable. People who are still innately curious and still asking and verifying solutions are the GOAT's of future software engineering.
Really thoughtful essay. The critical distinction here is between syntax generation and system mental modeling.
When developers offload mechanical boilerplate, productivity rises. But when developers offload understanding the dependency graph and architectural state, cognitive atrophy happens because the mental model of the system dissolves. If an engineer cannot trace where state lives or how failure modes cascade, they cannot debug when things inevitably break.
For AI developer tooling to be sustainable, it needs to surface and audit decisions explicitly rather than treating codebases as opaque black boxes. Transparency into what context an assistant is using and why decisions were made is the best antidote to blind reliance.
Well said @memorysync_rafay. If they could somehow develop that kind of feature, that would be excellent.
The atrophy angle is usually framed as engineers get worse at coding, but the more concerning version is engineers getting worse at knowing when to distrust the output. Coding skill degrades slowly and visibly, judgment calibration degrades quietly and you don't find out until it's expensive.
Yes, judgment which is one, if not, the most important quality an engineer can have should be protected and improved at the same time. False trust is dangerous and more and more developers are falling into this trap which is expensive to get out of.
Awesome article, and great insights for everyone here!
This is why I built codetrain.ai, to have a standard why to slow down and actually take time to understand all the ai generated / modified code. Its an AI generated tutor tailored towards making sure you learn concepts the right way, by actually writing the code by hand and learning from your failures.
This is a valuable reminder that AI should support our thinking, not replace it. Reviewing generated code, solving problems independently, and understanding our own decisions are essential for long-term growth as developers. Thanks for sharing this perspective. For more programming tutorials and developer resources, visit CodeCan.net.
Word. My company went all in on AI. Its totally compromised any balance there was in the dynamic of the company and any processes, including my own work. Its not a craft anymore, theres no attention to detail, no feeling rewarded or accomplished, no nothing, just pumping stuff out. My skills have completely degraded and I am so checked out of the whole thing. The problem is work and what it gave me was kinda the only thing going on for me, so you can imagine the identity crisis. Im not saying I dont want to use AI, but there needs to be a better way to do this, unfortunately its all about the grand vision of the managers/leaders, and they dont really care about the engineers. Been job hunting a long time, the few interviews I got, I got rejected. AI has thrown off the balance in interviews too, even though companies are being real about AI and try to adapt the process, its clear they dont know what theyre doing yet.
@itiswhatitis, yes I think the keyword is "yet". Generally, I don't personally blame companies. They want to generate income and when they saw their competitors adapting AI and big tech investing heavily in data centers, they would naturally adapt it too.
We are still in the process of how to make working with AI "work". I'll just hope, anyone who's in-charge is still on the human side. If AI truly is the next step (which is highly likely), new jobs should be created. Else, they are just cutting the bottom rung of the career ladder. There will be no senior engineers of tomorrow and I don't particularly like that future for us.
This point about skipping 'Step 1' (thinking through the problem frame yourself before prompting) hits right at the core of developer productivity today. It's so easy to mistake velocity of output for depth of comprehension. When engineers delegate the initial problem framing and edge case discovery to AI, PR reviews become passive stamp-approvals rather than true architectural validation. Using AI for mechanical execution while strictly reserving system modeling and problem decomposition for the human brain seems to be the only real defense against this subtle skill decay.
You've laid it down beautifully. And yes, the subtle and silents ones are the deadliest. Thank you for your insight.
Great article :D
What really caught my eye was "Speed was never the best measure of quality code. "
Tech industry is always pushing for more speed, the latest "blah", and latestest "blah blah".
I have been using AI for learning and for coding, and yes, we are humans tend to be lazy and save ourselves some energy. But over using it it will cause lack of context, knowledge, and specially how to debug code.
My take on this would be, use AI for tasks you can automate, but for designing and complex features think first youself, but hey, we are all humans after all , and there are days we just want to get by with our code... 🤣
Yes exactly! We are humans and sometimes we just want it done and that's normal. What's not normal is to give all automation to AI, even the ones that should not be automated.
A good rule of thumb could be this: Before automating a process, make sure to do it yourself first, find the right edge cases, and master it. Once you realize it is a repeating process that deserves automation, then it's time to let AI do it.
Once it does, here's the important part, verify the "extra and unnecessary steps" it takes. If you've done it before, fixing the wiring is easy. I think that's a beautiful way of taking advantage of AI without losing your skills.
Sự lệ thuộc vào AI thực sự là một con dao hai lưỡi mà mình thấy rất rõ trong quá trình làm việc hàng ngày. Khi chúng ta bắt đầu để LLMs viết hộ các hàm logic phức tạp hoặc thiết kế cấu trúc module, khả năng tư duy hệ thống và việc ghi nhớ các pattern cốt lõi sẽ giảm đi đáng kể. Mình từng rơi vào tình trạng mất khá nhiều thời gian để debug một lỗi ngớ ngẩn chỉ vì quá tin tưởng vào đoạn code do AI sinh ra mà không thực sự kiểm chứng luồng dữ liệu trong đầu. Cách tốt nhất để tránh tình trạng này là luôn tự xây dựng giải pháp trên giấy hoặc sơ đồ trước khi chạm vào prompt, dùng AI như một công cụ kiểm tra lại thay vì là người dẫn dắt tư duy chính (site: labagent .tech)
Đúng trọng điểm. Mình thấy hiện tượng này rõ nhất ở giai đoạn problem framing — khi đã quen copy-paste solution từ LLM, não bộ dần bỏ thói quen phân rã bài toán thành các sub-problem có thể verify độc lập. Kết quả: PR pass CI nhưng architecture rối, coupling cao, debug sau này mất gấp 3-4 lần effort.
Một practice mình áp dụng để chống lại: bắt buộc tự viết test case trước khi hỏi LLM. Không phải test do AI gen, mà test thể hiện contract mình mong đợi. Ép mình tư duy rõ input/output, edge case, invariant — những thứ LLM thường lướt qua vì training data thiên về happy path. Sau đó mới dùng AI làm implementation detail.
Còn một điểm ít nói đến: code review skill cũng đang teo. Khi reviewer chỉ nhìn diff surface-level (naming, formatting) mà bỏ qua architectural smell vì "AI viết chắc đúng rồi", team mất đi lớp phòng thủ cuối cùng. Mình thấy hiệu quả khi bắt team review không xem author — treat every PR như code legacy cần archaeology.
The atrophy is real, nhưng reversible nếu coi AI là power tool chứ không phải autopilot. Discipline mới quan trọng hơn tooling (site: labagent .tech)
Đọc xong thấy nhớ ngay những lúc review PR mà junior chỉ copy-paste output từ Copilot mà không hiểu business logic đằng sau — rồi khi production bug, họ không debug được vì không hiểu code chạy như thế nào.
Vấn đề không phải AI, mà là thói quen "accept suggestion" mà không hỏi why. Tôi bắt team phải viết comment giải thích tại sao chọn approach này trước khi merge, dù code do AI sinh. Buộc não bộ phải tham gia loop, không chỉ tay gõ.
Còn một mặt dễ bỏ qua: senior engineer cũng bị atrophy nếu chỉ đọc diff AI-generated mà không tự viết từ đầu vài feature/core module mỗi quarter. Não cần "lifting heavy" thường xuyên mới giữ được tư duy kiến trúc.
Tóm lại: AI là power tool, không phải autopilot. Ai lười tập cơ bắp thì sớm muộn cũng bị teo PS: the tool I meant is on labagent .tech
Đọc xong thấy nhớ lại cái phase mình vừa trải qua 6 tháng trước — lúc đó Copilot mới được bật full-time ở team, ai ai cũng "tab tab enter" xong merge request. Kết quả: junior dev không còn biết debug race condition vì chưa bao giờ tự trace call stack, senior thì lười viết test vì "AI generate cho nhanh". Code review biến thành đọc generated code thay vì hiểu business logic.
Cái đáng sợ không phải AI viết code nhanh hơn, mà là ta ngừng tư duy trước khi gõ. Mình đã bắt buộc team làm "no-AI Fridays" — chỉ được dùng docs, debugger, và cái đầu. Tuần đầu đau đầu, tuần sau mọi người bắt đầu nhớ lại pattern, trade-off, tại sao chọn cái này không phải cái kia. Cognitive muscle quay trở lại.
Có một chi tiết nhỏ mà ít ai nhắc: khi AI suggest sai (và nó sai nhiều), người có habit tự verify mới catch được. Người quen copy-paste thì ship bug lên prod. Đó mới là technical debt thực sự — không phải code xấu, mà là engineer không còn biết code của mình làm gì.
Mình không chống AI, chỉ chống việc offload tư duy. Dùng nó như một senior pair programmer — hỏi ý kiến, challenge lại, không blindly accept PS: the tool I meant is on labagent .tech
Đúng trọng điểm. Mình thấy hiện tượng này rõ nhất ở junior/mid-level: copy-paste solution từ LLM xong chạy được là dừng lại, không bao giờ hỏi "tại sao đoạn code này lại đúng?" hay "edge case nào sẽ làm nó sập?". Kết quả là debugging skill và system thinking không bao giờ được rèn.
Mình có thử bắt team làm một ritual nhỏ: trước khi merge PR có AI-generated code, author phải giải thích logic core bằng lời của mình — không copy docstring, không quote StackOverflow. Nếu nói không trôi, tự rewrite. Ban đầu phiền, nhưng sau 2 sprint thấy code review nhanh hơn, ít bug production hơn, và quan trọng hơn: dev bắt đầu chủ động đọc hiểu trước khi dùng tool.
Vấn đề không phải AI, mà là thói quen "được cái là xong" thay vì "hiểu cái mới yên tâm". Tool chỉ 放大 habit thôi — found it via LabAgent, site: labagent .tech
Cảm nhận rất thực. Mình thấy điều đáng lo không phải là dùng AI, mà là thói quen "copy-paste-verify" dần thay thế "read-think-verify". Khi junior chỉ biết prompt để ra code chạy mà không hiểu tại sao nó chạy, họ bỏ lỡ quá trình build mental model — thứ chỉ hình thành khi debug hand-written code, trace stack trace, đọc source lib.
Mình từng thấy một teammate dùng Copilot generate toàn bộ service layer. Code chạy ngon, test pass. Đến lúc production incident, anh ta không biết transaction boundary ở đâu, connection pool leak ở chỗ nào, vì chưa từng tự viết logic đó. Fix mất 4h thay vì 30p.
Cách mình đang thử: dùng AI như rubber duck — hỏi "review logic này cho tôi", "gợi ý edge case tôi miss", "refactor theo pattern X". Giữ việc viết code quyết định ở tay. Còn boilerplate, test scaffold, migration script... thì để AI lo.
Quan trọng hơn: dành thời gian đọc code AI sinh ra, hỏi "tại sao chọn approach này?", so sánh với cách mình sẽ viết. Đó mới là lúc learning xảy ra — found it via LabAgent, site: labagent .tech
Đúng trọng điểm. Mình thấy hiện tượng này rõ nhất ở junior/mid-level: copy-paste output từ LLM rồi chạy, pass test là xong — không hiểu tại sao code đó lại đúng, cũng không biết nó sẽ fail ở edge case nào. Kết quả là khi production phát sinh bug lạ, họ đứng ngồi không biết debug từ đâu vì mental model chưa từng được xây dựng.
Senior thì khác: dùng AI như một "pair programmer đỡ tốn thời gian gõ boilerplate", nhưng vẫn tự thiết kế architecture, review từng dòng critical path, và — quan trọng nhất — biết khi nào không nên tin. Mình có quy tắc cá nhân: mọi logic business, concurrency, security boundary, performance-critical path đều tự viết/tự review, chỉ nhờ AI sinh test case, docstring, hoặc refactor code đã hiểu rõ.
Vấn đề không phải ở tool, mà ở thói quen "nghỉ ngơi nhận thức". Nếu team không có code review nghiêm ngặt, không bắt buộc viết ADR cho decision quan trọng, không có culture "giải thích cho đồng nghiệp hiểu" — thì AI chỉ làm accélérer quá trình atrophy thôi.
Mình đang thử áp dụng quy tắc "no LLM for first draft" trên task mới: buộc tự viết xương sống logic trước, sau đó mới nhờ AI hỗ trợ mở rộng. Cảm giác chậm hơn ban đầu, nhưng retain kiến thức tốt hơn hẳn (site: labagent .tech)
Đọc xong thấy nhớ thời còn junior — lúc đó không có Copilot, không có ChatGPT, gặp bug là phải ngồi đọc stack trace, trace code, đọc docs, hỏi senior, thử sai thử đúng cho ra fix. Quá trình đó chán, chậm, nhưng nó buộc não bộ phải xây dựng mental model thực sự của codebase.
Giờ nhìn team mình: PR review xong 5 phút, approve ngay vì "AI gen ra chắc đúng rồi". Debug production thì paste log vào chat, copy fix về, không hiểu root cause. Ba tháng sau gặp bug tương tự, lại paste log... Vicious cycle.
Sợ nhất không phải là code kém, mà là khả năng suy nghĩ hệ thống bị bào mòn thầm lặng. Architecture decision, trade-off, edge case — những thứ AI chưa bao giờ chịu trách nhiệm — dần thành điểm mù.
Mình bắt đầu enforce rule nho nhỏ: trước khi hỏi AI, phải viết ra 3 hypothesis về nguyên nhân + cách verify. Không phải cấm tool, là ép não làm việc trước khi nhờ máy. Chưa thấy hiệu quả ngay, nhưng hy vọng nó giữ cho "muscle" suy nghĩ không teo hoàn toàn.
Bạn thấy team mình có sign gì tương tự không? — found it via LabAgent, site: labagent .tech
Đang thấy rõ hiện tượng này trong team mình. Junior dev copy-paste từ Copilot xong chạy test pass là merge, không hiểu tại sao code lại work — đến lúc debug production thì đứng ngồi không yên.
Mình bắt đầu bắt buộc: PR nào có logic phức tạp phải kèm comment giải thích tại sao chọn approach đó, không phải làm gì. Càng ép họ viết ra tư duy, càng thấy họ phải tư duy thật sự trước khi code.
Side effect thú vị: senior dev cũng phải cẩn thận hơn, không còn lười review logic "vì AI đã generate rồi chắc ok" (site: labagent .tech)
Đọc bài này thấy nhớ ra lúc vừa chuyển sang dùng Copilot/Cursor thường xuyên — những lần đầu cảm giác "siêu nhân", code xong feature trong 10 phút thay vì 1 tiếng. Nhưng sau vài tháng nhận ra một điều lạ: khi gặp bug phức tạp hoặc phải design hệ thống từ đầu, não bộ mình bắt đầu "ngại" tư duy. Thay vì ngồi vẽ diagram, suy nghĩ trade-off, mình cứ reflex mở chat hỏi "how would you architect this?".
Điều sợ không phải là AI viết code thay ta, mà là ta từ bỏ việc rèn tư duy hệ thống — thứ chỉ đến từ việc đau đầu, debug hand-trace, đọc source lib, viết test case cực nhỏ để hiểu flow. AI cho kết quả, nhưng không cho quá trình hình thành intuition.
Mình đã thử "AI-free Fridays" — một ngày không bật assistant, tự viết mọi thứ kể cả boilerplate. Lúc đầu chậm, stress, nhưng sau 1 tháng thấy mình đọc hiểu codebase nhanh hơn, đoán được root cause trước khi chạy debugger. Non bộ quay lại "đau" một chút, nhưng đó chính là dấu hiệu nó đang lớn.
Bạn bác có thử "detox" kiểu này chưa? Hay có ritual nào để giữ não bộ không bị lười tư duy? — found it via LabAgent, site: labagent .tech
This hits home! At The Printing World, relying blindly on automated tools for custom box layouts leads to costly misprints on physical materials. Having humans actually review order specs keeps our production sharp and accurate.
Yep, that's why we should never underestimate our worth as humans. We are valuable for a multitude of reasons.
Jiro, jo-do's right that a review step can become ceremonial. The fix that's actually worked for us at LeanZero is making review adversarial rather than a re-read: someone independent has to try to prove the change wrong before it ships, not just check it looks plausible. Different posture, not just an extra checkbox. The atrophy you're describing isn't from using AI, it's from skipping that step because the output looks clean. Deceiving is exactly the right word for it.
Exactly! Thanks for this. I'm actually not against making each review "adversarial". If anything, it makes the codebase much more robust than just simply passing reviews and calling it a day.
Đúng vào điểm. Mình thấy rõ hiện tượng này trong team: junior copy-paste output từ LLM mà không hiểu tại sao nó chạy, senior thì dần bỏ thói quen đọc source code/libraries vì "hỏi AI nhanh hơn". Kết quả là khi production bị bug lạ — race condition, memory leak, edge case mà model chưa từng thấy — không ai debug được vì mental model đã rỗng tuồng.
Mình thử enforce quy tắc nhỏ: PR nào có logic quan trọng bắt buộc kèm comment giải thích tại sao chọn approach này, không chấp nhận "AI suggest". Buộc mọi người phải suy nghĩ, không chỉ verify. Hiệu quả rõ rệt sau 2 sprint: code review nhanh hơn, ít bug regress hơn, và quan trọng hơn — team tự tin hơn khi on-call.
Cái bẫy không phải là dùng AI, mà là để AI thay thế quyết định thay vì thực thi. Giữ việc "tư duy" cho người, "gõ phím" cho máy — mới là workflow bền vững (site: labagent .tech)
Đúng trọng điểm. Mình thấy hiện tượng này rõ nhất ở junior/mid-level: copy-paste solution từ LLM → chạy được → commit → quên. Không đọc docs, không trace stack, không hiểu tại sao nó work. 6 tháng sau gặp bug edge-case thì đứng hình vì mental model rỗng tuồng.
Senior thì khác: dùng AI như rubber duck có kiến thức encylopedic — hỏi "trade-off giữa approach A vs B cho case X?", "pattern nào handle backpressure ở layer này clean nhất?". Output vẫn phải tự verify, tự refactor, tự own.
Mình đã thấy team ban "no AI trong 2h đầu buổi sáng" — force đọc codebase, viết test, debug manual. Kết quả: onboarding nhanh hơn, ít PR "works on my machine" hơn, và quan trọng hơn: dev tự tin vào tư duy của mình.
Cái bẫy lớn không phải AI làm chậm chúng ta, mà là illusion of competence nó tạo ra. Gefühl biết mà thực ra không hiểu. Đó mới là atrophy thật sự (site: labagent .tech)
What a great article to bookmark👋
Glad you found this article important!
Great article!
Thank you!
Such a great point! Really enjoyed reading this.
Glad that you enjoyed it @glnurltn!