- Tác nhân AI coding đang làm tăng tốc độ viết mã một cách đáng kể, nhưng phần quan trọng nhất trong quá trình phát triển thực tế vẫn là thấu hiểu và giải quyết vấn đề
- Có thể dùng LLM để tạo mã rất nhanh, nhưng do thiếu khả năng nắm bắt toàn bộ ngữ cảnh nên lại tốn nhiều thời gian hơn cho công đoạn hậu xử lý và việc hiểu mã
- Điều này tạo ra khoảng cách giữa kỳ vọng về năng suất và hiệu quả thực tế, đồng thời khiến lập trình viên phải dành thời gian cho những công việc lặp lại và nặng nề như kiểm thử, refactor, tài liệu hóa thay vì công việc sáng tạo mà họ mong muốn
- Giống như “thế lưỡng nan của tech lead” trước đây, nếu dồn các công việc phức tạp cho AI hoặc senior chỉ để đạt kết quả ngắn hạn thì về lâu dài sẽ dẫn tới suy giảm năng lực của cả đội ngũ và phát sinh khủng hoảng
- Cần nhìn nhận LLM như một junior engineer cực kỳ mạnh, và áp dụng các quy trình phát triển đã được kiểm chứng vào việc cộng tác với AI để xây dựng một cấu trúc phân phối phần mềm bền vững
Nhận diện vấn đề: Điều quan trọng hơn cả việc viết mã
- Phát triển phần mềm là công việc xoay quanh giải quyết vấn đề
- Việc viết mã thực tế chỉ là phần cuối cùng trong toàn bộ quá trình tư duy và cân nhắc của lập trình viên
- Ngoài mã nguồn, lập trình viên còn thực hiện nhiều công việc khác như nắm bắt domain, chia nhỏ yêu cầu, trừu tượng hóa, cân nhắc tác dụng phụ, kiểm thử từng bước, sửa lỗi
- Luồng phát triển truyền thống: suy nghĩ đầy đủ rồi mới viết mã
- Trong thời đại AI coding: mô hình chuyển sang mã có trước, hiểu sau
Sự chuyển đổi của AI coding: Một mô hình nơi mã được tạo ra trước
- Các tác nhân AI coding như Claude Code có thể tạo mã rất nhanh, nhưng không thể hiểu đầy đủ ngữ cảnh của toàn bộ hệ thống
- Quá trình review, kiểm thử, tích hợp của con người là bắt buộc, và việc hiểu mã do AI viết sau đó tiêu tốn rất nhiều thời gian
- Marketing thường nhấn mạnh tốc độ viết mã được cải thiện, nhưng mức cải thiện về năng suất phân phối phần mềm đang vận hành thực sự lại không đáng kể
- Lập trình viên phải dành nhiều thời gian hơn cho các công việc lặp lại và khó như kiểm thử, loại bỏ trùng lặp, tài liệu hóa, quản lý hạ tầng đối với sản phẩm do AI tạo ra
- Niềm vui thực sự của việc viết mã giảm đi, trong khi trải nghiệm làm việc với các tác vụ lặp lại lại tăng lên
Thế lưỡng nan lâu đời của lãnh đạo kỹ thuật
- Khi kỹ sư đảm nhận vai trò tech lead, họ phải gánh vác trách nhiệm chuyển giao kỹ thuật của cả nhóm
- Khi kinh nghiệm trong nhóm tập trung vào một người, sẽ xuất hiện sự mất cân bằng năng suất
- Nảy sinh mâu thuẫn giữa hai chiến lược: phân bổ công bằng (coi trọng sự phát triển của thành viên) và dồn việc (ưu tiên phát triển nhanh)
- Dồn việc mang lại lợi ích ngắn hạn lớn, nhưng do kinh nghiệm bị lệch về một phía nên sẽ gây ra rủi ro dài hạn cho đội ngũ (thiếu người trụ cột, burnout, khó hỗ trợ)
- Muốn có văn hóa đội ngũ lành mạnh, cần một cách cân bằng giữa tăng trưởng và hiệu quả
Cốt lõi của lãnh đạo tốt: Cân bằng giữa quy trình và phát triển
- Cần áp dụng nhiều nguyên tắc phát triển và framework khác nhau để cả nhóm có thể tiếp thu kinh nghiệm và bí quyết của các kỹ sư dày dạn
- Ví dụ: extreme programming, code review, triển khai dần từng bước, thiết kế mô-đun, phát triển hướng kiểm thử, pair programming, tài liệu hóa, tích hợp liên tục
- Mục tiêu cuối cùng: giảm thiểu làm lại, tối đa hóa cộng tác, thúc đẩy phát triển cá nhân
Cộng tác với tác nhân AI: Vai trò mới của người dẫn dắt nhóm
- Các tác nhân coding dựa trên LLM thế hệ mới giống như một junior developer cực nhanh
- Không giống junior truyền thống, LLM có hai khác biệt rõ rệt là không có khả năng tự học và không bị giới hạn về tốc độ
- AI tiếp tục tập trung vào tăng tốc độ hơn là cải thiện chất lượng, đồng thời thiếu sự thấu hiểu về ngữ cảnh và domain của con người
- Có hai mô hình cộng tác:
- Kỹ thuật phần mềm dựa trên AI: hướng tới teamwork hiệu quả và bền vững dù chậm hơn
- Vibe coding: tập trung cho ra kết quả nhanh, nhưng dần tích lũy sự hỗn loạn không thể cứu vãn
- Điều này rất giống điểm mù truyền thống của sự tăng trưởng mã ở Thung lũng Silicon: sau lợi ích ngắn hạn sẽ chạm tới bức tường giới hạn tăng trưởng
Cách thực tế để sống sót trước cạm bẫy AI coding
- LLM không hiểu tình huống riêng của chính nó và sản sinh mã một cách thiếu chọn lọc
- Kỹ sư cần cung cấp cho AI cấu trúc, tiêu chuẩn và quy trình rõ ràng để chuyển đầu ra thô sơ thành dịch vụ thực tế
- Cần một playbook mới để áp dụng sát sao các best practice của vòng đời phát triển truyền thống vào môi trường cộng tác với AI
- Cách tận dụng AI theo từng bước chính:
- Định nghĩa đặc tả: phân tích edge case, tập trung vào phạm vi mục tiêu
- Tài liệu hóa: bảo đảm có hướng dẫn và bằng chứng có thể tái sử dụng
- Thiết kế mô-đun: nâng cao mức độ hiểu thông qua việc giới hạn ngữ cảnh
- Phát triển hướng kiểm thử: tạo test case trước khi triển khai, ngăn ngừa hồi quy
- Tiêu chuẩn coding: duy trì phong cách và chất lượng
- Giám sát: tự động phân tích log và rút ra insight
Kết luận
- Phân phối phần mềm không chỉ được tạo nên bởi việc viết mã, mà còn đòi hỏi phải xây dựng một cấu trúc cộng tác hiệu quả giữa AI và con người
- Cần xem LLM như một junior developer siêu tốc, đồng thời áp dụng các quy trình phát triển đã được kiểm chứng để có thể cung cấp phần mềm chất lượng cao có khả năng mở rộng
2 bình luận
Ý kiến Hacker News
Tôi muốn thấy những lập luận phản đối AI không chỉ dựa trên kiểu nói đơn giản rằng “công nghệ làm con người lười biếng”. Ai đã nghiêm túc thử tạo mã bằng LLM đều sẽ cảm nhận rằng vòng lặp lập kế hoạch-cấu trúc-kiểm thử-hồi tưởng vẫn cực kỳ quan trọng. Nếu cứ chạy bừa mà không cẩn thận thì rất dễ hỏng ngay. Khi áp dụng tốt vòng lặp này, tôi có thể dành nhiều thời gian cho việc thiết kế kiến trúc mà mình thích và kiểm thử trải nghiệm đầu ra. Vì LLM xử lý nhanh các phần dễ, thứ cuối cùng còn lại cho chúng ta lại là những việc kém thú vị và ít được ghi nhận hơn. Trong những lĩnh vực mà AI làm nổi bật chuyên môn, sự khác biệt quan điểm giữa người thích bản thân công việc và người thích trải nghiệm suy nghĩ hiện ra rất rõ. Người thích suy nghĩ có thể nhờ AI mà gần như tập trung hoàn toàn vào phần đó. Ngược lại, với người thích tự tay gõ và thao tác, AI lại lấy mất phần họ yêu thích
Về chuyện sinh mã bằng AI, tôi cho rằng phê bình quan trọng hơn không phải là công nghệ làm con người lười đi, mà là nó lấy mất sự hiểu biết sâu về đoạn mã do AI tạo ra. Cốt lõi của kỹ sư phần mềm không phải là tạo ra mã, mà là thiết kế toàn bộ hệ thống. Điều quan trọng ở đây là mô hình tư duy về cách mã hoạt động và chuyên môn miền, còn mã chỉ là kết quả phát sinh từ mô hình tinh thần đó. Với dự án đạt đến một quy mô nhất định, nếu không phải chính tác giả trực tiếp viết mã thì rất khó hiểu hoàn toàn đoạn mã ấy. Nếu không xây dựng được mô hình tinh thần này, các vấn đề khác cũng sẽ kéo theo. Các tác nhân lập trình dựa trên LLM có giới hạn trong suy luận ở mức cú pháp nên bộc lộ điểm yếu về khả năng mở rộng
Nói về quan điểm của tôi, tôi có dùng các công cụ AI như Cline thỉnh thoảng, nhưng ngày càng gõ mã trực tiếp nhiều hơn. Lý do là trong đa số trường hợp, nó chỉ thay việc lập trình bằng việc viết prompt. Nếu thời gian viết prompt và suy luận ngắn hơn thời gian tôi tự tay viết mã thì tôi dùng AI, nhưng thường điều này chỉ đúng khi bị giới hạn tốc độ ở các việc như refactor. Trong hầu hết công việc, tự làm mất 10 phút, còn dùng AI thì viết prompt, chạy, rồi mất 8 phút. Nếu mọi thứ chạy tốt không lỗi thì tiết kiệm được 2 phút, nhưng nếu phải sửa hay prompt lại thì ngược lại thành 10~12 phút, lại còn tốn credit AI nên là tệ nhất. Càng tính kiểu này, tôi càng đi đến kết luận rằng xét cả chất lượng mã lẫn thời gian bỏ ra thì làm thủ công an toàn hơn
Về lập luận rằng công nghệ khiến con người bất cẩn hơn, nhìn chung cũng có nhiều trường hợp công nghệ khiến con người cẩn trọng hơn. Vấn đề là công nghệ AI này có khả năng cao dẫn người dùng đến sự bất cẩn. Điều tôi quan tâm không phải phần thú vị của việc viết mã, mà là bản thân thiết kế (kiến trúc). Nếu có thể phản ánh ý định trực tiếp thành mã thì tôi sẽ dùng cách đó. Nhưng giao diện chatbot truyền đạt ý định một cách gián tiếp và không hoàn chỉnh, nên khi dùng nó cho việc xây dựng mã cấp cao, mô hình trong đầu tôi và hiểu biết về mã thực tế nhanh chóng tách xa nhau, để lại một nền móng thiếu ổn định. Có thể rà soát kỹ từng dòng, nhưng như vậy lại đi ngược mục đích của công cụ. Lập trình bằng AI, vì cảm giác “nhanh hơn 10 lần”, đã khuyến khích khoảng cách giữa chi tiết triển khai và hiểu biết ở tầm vĩ mô. Trên thực tế, suy nghĩ ít hơn về phần cấu trúc chính là lợi ích lớn được dùng để quảng bá AI coding, nhưng khoảng cách hiểu biết này sẽ gây vấn đề về sau. Tự động hóa tốt thì đáng tin cậy và có thể dự đoán, nên chỉ cần hiểu các bất biến ở tầng trên là đủ, nhưng mã chatbot không cho bảo đảm đó nên cuối cùng tạo ra cấu trúc buộc phải kiểm chứng mọi thứ thủ công. Ở đây, an toàn và độ tin cậy lại trở nên khó đạt được hơn
Tôi thấy logic “hãy tập trung vào phần suy nghĩ” xuất hiện quá thường xuyên đến mức giờ đã thành sáo mòn. Vấn đề là, tôi nghi ngờ liệu một người chưa trực tiếp làm việc thực tế nhiều năm có thể chỉ bằng suy nghĩ mà thực hiện được những hoạt động đủ chiều sâu hay không. Cuối cùng, nếu không có trải nghiệm tự tay làm, ngay cả việc suy nghĩ cũng có nguy cơ ngày càng nông đi
Quan điểm của tôi là, vì debug còn khó hơn viết, nên thay vì debug đoạn mã tôi không viết thì tự viết còn hơn
Mỗi lần đọc những tranh luận như thế này tôi lại nghĩ, không biết tác giả có đang dùng cùng bộ công cụ với tôi không. Với Claude Code, tôi có thể tạo ra gần như mọi thứ, từ boilerplate đơn giản đến thuật toán phức tạp, ngay cả trong những codebase lớn rất rối. Tất nhiên không đúng 100%, nhưng rất sát. Hơn nữa, nó còn thường đề xuất những thuật toán mà tôi chưa nghĩ tới. Những công cụ này giúp tôi tiết kiệm thời gian ít nhất 10 lần
Bài này ổn, nhưng tôi thấy có hai giả định sai. Thứ nhất, ngay cả khi một lập trình viên giàu kinh nghiệm dùng LLM thì vẫn cần khám phá đầy đủ, suy nghĩ trước và thiết kế. Thậm chí để tận dụng LLM đúng cách, tôi còn phải suy nghĩ nhiều hơn bình thường, so sánh nhiều phương án thiết kế và phác họa toàn bộ cấu trúc. Trước đây tôi không tài liệu hóa quá trình này, nhưng giờ tôi để lại thành tài liệu thiết kế. Thứ hai là lập luận rằng LLM giống một lập trình viên junior không phát triển, trong khi hai thứ hoàn toàn khác nhau. Nhân viên mới là con người còn LLM là công cụ. Người ta hay nói rằng làm việc với junior thì tích lũy được giá trị theo thời gian còn với LLM thì không, nhưng điều đó cũng không đúng. Dù LLM không học, tôi lại học cách thuần hóa nó hiệu quả hơn và tận dụng nó tốt hơn nhiều. Vì đây vẫn là giai đoạn đầu của việc áp dụng LLM tốt vào sản phẩm, nên đương nhiên có thể thấy giá trị tăng trưởng phức hợp
Tôi đồng ý với ý “dù LLM không học thì tôi vẫn học”, nhưng vẫn mong LLM thật sự học được từ tương tác với người dùng. Điều tôi muốn là có thể lưu/tải nội dung phiên làm việc thành tệp để LLM hiểu trọn vẹn toàn bộ ngữ cảnh đã học trước đó mà không thiếu gì. Một số UI frontend có thể lưu/khôi phục phiên, nhưng điều quan trọng là a) kiểu “học lại” này không nên ảnh hưởng đến context window hiện tại của LLM (thực ra tôi còn mong khái niệm này biến mất luôn), và b) phải là cách hoàn toàn không mất mát. Các phương pháp như tóm tắt rồi tiếp tục, hay RAG, đã xuất hiện, nhưng tất cả đều có giới hạn căn bản như mất thông tin hoặc chỉ khôi phục được khi tương tác hiện tại kích hoạt nó. Ví dụ, hôm qua tôi đã nhờ LLM giải thích về một hàm nào đó rồi lưu phiên, đến hôm nay sau khi khôi phục phiên, ngay cả khi tôi hỏi một câu chẳng liên quan gì thì tôi vẫn muốn LLM trả lời có tính đến cả ngữ cảnh cũ. Đồng thời, cũng cần có cách để khi muốn thì có thể chủ động bắt đầu lại từ đầu (clean slate)
Đúng vậy. Vì trong năng suất tổng thể của phát triển phần mềm, thời gian suy nghĩ chiếm tỷ trọng lớn hơn rất nhiều so với thời gian thật sự viết mã, nên dù LLM tăng tốc phần coding thì cũng không tạo ra thay đổi quá kịch tính trong năng suất tổng thể hay nhu cầu nhân lực
Bắt đầu bằng prompt
DO NOT WRITE ANY CODE YETcũng là mặc định của tôi. Đó là cách để trước tiên hiểu LLM định làm gì và giữ quyền kiểm soát trong tay mình. Với tôi, bản thân thiết kế như logic/giải quyết vấn đề/tích hợp hệ thống thú vị hơn việc viết mãCó những tính năng cho phép chỉ lập kế hoạch mà không sửa file mã, như chế độ Ask của Copilot hay chế độ Plan/Chat của GPT-5 Codex. Tôi đã dùng Codex vài ngày, và nếu đưa chỉ dẫn đủ đầy thì nó rất xuất sắc
Tôi cũng đa phần thích hỏi LLM kế hoạch trước khi thực thi cụ thể, kiểu như “hãy nói kế hoạch trước”
Bài này viện dẫn tài liệu marketing của Microsoft để nói năng suất tăng 10%, nhưng trong nghiên cứu của Harvard thì thực tế lại ghi nhận giảm năng suất 10%. Tôi muốn thấy những bài trước hết trích dẫn các kết quả nghiên cứu độc lập, thay vì quảng bá từ một công ty cụ thể
Một trong những điểm cốt lõi mà bài này không truyền tải đầy đủ là tôi đồng tình với ý của Casey Muratori rằng “nếu bạn lập trình với tư duy lấy học tập làm trung tâm thì AI lại gần như vô nghĩa”. Cá nhân tôi thấy các trình sinh mã AI chỉ hữu ích cho loại mã dùng một lần rồi bỏ. Ở những lĩnh vực tôi thực sự muốn học nghiêm túc, tôi cảm thấy không giao việc sinh mã cho AI mới tối đa hóa hiệu quả học tập. Chắc chắn vẫn có những người thấy “AI-driven engineering” là có ý nghĩa, nhưng ít nhất với tôi, tự tay viết các khối mã vẫn thú vị hơn và cuối cùng cũng cho cảm giác hoàn thiện kết quả tốt hơn. Video liên quan, dài 5 phút
Từ khi dùng Claude Code, tôi dành nhiều thời gian suy nghĩ hơn hẳn. Trước đây tôi không bao giờ mô tả tính năng muốn làm trong 400~600 từ, còn giờ tôi sắp xếp nhiều thông tin hơn và suy nghĩ kỹ hơn. Nhờ những cân nhắc này mà kết quả nhanh hơn và tốt hơn, nhưng đồng thời mức độ hiểu mã của tôi cũng có phần thấp hơn trước. Tuy vậy, tôi không thể đồng ý với lập luận rằng các lập trình viên có kinh nghiệm sẽ bớt suy nghĩ khi dùng Claude Code. Có lẽ nhiều người đang dùng tác nhân theo cách kém hiệu quả, gần như chỉ viết prompt chẳng hạn, nhưng tôi không cho đó là lỗi của tác nhân
Nhìn những cuộc thảo luận này, tôi nghĩ hiện giờ vẫn là một giai đoạn chuyển tiếp khá mơ hồ. Có lẽ khoảng năm sau, những tranh luận như hôm nay sẽ bị xem như kiểu “nghĩ quá nhiều”. Nó giống giai đoạn trước và sau khi Internet phổ cập, khi có rất nhiều nghi ngờ kiểu “mốt nhất thời” hay “đầu tư sai lầm”
Điều những bài như thế này thường bỏ sót là như sau
Tôi mong có một bài viết chỉ hệ thống hóa các ưu/nhược điểm và đánh đổi của công cụ hỗ trợ viết mã bằng AI. Cần thảo luận mà bỏ qua phán xét đạo đức (tốt/xấu). Tôi thừa nhận rằng khi “kỹ năng lập trình” là một phần bản sắc của bản thân thì đặc biệt khó tiếp cận vấn đề này một cách lạnh lùng
Mỗi ngày tôi đều tự động viên “cố thêm 30 năm nữa rồi nghỉ hưu”. Đã 10 năm trong lĩnh vực machine learning, tôi mệt với việc ngồi trước máy tính và cũng mệt với công việc. Tôi chỉ muốn lăn ra bãi cỏ thôi
Biểu đồ “suy nghĩ & code vs suy nghĩ & sửa” khá thú vị. Gần đây dùng Codex, tôi thực sự kỳ vọng AI sẽ khiến nó sửa mã của tôi rất nhiều. Nhưng trên thực tế, thời gian lại bị tiêu tốn khủng khiếp khi nguyên nhân vấn đề hoàn toàn không liên quan tới mã. Gần đây tôi đã mất rất lâu chỉ để đào bới phần mã vì vấn đề xác thực, cuối cùng mới phát hiện nguyên nhân là lỗi cấu hình ipv6 của VM
Tôi rất đồng cảm. Khi dùng AI để lập trình, công việc hậu xử lý quá nhiều nên việc đưa vào vận hành trong kinh doanh thực tế và bảo trì rất vất vả.
Ngay cả khi làm với góc độ là cùng phát triển và cố gắng trao đổi qua lại thật nhiều để triển khai, vì một phần mã không phải do mình trực tiếp viết nên cũng thường có lúc nó bị bay khỏi đầu.
Tôi nghĩ việc đặt ra ranh giới là điều chắc chắn cần thiết.