- Khi các công cụ lập trình AI tự động hóa việc viết mã, vốn là công việc dễ, một vấn đề mang tính cấu trúc xuất hiện: lập trình viên chỉ còn lại những việc khó như nghiên cứu, nắm bắt ngữ cảnh và xác minh
- Hiện tượng lập trình viên không tự hiểu trực tiếp đầu ra của AI mà nói rằng "AI đã làm thay" là một tín hiệu rủi ro tương tự việc sao chép-dán từ StackOverflow trước đây
- Vibe coding hữu ích cho việc tạo prototype, nhưng trong môi trường production thực tế, có những lúc AI không tiết kiệm thời gian mà còn khiến tốn thời gian hơn
- Nhờ AI mà một lần triển khai nhanh được thực hiện, nó sẽ trở thành đường cơ sở mới, dẫn đến áp lực sprint liên tục và burnout như một vấn đề quản lý
- Điều cốt lõi là sử dụng AI như một công cụ nghiên cứu chứ không phải nhà cung cấp giải pháp, và lập trình viên phải duy trì trách nhiệm đối với toàn bộ mã
Vấn đề của câu nói "AI đã làm thay"
- Trước đây, các lập trình viên đọc câu trả lời trên StackOverflow, bài viết hoặc issue trên GitHub rồi tự xác minh ngữ cảnh và rút ra kết luận
- Không ai nói rằng "Google đã viết code giúp tôi" hay "kết quả đứng đầu tìm kiếm nên chắc là đúng"
- Gần đây bắt đầu xuất hiện cách diễn đạt "AI đã làm thay"
- Điều này либо phóng đại những gì thực sự đã xảy ra, либо có nghĩa là lập trình viên không tự mình đưa ra kết luận
- Cả hai trường hợp đều có vấn đề, và làm dấy lên cùng mối lo như khi sao chép-dán mã từ StackOverflow: bạn có thực sự hiểu đoạn mã đã dán vào hay không
Giới hạn của vibe coding
- Vibe coding lúc đầu rất thú vị và hữu ích cho prototyping hoặc các dự án cá nhân rủi ro thấp
- Nhưng trong công việc thực tế, mọi dòng mã đều kéo theo hệ quả
- Trong một dự án cá nhân, khi yêu cầu AI agent thêm test vào một file cụ thể, file từ 500 dòng bị rút xuống còn 100 dòng
- AI khẳng định rằng nó không xóa nội dung khác, rồi sau đó lại nói file đó vốn chưa từng tồn tại
- Khi được cho xem git history, nó xin lỗi và thừa nhận lẽ ra phải kiểm tra sự tồn tại của file trước
- Trong trường hợp này, hỗ trợ của AI không tiết kiệm thời gian mà còn tiêu tốn nhiều thời gian hơn
- Tranh cãi với agent và khôi phục file mất nhiều thời gian hơn là tự viết test trực tiếp
- Nếu điều tương tự xảy ra trong một môi trường như codebase y tế, hậu quả có thể rất nghiêm trọng
- Điều quan trọng là sử dụng AI như một công cụ nghiên cứu chứ không phải nhà cung cấp giải pháp, và để nhận ra khi nào AI sai thì cần có sự rèn luyện
Cấu trúc khiến phần khó càng khó hơn
- Việc viết code vốn dĩ là phần dễ trong công việc phát triển phần mềm
- Phần khó là nghiên cứu, hiểu ngữ cảnh, xác minh giả định và biết vì sao một cách tiếp cận cụ thể là đúng
- Khi giao phần dễ cho AI, công việc không hề giảm đi, mà chỉ là chỉ còn lại những việc khó
- Nếu bỏ qua khâu nghiên cứu chỉ vì AI đã đưa ra câu trả lời, thì bản thân ngữ cảnh để đánh giá đầu ra của AI cũng không còn
- Đọc và hiểu code của người khác là công việc khó hơn rất nhiều so với tự viết code
- Code do AI tạo ra về bản chất là code của người khác
- Tức là giao phần mà lập trình viên làm tốt (viết) cho máy, và chỉ để lại phần khó hơn (đọc, review)
- Một tình huống phải chỉ review mà không có ngữ cảnh tích lũy được trong quá trình tự viết
Kỳ vọng sprint và burnout
- Một khi đã có lần triển khai nhanh nhờ AI hỗ trợ, nó sẽ trở thành đường cơ sở mới và người ta sẽ luôn đòi hỏi cùng tốc độ đó
- Cuộc trò chuyện chuyển từ "Làm sao bạn làm được thế?" sang "Sao lần nào bạn cũng không làm được như vậy?"
- Đây không phải vấn đề kỹ thuật mà là vấn đề quản lý
- Kỹ sư kiệt sức sẽ bỏ sót edge case, bỏ qua test và phát hành bug
- Nhiều incident hơn → nhiều áp lực hơn → nhiều sprint hơn, tạo thành vòng luẩn quẩn
- Trước tuyên bố "AI tạo ra năng suất gấp 10 lần", thực tế có thể chỉ là một kỹ sư 0.1x trở thành 1x
- Về mặt kỹ thuật có thể là 10x, nhưng câu hỏi cốt lõi là đó có thực sự là tăng năng suất hay chỉ là phơi bày việc trước đây đã nghiên cứu quá ít
- Burnout và việc phát hành code chất lượng thấp sẽ triệt tiêu phần năng suất mà AI mang lại
Kỹ năng senior, độ tin cậy junior
- AI coding agent có khả năng viết code ở mức senior, nhưng mức độ tin cậy với đầu ra của nó phải được xem như một kỹ sư junior
- Code trông có vẻ tốt và có lẽ sẽ chạy, nhưng vì thiếu kinh nghiệm nên cần kiểm tra kỹ hơn
- Có thể ví AI coding agent như một người có khả năng đọc cực nhanh bỗng gia nhập nhóm
- Nó có thể hỗ trợ nghiên cứu và viết code, nhưng lại không tham dự các cuộc họp đã bàn về bối cảnh quan trọng của tuần trước
Tầm quan trọng của quyền sở hữu mã
- Lập trình viên phải có quyền sở hữu mang tính trách nhiệm không chỉ với code do mình trực tiếp viết mà còn với code do AI tạo ra
- Nếu vì mục tiêu tốc độ phi thực tế mà sao chép-dán đầu ra của AI, vấn đề sẽ xuất hiện khi một thành viên mới của nhóm cố hiểu đoạn code đó sau 6 tháng hoặc khi có sự cố lúc 2 giờ sáng
- Câu nói "AI viết đấy" không giúp ích trong bất kỳ tình huống nào
AI có thể giúp phần khó bằng cách nào
- Ví dụ bug production: ngay sau một đợt phát hành lớn, người dùng báo cáo một bug edge case ở phần hiển thị múi giờ
- Lập trình viên phụ trách phải đi học sau 30 phút, còn những người khác thì đã tan làm
- AI được dùng để tiến hành nghiên cứu, chỉ ra đây là bug dựa trên các thay đổi gần đây và giải thích cách tái hiện lỗi
- Nguyên nhân là một số phương thức deprecated được áp dụng ưu tiên hơn các phương thức nhận biết múi giờ hiện tại, khiến việc chuyển đổi múi giờ không diễn ra chính xác
- Trong vòng 15 phút, nguyên nhân gốc rễ, ý tưởng giải pháp và ghi chú điều tra đã được tổng hợp vào issue trên GitHub
- Lập trình viên phụ trách xác nhận bản sửa, và một thành viên khác trong nhóm hoàn tất việc test và triển khai
- Sự việc được giải quyết mà không có tình huống khẩn cấp, cũng không cần tăng ca
- Điểm cốt lõi mà ví dụ này cho thấy: AI thực hiện các công việc lặp lại trong quá trình điều tra, còn con người cung cấp ngữ cảnh và xác minh theo một cấu trúc cộng tác
- AI nên được sử dụng để tăng cường nghiên cứu, xác minh và hiểu ngữ cảnh; nếu không, phần dễ sẽ càng dễ hơn còn phần khó sẽ càng khó hơn như một cấu trúc bị cố định
3 bình luận
> AI không làm việc phát triển trở nên khó hơn
> Ngược lại, nó phơi bày những phần thực sự khó mà bấy lâu nay mọi người vẫn phớt lờ
> Trong 15 năm qua, các lập trình viên thực ra đã làm “phiên bản vibe coding của con người” — copy-paste từ Stack Overflow, refactor không có kế hoạch, và làm việc theo kiểu “chỉ cần chạy tốt trên laptop của tôi là được”
> Giờ AI làm điều đó, thì đột nhiên ai cũng muốn lập kế hoạch và viết test
> Nếu chất lượng được cải thiện dù có chậm lại, thì đó mới là tiến bộ thật sự
Theo tôi thấy, những lập trình viên trước giờ chỉ sao chép rồi dán thì dù dùng LLM vẫn chỉ sao chép rồi dán
Còn những lập trình viên vốn đã rất chú trọng đến chất lượng thì dường như lại càng chú trọng hơn
Ý kiến trên Hacker News
Việc lập trình cùng các công cụ hỗ trợ AI là một kỹ năng mới hoàn toàn khác với kiểu lập trình lấy con người làm trung tâm trước đây
Ngôn ngữ, framework và các nguyên tắc phát triển mà chúng ta có được tạo ra để vượt qua giới hạn của con người, còn AI thì có những giới hạn khác
Khi giải quyết các vấn đề phức tạp, thay vì chỉ đưa prompt và nhận kết quả, quá trình khám phá không gian vấn đề thông qua đối thoại và thiết kế lặp lại hữu ích hơn
Lỗi hay ảo giác của AI ngược lại còn đóng vai trò như tín hiệu cho biết liệu tôi có thực sự hiểu đúng vấn đề hay không
Tôi đã thử tạo một trình giả lập retro và assembler theo kiểu vibe coding, và chỉ với prompt tối thiểu vẫn cho ra kết quả tốt
Nhưng khi thử phần độc quyền của một ứng dụng công nghiệp cụ thể mà trước đây tôi từng làm, thì dù prompt thế nào kết quả cũng rất tệ
Có hàng nghìn ví dụ về emulator trên GitHub, nhưng thứ tôi định làm thì hoàn toàn không có ví dụ nào
Kết luận rất đơn giản — có thứ thì dễ, có thứ thì hoàn toàn không làm được
Nếu có nhiều ví dụ trên GitHub thì chúng cũng tồn tại trong latent space của LLM, nên lúc nào cũng có thể lôi ra được
Thứ bạn thử chỉ đơn giản là không có ví dụ như vậy
Framework chuyên biệt cho từng ngành thì khó xử lý bằng vibe coding, nhưng nếu đơn giản hóa vấn đề thì AI giúp nhanh hơn rất nhiều
Nếu chấp nhận hoàn toàn vibe coding thì có thể tạo ra kết quả ấn tượng, nhưng nợ kỹ thuật sẽ phình quá lớn, đến mức có cảm giác trở thành nô lệ của cỗ máy
Khi AI viết thay hàng nghìn dòng mã, việc hiểu cấu trúc hay review nó trở nên cực kỳ khó khăn
Có vẻ cuối cùng mã và phần mềm dùng một lần sẽ tăng lên — ứng dụng giải quyết bài toán cụ thể thì dễ làm, nhưng với SaaS bền vững thì rủi ro rất lớn
AI là công cụ tạo ra hiệu ứng nhân lực mạnh mẽ (force multiplier)
Nếu nền móng của codebase tệ thì AI cũng sẽ sao chép nguyên kiểu đó
Ngược lại, nếu có nền tảng sạch sẽ và nhất quán thì AI có thể giữ được chất lượng đó và hoạt động tốt đến đáng ngạc nhiên
Cuối cùng, điều cốt lõi vẫn là nền móng thiết kế (foundation)
Phần lớn codebase đều có cấu trúc khó bảo trì và khó mở rộng, nên AI chỉ làm lộ rõ hơn những vấn đề đó
Cũng như trong xây dựng, nếu móng yếu thì công cụ tốt đến đâu cũng có giới hạn
Làm vậy giúp cả các lập trình viên đến sau cũng có thể hiểu đầy đủ ngữ cảnh (context) của dự án
Cuối cùng vẫn phải sửa đúng các trừu tượng cốt lõi trước thì AI mới hoạt động tử tế
Yêu cầu luôn thay đổi và các thỏa hiệp xuất hiện vì hiệu quả
Cuối cùng thời gian và chi phí cơ hội lại được ưu tiên hơn chất lượng — vì con người không thể bám sát kế hoạch một cách hoàn hảo
AI làm cho những phần phiền phức bớt phiền phức hơn
Nhưng tranh cãi với LLM là lãng phí thời gian
Thay đổi theo đơn vị nhỏ, nếu ổn thì commit, không ổn thì bỏ và thử lại sẽ hiệu quả hơn
AI không phải vạn năng, và chọn đúng công cụ là điều quan trọng
Nếu định chơi với một đứa trẻ cầm súng thì phải mặc áo chống đạn
Câu “đọc code của người khác khó hơn viết” xuất hiện rất thường xuyên, nhưng tôi thấy điều đó kỳ lạ
Một hàm mà tôi phải mất nửa ngày để viết thì chỉ cần 10–15 phút để đọc và review
Việc xác minh mã đúng dễ hơn rất nhiều so với việc tạo ra nó
Chỉ đọc thì dễ, nhưng hiểu cấu trúc và tìm ra điểm cần cải thiện trong lúc chỉnh sửa lại tốn công hơn nhiều
Vì ngữ cảnh (context) ở thời điểm viết đã biến mất
Thực ra không phải đọc khó hơn, mà là mọi người thích viết mới hơn
Cách nghĩ đúng nên là: “AI làm mọi thứ dễ hơn, nhưng bản thân nó là một kỹ năng mới và rất khó học”
Hiện tại đây là thời ENIAC của AI, khi các khái niệm tương đương ngôn ngữ bậc cao hay hệ điều hành vẫn chưa tồn tại
Trong tương lai sẽ xuất hiện một ngành gọi là context engineering, và cách làm hiện nay sẽ trông rất nguyên thủy
Nếu tổ chức cấu trúc tốt, năng lực của AI trông gần như vô hạn
Nói “làm bằng AI” thực chất gần như đồng nghĩa với “đã tiêu tốn một lượng lớn tài nguyên CPU của công ty bên ngoài”
Cho đến khi tôi có một AI agent do tôi sở hữu hoàn toàn, tôi nghĩ đó gần với hành vi ăn cắp tài nguyên ở quy mô hành tinh hơn là tiến bộ thực sự
AI không làm việc phát triển trở nên khó hơn
Ngược lại, nó phơi bày những phần thực sự khó mà con người bấy lâu nay vẫn lờ đi
Suốt 15 năm qua, các lập trình viên vốn đã làm kiểu “vibe coding phiên bản con người” — copy-paste từ Stack Overflow, refactor không kế hoạch, và làm việc theo kiểu “chạy trên laptop của tôi là được”
Giờ AI làm điều đó thì đột nhiên mọi người lại muốn lập kế hoạch và viết test
Nếu có chậm hơn nhưng chất lượng được cải thiện thì đó mới là tiến bộ thật sự
Văn hóa ‘nước rút trong một cuộc marathon’ hiện nay đang bị AI làm tăng tốc thêm
Nhưng nếu dùng AI mà không có giám sát thì nó nhanh chóng đi chệch hướng, và việc đọc code do người khác viết mệt hơn rất nhiều so với sửa code của chính mình
Khi tôi bảo AI “hãy thêm test vào file này”, thì file dài 500 dòng bị rút còn 100 dòng
Khi hỏi lý do, nó trả lời rằng “vì file gốc không tồn tại”
Tôi đưa cho nó lịch sử git, nó xin lỗi và nói rằng “lẽ ra tôi nên kiểm tra sự tồn tại trước”
Hôm qua tôi bảo “hãy quên file đó đi”, thì nó thật sự xóa luôn file đó
Một chút chi phí hoàn tác vẫn đáng chấp nhận so với giá trị mà AI mang lại