- Khi các nhà phát triển sử dụng rộng rãi các công cụ AI coding, năng suất đã tăng lên, nhưng đồng thời cũng phát sinh những chi phí nhận thức và tổ chức khó nhìn thấy
- Từ các công cụ hỗ trợ ban đầu như Copilot·Cursor, xu hướng gần đây đã tiến hóa thành tác nhân tự trị, chuyển sang mô hình con người hỗ trợ AI
- Tuy nhiên, việc sử dụng theo kiểu ủy quyền hoàn toàn gây ra nợ nhận thức (cognitive debt) và suy giảm năng lực gỡ lỗi, làm yếu đi khả năng giải quyết vấn đề và mức độ hiểu mã của lập trình viên
- Cấu trúc trong đó AI viết mã còn con người chỉ rà soát dẫn đến sự sụp đổ của lộ trình đào tạo senior và mất đi trạng thái nhập tâm sáng tạo (flow), khiến năng lực kỹ thuật của tổ chức bị bào mòn về dài hạn
- Việc tận dụng AI là cần thiết, nhưng cần tự đặt ra ‘ngưỡng sử dụng phù hợp’, đồng thời điều chỉnh theo cách vẫn duy trì được sự hiểu biết và học hỏi của con người
Sự tiến hóa của việc áp dụng AI coding
- Các công cụ như Copilot·Cursor xuất hiện trong giai đoạn 2022~2023 đã lập chỉ mục codebase để cung cấp tính năng tự động hoàn thành và chat dựa trên ngữ cảnh
- Việc tìm kiếm trên Google hay StackOverflow gần như không còn cần thiết, và môi trường IDE tích hợp AI đã lan rộng
- Sau đó, quy trình làm việc kiểu agent xuất hiện, chuyển từ hỗ trợ con người sang phát triển do AI dẫn dắt
- Tuy nhiên, agent gặp các vấn đề về độ tin cậy như vòng lặp, ảo giác và lỗi phụ thuộc
- Từ sau Opus 4.5, mức độ tự động hóa tăng cao, và tại một số công ty đã xuất hiện trường hợp lập trình viên không còn trực tiếp viết mã
- Ví dụ: đồng CEO của Spotify cho biết kỹ sư có thể ra lệnh cho Claude trên Slack để chỉnh sửa và triển khai tính năng
Nợ nhận thức và sự thoái hóa kỹ năng
- Bài viết viện dẫn khái niệm ‘Digital Dementia’ của Manfred Spitzer và ‘Cognitive Debt’ của Margaret-Anne Storey
- Khi giao phó tư duy lặp đi lặp lại cho AI, các đường mòn nhận thức của não bộ bị suy yếu, kéo theo sự suy giảm khả năng hiểu mã
- Nghiên cứu của Shen·Tamkin (2026): trong 52 nhà phát triển, nhóm được AI hỗ trợ có điểm thấp hơn 17% ở khả năng hiểu khái niệm, gỡ lỗi và đọc mã
- Đặc biệt, sự suy giảm năng lực gỡ lỗi là rất rõ rệt, và chỉ 1 giờ sử dụng AI một cách thụ động cũng đủ tạo ra sự xói mòn kỹ năng có thể đo được
- Khi AI xử lý thay các thử thách, nó tạo ra trạng thái ‘dark flow’ thay vì ‘flow’ thật sự, khiến sự phụ thuộc tăng lên mà không đi kèm học hỏi
Nghịch lý code review và sự sụp đổ của senior
- Nếu AI viết mã còn con người chỉ review, sẽ xuất hiện nghịch lý là nguồn gốc của năng lực review dần biến mất
- Những nhà phát triển phụ thuộc hoàn toàn vào AI có thể làm việc nhanh hơn, nhưng điểm đánh giá lại ở mức thấp nhất
- Storey đề xuất rằng “con người phải hiểu đầy đủ các thay đổi do AI tạo ra trước khi triển khai”
- AI có thể cung cấp cho người mới bắt đầu đầu ra ở mức senior, nhưng đó chỉ là sự sao chép không có hiểu biết
- Senior không còn trực tiếp viết mã nên mất đi chiều sâu, còn junior không trải qua thử-sai nên không thể trưởng thành
- Kết quả là pipeline đào tạo senior bị sụp đổ
Sự ngộ nhận của ban lãnh đạo và tác dụng phụ ở cấp tổ chức
- Lãnh đạo tại Microsoft, Anthropic, Google dự đoán rằng AI sẽ thay thế kỹ sư chỉ trong vài tháng
- Google báo cáo rằng vào cuối năm 2024, 50% mã nguồn mới được tạo bởi AI
- Tuy nhiên, những con số này bị cho là thổi phồng nhằm bán AI và nâng đỡ giá cổ phiếu, nên không thể áp dụng cho các tổ chức thông thường
- Một số công ty còn đo mức sử dụng AI bằng KPI và ép buộc nhà phát triển phải dùng
- Trường hợp Reddit: các nhà phát triển thao túng số liệu sử dụng AI bằng những câu lệnh vô nghĩa
- Kết quả là định luật Goodhart phát huy tác dụng, để lại sự tuân thủ hình thức thay vì cải thiện năng suất thực sự
Chi phí mang tính con người và sự mất mát sáng tạo
- Viết mã mang lại niềm vui của sự nhập tâm và sáng tạo, trong khi review mã do AI tạo ra lại gây mệt mỏi tinh thần
- Khi phần thưởng dopamine từ việc sáng tạo biến mất, burnout tăng tốc
- Công việc phát triển bị hạ xuống thành kiểm soát chất lượng (QA), và cảm giác thỏa mãn sáng tạo cũng biến mất
- Tình huống này được ví như AI làm hết mọi loại hình nghệ thuật còn con người chỉ gấp quần áo
Ngưỡng sử dụng AI phù hợp
- AI là công cụ mạnh mẽ, nhưng không phải dùng càng nhiều hay càng ít thì càng tốt
- Nghiên cứu của Shen·Tamkin cho thấy trong 6 kiểu tương tác với AI,
- ‘ủy quyền hoàn toàn·phụ thuộc tăng dần·giao việc gỡ lỗi’ làm cản trở việc học
- ‘yêu cầu giải thích·hỏi về khái niệm·tự code rồi mới đối chiếu’ giúp duy trì việc học
- Cốt lõi là duy trì sự tham gia về mặt nhận thức, nghĩa là điều quan trọng không phải có dùng AI hay không mà là cách dùng
- Nếu hoàn toàn không dùng AI, bạn sẽ mất đi hiệu quả trong tìm kiếm, boilerplate và khám phá,
còn nếu dùng quá mức thì khả năng hiểu, lộ trình đào tạo senior, phát hiện bug và cảm giác nhập tâm sẽ bị tổn hại
Sự suy thoái âm thầm
- Trên chỉ số bề mặt, số lượng PR, số tính năng và cycle time đều được cải thiện, nhưng
năng lực kỹ thuật nội tại, sự tập trung và khả năng giải quyết vấn đề lại dần suy yếu
- Nhà phát triển trở thành một kiểu ‘butter robot’ chỉ nhấn phê duyệt mà không hiểu cấu trúc do AI tạo ra
- Simon Willison cũng cho biết trong một dự án, vì không review tính năng do AI tạo ra nên
ông “không còn hiểu rõ cách hoạt động bên trong nữa”
- Cuối cùng, thứ bị thoái hóa không phải công cụ mà là con người, và sự thay đổi này vừa không được đo lường, vừa không được quản lý
- Sự phụ thuộc vào AI diễn ra như một cơn nghiện, và có nguy cơ dẫn tới sự suy giảm kỹ năng âm thầm nhưng thực chất
1 bình luận
Ý kiến trên Hacker News
Tôi vẫn thấy quá trình tự tay viết code và vẽ cấu trúc trong đầu là một trong những niềm vui của công việc
Ngay cả việc refactor lặp đi lặp lại hay phiền phức, với tôi, cũng là một quá trình có ý nghĩa
Những khoảnh khắc vất vả đó trở thành chất liệu học hỏi giúp lần sau tìm ra cách tốt hơn
Nó vẫn còn như một hy vọng rằng một ngày nào đó xu hướng này sẽ quay lại
Tôi tin rồi sẽ có lúc giá trị của những người vẫn giữ được khả năng tự lựa chọn và phán đoán lại được công nhận
Nếu code khó test thì cần thay đổi abstraction hoặc interface
Test là lần tái sử dụng đầu tiên của code, nên nếu test đã bất tiện thì khi dùng thực tế cũng sẽ bất tiện
Code do chính mình viết thì dễ hình dung trong đầu hơn là lỗi sẽ phát sinh ở đâu
LLM không thể thay thế trực giác đó dù bạn có ném bao nhiêu log cho nó đi nữa
Nhưng tôi lo điều này có thể làm mất đi động lực cải thiện hệ sinh thái frontend
Ngay cả những việc mà người khác muốn giao cho LLM làm, tôi vẫn thấy vui khi tự mình làm
Thấy các công ty dần dần lấy mất những niềm vui nhỏ bé ấy thì thật buồn
Trong năm qua tôi đã dùng Claude Code rất nhiều, và gần đây cảm nhận được sự thay đổi cảm xúc quanh việc dùng AI giữa các đồng nghiệp
Tôi đã viết một bài về chi phí ẩn phát sinh khi lạm dụng AI, đồng thời gom dữ liệu từ nhiều nguồn
Dù vẫn chưa có dữ liệu thật rõ ràng, có vẻ rất nhiều lập trình viên cũng đang cảm thấy như vậy
Tuy nhiên, cách nói “software chỉ là công cụ” lúc nào cũng nghe khá lạ
Khi một công cụ có thể thay thế việc suy nghĩ, liệu ta vẫn nên gọi nó là “công cụ” chăng?
Tôi thích cách nói thẳng thắn là “nghiện prompt”. Nhưng sẽ hay hơn nếu khám phá thêm khía cạnh của nghiện hành vi
Nó nhanh và có vẻ như đang trong tầm kiểm soát, nhưng dần dần ta lại mất kiểm soát
Điều thực sự khó là tìm ra “mức độ sử dụng với tốc độ bền vững là bao nhiêu”
Tôi cũng đã viết một bài blog về chủ đề tương tự,
nhưng tiếp cận từ góc nhìn giúp lãnh đạo dẫn dắt tổ chức tìm được sự cân bằng bền vững
Tôi đã tìm các bài nghiên cứu về ảnh hưởng của working memory và hệ thống phần thưởng tới việc học và sự tập trung
Ví dụ, bài báo Nature nói rằng working memory có độ phản ứng với dopamine
Và bài viết trên Scientific American cho rằng việc viết bằng tay kích hoạt nhiều vùng não hơn
Cuối cùng, kết luận là với những công việc thụ động, ít phần thưởng, các lợi ích nhận thức này gần như không có
Vì vậy tôi nghĩ tiêu chí dùng AI nên là “công việc này đau đớn và ít phần thưởng tới mức nào?”
Tôi vẫn tự tay viết code và hiểu hoàn toàn kết quả tạo ra
Tăng tốc gì đó không quan trọng. Điều quan trọng là cảm giác sở hữu rằng đây là code của tôi
Trước đây tôi cũng có thể thuê ngoài, nhưng như vậy chỉ biến tôi thành người đi đọc code của người khác
Tôi và đa số lập trình viên quanh mình đều cảm thấy áp lực đó
Dùng bàn phím không làm ta quên viết tay, và mua cà phê không làm ta quên cách pha cà phê
Đầu những năm 80 tôi học code bằng LSI-11 assembly và thuộc hết mọi opcode hệ bát phân
Nhưng khi học FORTRAN 83, năng suất tăng gấp 10 lần, và tôi hoàn toàn không hối tiếc dù những kỹ năng ngày đó bị mai một
Một ngày nào đó, những ngôn ngữ như C++ hay Java cũng sẽ tương tự, trở thành kỹ năng không còn cần thiết
Chính năng lực tư duy logic tích lũy khi làm việc với opcode đã giúp việc học các ngôn ngữ sau này dễ hơn
Kiểu tư duy làm việc với formal language này sâu về nhận thức hơn rất nhiều so với việc viết prompt cho LLM
còn cộng tác với AI là quá trình truyền đạt ý định bằng ngôn ngữ tự nhiên mơ hồ
Trừ khi bạn viết pseudocode bằng tiếng Anh, còn không thì độ chính xác sẽ thấp hơn
Hơn nữa, lần này còn đi kèm với nỗi sợ có thể bị thay thế
Nếu tuân theo ba mẫu sử dụng AI hợp lý thì có thể vừa tăng năng suất vừa học được thêm
Nhưng nếu đi theo phản mẫu thì sẽ dẫn đến lệ thuộc công cụ, lo âu, giảm khả năng debug và nghiện phần thưởng tức thì
Cuối cùng hình thành vòng xoáy suy giảm nhận thức
Gần đây tôi vào làm ở một công ty lấy AI làm trung tâm, nơi gần như cấm coding thủ công
Tôi cho Claude đọc tài liệu API rồi bảo nó tạo wrapper, kết quả thì hoàn hảo,
nhưng bản thân tôi lại hoàn toàn không hiểu được cảm giác hay cấu trúc của API
Trạng thái kiểu “làm được rất nhiều nhưng chẳng thật sự biết gì” này khó chịu và trống rỗng
Ký ức phản xạ không tích lũy được. Vì vậy tôi rất đồng cảm với nội dung bài viết
Tôi đang làm vài side project do AI viết
Tuy vậy, đó là một cảm xúc khá lạ kiểu “nghĩ là tốt nhưng không thật sự chắc chắn”
Kết luận là, dù làm cùng AI, bạn vẫn cần để lại dấu ấn của bản thân thì mới cảm thấy có thành tựu
Tôi mới bắt đầu học code được 8 tháng, và đã học được nhờ AI
Nhưng khi Claude viết code, tôi chỉ hiểu khoảng 70%, phần còn lại thường cứ thế bỏ qua
Cảm giác tốc độ rất gây nghiện, nhưng khả năng giữ toàn bộ cấu trúc trong đầu thì giảm đi
Dù vậy, nếu không có AI thì tôi cũng không thể tạo ra được kết quả hiện tại, nên tôi chấp nhận trade-off này
Ví dụ nó hay lạm dụng fallback code không cần thiết
Nếu chưa có kinh nghiệm thì có thể bạn sẽ không biết đó là sai
Trình độ LLM hiện nay vào khoảng intern đến junior developer
Nút thắt không nằm ở model mà ở khả năng kiểm chứng của chúng ta
Tôi nghi ngờ việc phải dùng LLM chỉ để tự động hóa boilerplate
Chẳng phải với metaprogramming hoặc script truyền thống cũng đã đủ làm được rồi sao?
Và việc về nguyên tắc từ chối AI cũng có thể là một lựa chọn đem lại thỏa mãn
Những kỹ năng cơ bản như dùng chuột và bàn phím, duyệt file, tìm lệnh đều yếu
Vì thế cám dỗ kiểu “thôi cứ hỏi LLM đi” trở nên rất lớn
Nhưng giải pháp thực sự là nâng cao độ thành thạo công cụ và học template engine
AI có thể gây ra sự mai một kỹ năng,
nhưng nếu đó là lĩnh vực tôi không muốn tập trung thì tôi thấy cũng không sao
Ví dụ, không nhất thiết phải biết cả tối ưu hóa bên trong của compiler
Muốn hiểu tương tác giữa các hệ thống thì vẫn cần biết ở mức nào đó về nguyên lý hoạt động của compiler
Giao cho LLM những phần mình không muốn bận tâm,
rồi tập trung tài nguyên não bộ vào những vấn đề thật sự quan trọng