Phân tích cảm giác mệt mỏi khi "vibe coding" của lập trình viên do tốc độ AI vượt nhanh hơn tư duy
(tabulamag.com)Điểm chính:
- Tốc độ phát triển tăng lên nhờ các công cụ AI (Claude Code, Cursor), nhưng nhịp độ làm việc quá nhanh vượt quá giới hạn xử lý của não bộ, gây ra mệt mỏi
- Việc chuyển đổi ngữ cảnh thường xuyên, dư thừa dopamine và sự chuyển vai trò sang người quản lý làm gia tăng gánh nặng nhận thức
- Xuất hiện hiện tượng "thời gian máy móc" khi con người bị AI kéo theo về tốc độ, làm nổi bật nhu cầu chủ động điều tiết nhịp độ
Mở đầu
- Lợi ích và tác dụng phụ của công cụ AI: Một lập trình viên với 40 năm kinh nghiệm đã sử dụng Claude Code và Cursor để phát triển trình quản lý gói (Marvai), trải nghiệm được sự gia tăng năng suất nhưng đồng thời cũng cảm thấy mệt mỏi ở mức chưa từng có.
- Nêu vấn đề: Trong khi tốc độ triển khai tính năng và sửa lỗi tăng lên, não bộ lại không theo kịp tốc độ của AI, dẫn đến hiện tượng kiệt sức ngay cả sau thời gian làm việc ngắn (khoảng 1 giờ).
Nội dung chính
1. Sự gia tăng đột biến của gánh nặng nhận thức và áp lực của "thời gian máy móc"
- Áp dụng lý thuyết gánh nặng nhận thức: Theo lý thuyết Team Topologies, trách nhiệm quá nhiều và việc chuyển đổi chủ đề liên tục sẽ làm tăng gánh nặng nhận thức. Lập trình với AI đẩy gánh nặng này tới sát giới hạn.
- Nhịp điệu do máy dẫn dắt: Tương tự áp lực mà công nhân nhà máy trước đây phải chịu khi phải làm việc theo tốc độ của máy móc, lập trình viên nay cũng trải nghiệm hiện tượng bị AI thúc ép chạy theo nhịp lập trình quá nhanh ("thời gian máy móc").
- Sự biến mất của quá trình tư duy: Trước đây, tốc độ viết mã và tốc độ suy nghĩ tương đối đồng bộ nên não bộ có khoảng trống để xử lý (Baking time), nhưng lập trình với AI xử lý ngay lập tức các kiến trúc và quyết định phức tạp, cản trở sự đồng bộ của não bộ.
2. Sự cùng tồn tại của dư thừa dopamine và hormone căng thẳng
- Vòng lặp dopamine tăng tốc: Chu kỳ phần thưởng dopamine nối tiếp "viết mã - lỗi - giải quyết - thành công" được AI đẩy nhanh đến mức cực độ.
- Kiệt quệ cảm xúc: Việc dopamine tiết ra thường xuyên cùng với hormone căng thẳng phát sinh do tốc độ cao cùng lúc tác động, khiến việc lập trình không còn đem lại niềm vui mà thay vào đó là mệt mỏi và cảm giác bị quá tải.
3. Chi phí chuyển đổi ngữ cảnh (Context Switching) gia tăng
- Bộ nhớ đệm của não bị quá tải: Chuyển đổi ngữ cảnh là một công việc tiêu tốn nhiều năng lượng vì phải xóa rồi nạp lại "cache" của não.
- Chuyển đổi ngữ cảnh vi mô (Micro-Context Switching): AI buộc người dùng phải liên tục thực hiện những lần chuyển đổi nhỏ, chẳng hạn sửa nhiều mô-đun cùng lúc hoặc ngay cả khi chỉ dùng tính năng hoàn thành tab đơn giản (phím
Tab), khiến phải thường xuyên đổi từ "chế độ viết" sang "chế độ rà soát", làm năng lượng não bộ cạn kiệt rất nhanh.
4. Sự thay đổi mang tính bản chất trong vai trò của lập trình viên
- Từ người viết sang người quản lý: Vai trò đã chuyển từ người hiện thực hóa yêu cầu thành mã sang kiểu "trưởng nhóm" hoặc "người điều phối" quản lý và rà soát đầu ra của một "đồng đội siêu nhanh" là AI.
- Sự bất đối xứng của trách nhiệm: Trong khi AI có thể tạo ra khối lượng công việc tương đương 5 người, lập trình viên vẫn phải gánh trách nhiệm cuối cùng về chất lượng mã, làm tăng thêm gánh nặng quản lý.
Kết luận
Đề xuất cho việc lập trình với AI theo hướng bền vững
- Điều tiết tốc độ có chủ đích (Pacing): Lập trình viên cần chủ động kiểm soát nhịp độ làm việc thay vì để mình bị cuốn theo tốc độ của AI.
- Đưa vào cách hồi tưởng mới: Cần có các quy trình làm việc mới như retrospective hằng ngày để đồng bộ AI với nhịp xử lý của não bộ.
- Chuyển đổi cách nhìn nhận vai trò: Cần giảm xu hướng micromanage đầu ra của AI và thay đổi phong cách làm việc theo hướng tin tưởng AI hơn.
- Triển vọng tương lai: Tương lai của lập trình có thể không phải là tăng tốc vô điều kiện, mà là một kiểu "chậm lại có chủ đích" và thiết lập những ranh giới mới có tính đến giới hạn nhận thức của con người.
14 bình luận
Tôi cũng có trải nghiệm tương tự nên làm như thế này.
Ví dụ, nếu đang refactor,
'Hãy phân tích mã hiện có rồi đề xuất phương án thay thế'
'Hãy tóm tắt và giải thích sự khác biệt giữa phương án thay thế và mã hiện có, cùng ưu nhược điểm của chúng'
'Hãy đề xuất cách có thể kiểm chứng liệu phương án thay thế có thực sự tốt hơn hay không'
'Tự mình kiểm chứng phương án thay thế'
'Yêu cầu áp dụng phương án thay thế và viết tài liệu, bài kiểm thử'
Vấn đề là lượng token sử dụng quá nhiều nên chi phí rất tốn kém...
Ngay cả với mấy việc đơn giản, tôi vẫn thấy thoải mái hơn nếu cứ tạo hẳn một cái macro...
Giữa con người với nhau cũng vậy.
Ngay cả giữa con người với nhau, vấn đề này cũng thường xảy ra.
Nếu người suy nghĩ chậm là quản lý,
thì sẽ nói: “Công việc diễn ra quá nhanh nên rất mệt, khó làm việc cùng.”
Còn nếu người đó là cấp dưới,
thì sẽ nói: “Vì không hiểu ý người khác cho lắm nên rất khó làm việc cùng.”
Cuối cùng, để có thể làm việc cùng nhau, hai bên phải hợp cạ với nhau.
Nỗi khổ khi bị tước mất việc viết mã, chỉ còn phải làm code review và kiểm thử...
Ngoại trừ các dự án cá nhân, tôi chỉ dùng vibe coding ở mức hạn chế. Với tính năng tự động hoàn thành của Cursor, tôi chỉ dùng cho ideation hoặc những đoạn code lặp lại cùng một mẫu. Trong các dự án dài hạn, cố giải quyết mọi thứ bằng vibe coding thì tôi cho rằng đó là hành động thiếu trách nhiệm với tư cách là một lập trình viên.
Có vẻ như những người hiểu mã của kết quả đã được tạo ra và làm công việc xác minh/kiểm tra sẽ cảm thấy mệt mỏi hơn so với những người chỉ viết prompt rồi chỉ lấy kết quả. Điều này cũng có trong bài gốc.
Tôi chỉ nghĩ là “May quá, nhờ AI mà việc tôi phải làm đã giảm đi”, nên chưa từng trải qua kiểu mệt mỏi này lần nào. Tôi dùng zed + claude, đôi khi giữa chừng ngữ cảnh bị đổi nên nó hoạt động kỳ lạ, nhưng những lúc đó chỉ cần hoàn tác code trong git rồi bảo nó “hãy tổng hợp nội dung ở trên và viết lại”, thì nó lại làm ra phiên bản gọn gàng hơn. Chẳng phải chỉ là quá trình biến những ý nghĩ trong đầu thành code đã thay đổi, chứ không còn là tự tay gõ từng dòng để viết code nữa thôi sao? Thậm chí trong lúc nhập prompt, suy nghĩ còn được sắp xếp lại rõ ràng hơn nữa.
Chẳng phải khi quá trình tạo ra mã trở thành một chiếc hộp đen thì sẽ cần thời gian để đồng bộ giữa mã và những gì đang có trong đầu sao?
Việc viết mã theo cách truyền thống đảm bảo rằng mã và ý nghĩ trong đầu là giống nhau, nhưng với coding thông qua LLM thì điều đó không được đảm bảo.
Trong đầu chỉ cần có logic và kiểm tra xem mã do AI viết có đúng hay không, chẳng phải không cần phải tự viết mã trong đầu nữa sao? Chỉ cần tập trung nghĩ xem phải đưa dữ liệu chính xác đến mức nào vào prompt là được, nên ngược lại tốc độ xử lý công việc đã nhanh hơn rất nhiều.
Có lẽ điều này cũng có thể khác nhau tùy vào mức độ prompt cụ thể đến đâu. Nếu giao cho LLM ở mức pseudocode thì tôi hiểu ý bạn nói.
Trước đây, dù viết code cả ngày thì khi kết thúc công việc vẫn thường có cảm giác rất mãn nguyện, nhưng giờ đây phần lớn công việc trong ngày lại được xử lý bằng hội thoại, đến mức nhiều ngày tôi không trực tiếp viết nổi một dòng code nào mà vẫn bị burnout.. Tôi hoàn toàn đồng cảm
Tôi cũng mệt hơn đúng vì chính lý do này. Tôi cũng đã đoán trước là sẽ như vậy nên bản thân chuyện mệt mỏi thì không sao, nhưng vấn đề hơn là nhìn từ bên ngoài, vì không còn khoảng thời gian gõ bàn phím liên hồi khi code nữa nên có vẻ mọi người nghĩ tôi đang làm việc rất thong thả. Mỗi khi tôi nói rằng mình còn mệt hơn trước, họ lại không hiểu lắm....
À, tôi có cảm giác như cuối cùng cũng được ai đó diễn giải thay một cách rõ ràng vì sao mình lại mệt mỏi.
1. "Tốc độ là nguồn sinh lực" (phe tích cực)
2. "Tranh cãi về định nghĩa của vibe coding" (sự hỗn loạn về thuật ngữ)
3. "Tốc độ không kiểm chứng là nợ kỹ thuật" (phe thận trọng)
4. "Mệt mỏi vì chuyển đổi ngữ cảnh" (phe đồng cảm)
5. "Đánh mất niềm vui của việc code" (thiếu dopamine)
6. "Thuốc độc với người mới, thuốc bổ với người thành thạo" (khác biệt theo trình độ)
7. "Bị ép chuyển sang vai trò quản lý" (thay đổi vai trò)
8. "Thiếu sự thấu hiểu business logic" (chỉ ra giới hạn)
9. "Sự biến mất của nghỉ ngơi và khoảng thở" (thời gian máy móc)
10. "Vấn đề chuyển tiếp của công cụ" (triển vọng tương lai)