- vibe coding và agentic engineering vốn được phân biệt dựa trên tiêu chuẩn rà soát mã và trách nhiệm, nhưng khi độ tin cậy của các coding agent tăng lên, ranh giới này đang mờ dần trong công việc production thực tế
- vibe coding là cách làm hầu như không xem mã, chỉ cần ra kết quả mong muốn thì chấp nhận, nên có thể hữu ích với công cụ cá nhân, nhưng lại có vẻ là một cách làm thiếu trách nhiệm đối với phần mềm liên quan đến dữ liệu và trải nghiệm của người khác
- Các agent như Claude Code liên tục xử lý tốt JSON API endpoint, truy vấn SQL, kiểm thử và tài liệu hóa, dẫn tới việc không còn rà soát từng dòng mã được sinh ra, và điều này tạo nên rủi ro của việc đặt niềm tin vào một thực thể không có danh tiếng hay trách nhiệm như một đội ngũ con người
- Giờ đây có thể tạo ra một kho mã với 100 commit, README tốt và bộ kiểm thử đầy đủ chỉ trong 30 phút, nên ngày càng khó đánh giá chất lượng chỉ qua bề ngoài; tiêu chí thực sự là liệu ai đó đã sử dụng phần mềm đó một cách liên tục hay chưa
- Công cụ AI không thay thế kinh nghiệm của kỹ sư phần mềm mà khuếch đại nó; khi tốc độ sản xuất mã tăng từ 200 dòng mỗi ngày lên 2.000 dòng, nút thắt sẽ chuyển sang thiết kế, kiểm chứng, vận hành và việc sử dụng thực tế
Ranh giới giữa vibe coding và agentic engineering
- Trong podcast Heavybit High Leverage Ep. #9 về công cụ AI coding, tôi nhận ra rằng vibe coding và agentic engineering đang tiến gần nhau hơn trong công việc thực tế
- Trước đây, trong Not all AI-assisted programming is vibe coding (but vibe coding rocks), tôi từng phân biệt rõ vibe coding với lập trình có hỗ trợ AI theo cách có trách nhiệm, và sau đó bắt đầu gọi cách thứ hai là agentic engineering
- vibe coding được hiểu là cách làm hầu như không xem mã, người dùng thậm chí có thể không biết lập trình, chỉ yêu cầu kết quả mong muốn rồi nếu chạy được thì chấp nhận, nếu không thì yêu cầu lại
- Với công cụ cá nhân, nơi lỗi chỉ gây hại cho chính mình, vibe coding có thể hữu ích; nhưng khi làm phần mềm liên quan đến dữ liệu và trải nghiệm của người khác, nó trông như một cách làm thiếu trách nhiệm
- agentic engineering là cách một kỹ sư phần mềm chuyên nghiệp tận dụng tối đa công cụ AI trong khi vẫn hiểu rõ các ràng buộc như bảo mật, khả năng bảo trì, vận hành và hiệu năng
- Mục tiêu không phải là tạo ra kết quả chất lượng thấp nhanh hơn, mà là xây dựng các hệ thống production chất lượng cao hơn nhanh hơn
- Vấn đề là khi các coding agent trở nên đáng tin cậy hơn, người ta bắt đầu không còn rà soát mọi dòng mã được sinh ra ngay cả trong các tác vụ ở mức production
Niềm tin khiến việc rà soát mã bị bỏ qua
- Khi yêu cầu Claude Code tạo một JSON API endpoint, chạy truy vấn SQL và xuất kết quả dưới dạng JSON, tôi bắt đầu tin rằng nó sẽ xử lý đúng
- Ngay cả khi bảo nó thêm kiểm thử tự động và tài liệu hóa, tôi cũng kỳ vọng kết quả sẽ ổn, và trong quá trình đó đôi khi không xem kỹ mã thực tế
- Nếu không rà soát mã, vẫn có cảm giác day dứt về việc liệu đem nó vào production có phải là điều có trách nhiệm hay không
- Có thể xem điều này giống với cách làm việc của một engineering manager trong tổ chức lớn khi sử dụng phần mềm do đội khác xây dựng
- Nếu một đội khác cung cấp dịch vụ resize ảnh, thông thường bạn sẽ không đọc mọi dòng mã mà đội đó viết
- Bạn xem tài liệu, thử resize ảnh rồi phát hành tính năng của mình
- Chỉ khi thấy lỗi hoặc vấn đề hiệu năng, bạn mới có thể vào xem kho Git
- Trong phần lớn trường hợp, dịch vụ đó được đối xử như một hộp đen một phần
- Agent cũng đang dần được đối xử theo cách tương tự, nhưng khác với đội ngũ con người, Claude Code không có danh tiếng nghề nghiệp hay trách nhiệm giải trình
- Một đội ngũ con người có thể xây dựng danh tiếng bằng cách từng tạo ra phần mềm tốt, và họ chịu áp lực rằng kết quả tệ sẽ ảnh hưởng đến uy tín chuyên môn của mình
- Claude Code không thể có loại danh tiếng như vậy, nhưng nó vẫn đang tích lũy niềm tin bằng cách liên tục xử lý đúng các tác vụ đơn giản, lặp đi lặp lại theo phong cách ưa thích của tôi
- Điều này có yếu tố normalization of deviance
- Mỗi lần mô hình viết đúng mã mà không bị giám sát chặt, mức độ tin tưởng lại tăng lên
- Đồng thời, nguy cơ quá tự tin đúng vào thời điểm sai lầm và phải trả giá cũng tăng theo
Việc đánh giá phần mềm trở nên khó hơn
- Trước đây, nếu một kho GitHub có 100 commit, README tốt và kiểm thử tự động, người ta dễ kết luận rằng dự án đó đã được đầu tư nhiều công sức và sự cẩn trọng
- Giờ đây có thể tạo một kho Git với 100 commit, README đẹp và bộ kiểm thử bao phủ mọi dòng mã chỉ trong 30 phút
- Những kho như vậy bề ngoài có thể trông giống hệt một dự án được chăm chút lâu dài
- Có thể nó thực sự tốt đến vậy, nhưng nhìn bề ngoài thì khó mà biết được, và chính dự án của bạn cũng gặp vấn đề tương tự
- Tiêu chí tôi coi trọng hơn chất lượng của kiểm thử và tài liệu là liệu có ai đó đã thực sự sử dụng phần mềm đó hay chưa
- Ngay cả một sản phẩm được vibe code tạo ra, nếu người làm đã dùng nó mỗi ngày trong hai tuần qua, thì vẫn giá trị hơn rất nhiều so với thứ bị đẩy ra mà gần như chưa được chạy thử
Nút thắt chuyển từ viết mã sang các giai đoạn khác
- Khi từ chỗ tạo được 200 dòng mã mỗi ngày chuyển sang 2.000 dòng, các phần khác của vòng đời phát triển phần mềm bắt đầu trục trặc
- Vòng đời phát triển phần mềm truyền thống vốn được thiết kế với giả định tốc độ tạo ra chỉ vài trăm dòng mã mỗi ngày
- Sự thay đổi nút thắt không chỉ ảnh hưởng đến các bước ở hạ nguồn mà còn cả các bước ở thượng nguồn
- Trong bài nói của Jenny Wen, cô cho rằng quy trình thiết kế hiện tại dựa trên giả định rằng “phải làm đúng phần thiết kế ngay từ đầu”
- Vì nếu giao cho kỹ sư rồi họ xây sai thứ gì đó suốt 3 tháng thì sẽ là thảm họa
- Do thiết kế dẫn tới công việc triển khai đắt đỏ nên mới cần quy trình thiết kế sâu rộng
- Nhưng nếu việc build không còn mất 3 tháng, thì chi phí của việc làm sai giảm mạnh, và quy trình thiết kế có thể chấp nhận rủi ro nhiều hơn rất nhiều
Vì sao tôi vẫn không cho rằng sự nghiệp kỹ sư phần mềm đã kết thúc
- Việc trò chuyện với agent trông giống như một thứ “moon language” mà phần lớn mọi người khó lòng hiểu nổi
- Một trong những lý do tôi không cho rằng sự nghiệp kỹ sư phần mềm đã kết thúc chỉ vì máy tính giờ có thể tự viết mã là vì những công cụ này khuếch đại kinh nghiệm sẵn có
- Người biết mình đang làm gì có thể di chuyển nhanh hơn rất nhiều khi dùng AI tool cùng lúc
- Càng dùng AI tool, tôi càng liên tục thấy rằng việc tạo ra phần mềm vốn dĩ đã cực kỳ khó
- Dù có trong tay mọi công cụ AI, việc đạt được điều mình muốn làm vẫn rất khó
- Trong một tweet, Matthew Yglesias viết rằng: “Sau 5 tháng, tôi nhận ra mình không muốn vibecode. Tôi muốn các công ty phần mềm được quản lý chuyên nghiệp dùng AI coding assist để tạo ra nhiều sản phẩm phần mềm hơn, tốt hơn và rẻ hơn rồi bán cho tôi,” và tôi đồng ý với điều đó
- Điều này có thể tóm lại bằng phép so sánh rằng bạn có thể tự sửa đường ống trong nhà nếu xem đủ nhiều video YouTube về plumbing, nhưng vẫn thích thuê một thợ ống nước hơn
Rủi ro của SaaS và tự xây trong nội bộ
- Ngay cả với mối đe dọa rằng doanh nghiệp có thể không dùng SaaS mà tự xây giải pháp riêng, tiêu chí ưu tiên phần mềm đã được kiểm chứng qua sử dụng thực tế vẫn được giữ nguyên
- Với dự án cá nhân, tôi ít nhất sẽ ưu tiên công cụ mà chính người tạo ra nó đã dùng trực tiếp trong vài tuần
- Khi chuyển sang phiên bản doanh nghiệp, tiêu chí sẽ là tôi không muốn triển khai một CRM nếu nó chưa được ít nhất hai tập đoàn lớn khác sử dụng thành công trong 6 tháng
- Trước khi chấp nhận rủi ro, tôi muốn một giải pháp đã chứng minh được rằng nó thực sự hoạt động
1 bình luận
Ý kiến Hacker News
Vibe coding và LLM không tạo ra các tổ chức kỹ thuật hay kỹ sư thiếu kỷ luật, mà chỉ làm lộ ra và tăng tốc những vấn đề vốn có
Nhiều kỹ sư có tiêu chuẩn và thực hành viết mã khá lỏng lẻo, thậm chí là không có; nhiều đội ngũ cũng có tiêu chuẩn yếu trong việc triển khai mã lên môi trường vận hành
Đây không phải hiện tượng mới, mà chỉ có nghĩa là các cá nhân và đội ngũ vốn chưa từng tuân thủ tiêu chuẩn trong vòng đời phát triển phần mềm nay dễ tạo ra nhiều mã hơn và hiện thực hóa ý tưởng dễ hơn rất nhiều
Tôi chưa từng thấy đồng nghiệp nào trở thành kỹ sư giỏi chỉ vì họ viết mã nhanh
Những kỹ sư giỏi nhất mà tôi biết là những người chia sẻ cho cả đội các góc nhìn quan trọng dựa trên kinh nghiệm và sự phán đoán cẩn trọng, từ đó dẫn dắt hệ thống theo hướng tốt hơn
“Claude, làm cho tôi một hệ thống đi. Nhưng nhớ làm cho tốt nhé. Cảm ơn!”
Trước đây, khi codebase bắt đầu kháng cự việc phát triển tính năng, người ta sẽ sửa nút thắt ngay trước mắt rồi trì hoãn cho đến điểm kháng cự tiếp theo
Đó là cách vừa làm tính năng vừa refactor ở mức nào đó, nhưng các mô hình tuyến đầu đã đẩy lùi thời điểm “trở thành vấn đề” đó
Vì chúng có thể xử lý một đống mã ở mức nào đó, nên vấn đề thể hiện thành việc LLM tạo thêm regression hoặc bỏ sót thêm yêu cầu, nhưng con người lại ít cảm thấy công việc khó hơn
Rồi đến một lúc mọi thứ vỡ quá nhiều và buộc phải sửa, nhưng cả codebase đã trở thành một lớp phân dạng của những quyết định mà tôi chưa từng đưa ra, nên rất khó gỡ rối
Vì không trực tiếp chỉnh sửa mã, cảm giác bằng trực giác kiểu “nếu thêm theo cách này thì độ căng sẽ rất lớn” cũng biến mất, khiến việc tìm ra đột phá refactor càng khó hơn
Mã lúc nào cũng có thể refactor, và có thể buộc agent viết các mảnh và file nhỏ, có tính mô-đun
Dù do agent viết hay con người viết thì kỹ thuật tốt vẫn là kỹ thuật tốt
Hiện tại con người vẫn cần ít nhất là hiểu và dẫn dắt kiến trúc, còn agent có thể hỗ trợ cực tốt trong việc trinh sát và đề xuất
Trừ khi tôi đã bỏ lỡ bước tiến nào đó trong vài tuần qua, có vẻ không phải AI đáng tin hơn mà là lỗi đã trở nên tinh vi hơn
Nếu mã không biên dịch được thì rất dễ tìm, và nếu biên dịch được nhưng không chạy thì cũng tương đối dễ phát hiện
Nhưng nếu nó biên dịch được, chạy được, chỉ sai ở vài điều kiện biên, hoặc có lỗ hổng bảo mật, hoặc kéo theo nợ kỹ thuật và các quyết định kiến trúc đáng ngờ thì sẽ khó phát hiện hơn nhiều, và gánh nặng review hoàn toàn không giảm
Thậm chí mã trông có vẻ hợp lý còn tạo gánh nặng tinh thần khi review hơn cả mã rõ ràng là tệ
Chỉ cần cho nó viết nhiều test trước, kiểm tra xem mã có đáp ứng chúng không, và yêu cầu agent tổ chức mã đúng cách
Nhưng hiện tại sức nóng từ trên xuống quá lớn, bầu không khí là phải áp dụng rộng khắp ở mọi nơi, và nếu phản đối thì vừa rất nản vừa bị hạn chế về sự nghiệp, khiến tinh thần bị bào mòn
Chỉ ra một vấn đề rõ ràng thì sẽ có bấy nhiêu cách lách được đưa ra, rồi các cách lách đó lại nhanh chóng lộ ra vấn đề khác, sinh thêm những lời giải mới mãi không dứt
Đến một lúc mọi chuyện như thể trở thành công việc chỉ để phục vụ chính cái máy
Ở nhiều công ty, có vẻ mục tiêu thật sự đã mờ đi và thứ còn lại chỉ là bản thân LLM
Tôi không biết những người đang cược tương lai công ty để hiện thực hóa viễn cảnh đó có được bảo đảm một lối thoát êm ái khỏi hậu quả hay không, hay là sự hợp lý đang bị vứt bỏ hoàn toàn
Có thể giảm nhẹ vấn đề bằng các nguyên tắc kỹ thuật lành mạnh, nhưng tôi nghi ngờ rốt cuộc hiệu quả thực tế nằm ở đâu nếu xét theo tải nhận thức, thời gian lập trình viên, tiền bạc và các nguồn lực hữu hạn
Trong câu “điều gì sẽ hỏng khi bạn có thể tạo ra 2.000 dòng thay vì 200 dòng mỗi ngày”, việc dùng số dòng mã làm thước đo đầu ra kỹ thuật là điều đáng xấu hổ
Review 200 dòng và review 2.000 dòng là hai mức khối lượng công việc hoàn toàn khác nhau
Khi viết lại cùng chương trình đó bằng chính đầu óc mình và chỉ dùng ChatGPT như công cụ tìm kiếm và tự động hoàn thành, tôi đạt cùng kết quả với 1.500 dòng
Thành thật mà nói chênh lệch công sức cũng không quá lớn, nhưng cách làm thủ công có thể đã hưởng lợi từ việc phiên bản vibe coding trước đó giúp tôi nghĩ trước mình muốn xây gì
Dùng số dòng mã làm đầu vào cho việc review phần mềm là hợp lý
Vì theo nghĩa đen là phải đọc từng dòng
Chỉ là nó cực tệ nếu dùng như thước đo đơn lẻ cho năng suất lập trình viên, và vấn đề xuất hiện khi người ta cố dùng nó như vậy
Dù vậy, nó vẫn hữu ích vì gần như là chỉ số duy nhất có thể được hiểu trực quan ngay lập tức và so sánh giữa nhiều công ty, đội ngũ, ngôn ngữ và bối cảnh ứng dụng
Ngay cả khi cùng một đội làm trên cùng một sản phẩm, thay đổi 1.000 dòng có thể xong rất nhanh còn sửa một bug 1 dòng có thể cần vài ngày debug
Vì thế rất khó so sánh PR, tính năng hay story point ngoài ngữ cảnh; nếu có một chỉ số năng suất lập trình viên tiêu chuẩn toàn ngành khả thi thì hẳn ai cũng đã dùng, nhưng tôi nghĩ bản chất việc đó là khó
Khi làm các so sánh kiểu này, sẽ hữu ích nếu giả định ngữ cảnh là như nhau
Ví dụ, nếu một đội từng xây một sản phẩm cụ thể của một công ty cụ thể với một stack kỹ thuật và quy trình chất lượng cụ thể, hôm qua tạo N1 dòng, hôm nay dùng AI tạo N2 dòng, thì theo thời gian chênh lệch giữa N1 và N2 sẽ xấp xỉ tác động thực tế
Các nghiên cứu nghiêm ngặt về năng suất phát triển có hỗ trợ AI nhìn chung cũng đo kiểu A/B test bằng cách so sánh PR trước và sau khi dùng AI trong cùng một nhóm
Theo tôi, khác biệt nằm ở chất lượng và độ nghiêm ngặt của pipeline
Vibe coding là làm một hoặc vài lần thử, kiểm tra sơ qua kết quả rồi dùng cho đến khi nó vỡ
Nó phù hợp cho proof of concept nhẹ hoặc ứng dụng rủi ro thấp dành cho cá nhân, gia đình hay nhóm nhỏ
Kỹ thuật kiểu agent quan tâm đến các mối bận tâm rộng hơn như tính đúng đắn chức năng, hiệu năng, hạ tầng, khả năng phục hồi/sẵn sàng, khả năng mở rộng, khả năng bảo trì
Có một pipeline nhiều giai đoạn để quản lý luồng công việc, với các bước như tiếp nhận dự án, tuyển chọn, đặc tả, phân rã epic, phân rã story, coding, tài liệu hóa, triển khai
Mỗi giai đoạn có thể trộn giữa các cổng chất lượng mang tính quyết định như vượt qua test hay đạt ngưỡng hiệu năng, và các vòng review đối kháng về giá trị kinh doanh, độ đầy đủ của đặc tả, độ thanh lịch của mã, độ nghiêm ngặt và đơn giản của ubiquitous language
Đây cũng là một thanh trượt
Có lúc bạn không muốn phỏng vấn, đốt token, làm ba vòng review đối kháng, ước lượng giá trị và viết đặc tả chi tiết chỉ để triển khai một tính năng, mà chỉ muốn ném thẳng ticket vào hệ thống
Tôi dùng Opus, GPT-5.5 và các mô hình nhỏ hơn mỗi ngày, nhưng không giao toàn bộ công việc cho chúng
Dù bỏ khá nhiều công để định nghĩa và tinh chỉnh đặc tả, chúng vẫn thường xuyên làm những điều ngu ngốc mà nếu là review PR của người thì tôi sẽ không cho qua
Nếu tôi tin đầu ra của chúng hoặc xây một pipeline agent lớn để tự tạo cảm giác ổn định giả, có lẽ tôi đã dễ để mã đó chảy thẳng vào codebase
Có thể 10 năm nữa sẽ khá hơn, nhưng hiện tại cả vibe coding lẫn pipeline kỹ thuật kiểu agent đều giống như những biến thể của cùng một chủ đề là giao trọn cho LLM
Ngay sáng nay tôi còn nghĩ trong một file đơn lẻ, có thể giao thay đổi cho Opus on Max, nhưng gần như ở mỗi lượt nó đều mắc lỗi hoặc bỏ sót điều gì đó nên tôi phải sửa
Mã nó đề xuất phần lớn là chạy được, nhưng quá phức tạp và còn làm thoái hóa những phần tôi đã tự tay đơn giản hóa
Nếu chuyện này được nhân lên qua hàng nghìn commit của agent, codebase sẽ xuống cấp rất nhanh
Các đội phát triển sẽ gặp khó nếu cố xây mà không có quy trình đúng đắn về thiết kế, test và review
Trước thời agent coding đã vậy, nhưng bây giờ càng đúng hơn, và những đội hiểu cách tận dụng agent trong quy trình này sẽ thành công nhất
Bạn không cảm thấy coding agent thường đi rất gần lời giải ngay ở lần thử đầu, nhưng để chốt được 10% hay 5% cuối cùng lại cần khối lượng công việc khổng lồ sao
Nếu thay đổi cách tiếp cận vấn đề thì agent có thể lấp khoảng cách đó
Mười năm trước, tôi sẽ dừng viết mã mỗi 10–15 phút để refactor, test và phân tích nhằm đảm bảo mọi thứ hoàn hảo
Vì bug sẽ làm ô nhiễm toàn bộ phần mã phía sau
Coding agent không làm được như vậy, và cứ tiếp tục mang theo bug hay kiến trúc sai
Theo bản năng, tôi muốn chặn agent lại giữa chừng, nhưng vì nhiều lý do điều đó là bất khả thi
Thay vào đó, vì chi phí rất rẻ nên ta tìm điểm đầu tiên nơi agent mắc lỗi, sửa prompt, rồi xóa hết và chạy lại từ đầu thay vì sửa mã
Chỉ cần lặp lại việc này cho đến khi prompt tạo ra mã hoàn hảo
Sẽ có người phản bác rằng như vậy con người vẫn phải làm rất nhiều, nhưng đó chính là mấu chốt
Con người vẫn cần thiết, và nếu dùng công cụ theo cách này thì tốc độ viết mã tăng gấp 10 lần
Làm ra “một thứ chạy được” thì khá nhanh, nhưng để đánh giá các phương án khác, tinh chỉnh và test nhằm xây dựng sự chắc chắn thì mất rất lâu
Ý chính là đúng, nhưng không ai biết ranh giới nằm ở đâu
Khoảng một năm tới sẽ là giai đoạn mọi người cùng dò tìm điều đó, và vì thế mới có nhiều lời kiểu “chúng ta cần tái phát minh GitHub”
Trong nhiều trường hợp, đầu tư để cơ giới hóa nốt phần cuối đó là không hợp lý về kinh tế
Tôi cho rằng các nhà cung cấp LLM đã chọn sai hướng ngay từ đầu
Họ lẽ ra nên tập trung vào bổ trợ lao động thay vì thay thế lao động, và có vẻ họ đã học được một bài học đắt giá
Có lẽ bắt đầu lại từ đầu sẽ tốt hơn, nhưng khi khởi đầu tôi chưa biết kiến trúc mình muốn sẽ trông như thế nào
Chỉ vì LLM chật vật trong việc gắn tính năng vào kiến trúc hiện có mà bạn không thể xóa cả codebase đang chạy rồi bắt đầu lại
Đây là một bài viết tuyệt vời từ một người thông minh, khiêm tốn và không ngừng học hỏi
Câu tôi thích là: “Có nhiều lý do khiến tôi không sợ rằng sự nghiệp kỹ sư phần mềm đã chấm hết chỉ vì máy tính giờ có thể tự viết mã của nó. Một phần là vì những thứ này là bộ khuếch đại cho kinh nghiệm sẵn có. Nếu bạn biết mình đang làm gì, bạn có thể chạy nhanh hơn rất nhiều”
Tôi cũng thích đoạn: “Dùng những công cụ này liên tục nhắc tôi rằng công việc của chúng ta khó đến mức nào. Xây dựng phần mềm là thứ cực kỳ khó. Dù có trao cho ta mọi công cụ AI trên đời thì điều chúng ta đang cố làm ở đây vẫn thực sự rất khó”
Nhận định rằng công việc upstream cũng đang thay đổi theo là hoàn toàn chính xác
Công cụ phía thiết kế đang tiến hóa đặc biệt nhanh, đến mức có vẻ không còn đáng để gánh chi phí chuyển dịch bị kẹt bên phía Figma nữa
Phần đáng sợ là các lớp phức tạp do AI tạo ra sẽ tích tụ trong codebase, đến mức con người không còn hiểu nổi mã và phải trả chi phí lớn để các mô hình mới nhất giải mã và sửa đổi nó
Chẳng bao lâu nữa việc tái sử dụng mã có thể biến mất, và ta sẽ đốt tiền để liên tục phát minh lại bánh xe
Khi làm ứng dụng Android thời đầu, bạn gần như bắt buộc phải dùng IDE, và phải viết một lượng mã khuôn mẫu vô lý chỉ để bấm nút rồi hiện thông báo “Hello World”, cảm giác như bị rút cạn linh hồn
Nói theo tôi nào: phần lớn phần mềm dành phần lớn vòng đời của nó ở giai đoạn bảo trì
Vì thế phần lớn tiền mà phần mềm kiếm ra cũng đến trong giai đoạn bảo trì
Gần 100 năm trôi qua mà ngành này vẫn chưa hiểu được điều đó
Alan Kay nói rằng cuộc cách mạng máy tính vẫn chưa diễn ra là đúng 100%
Bất chấp mọi tiến bộ hiện tại, công cụ nhìn chung vẫn ở mức thời đồ đá
Hy vọng lớn của tôi là AI sẽ tăng tốc chúng ta đến điểm phá vỡ hoàn toàn và không thể phục hồi của mô hình hiện tại, để cuối cùng ta có thể làm ra thứ gì đó mới, khác và tốt hơn
Vậy nên hiện giờ cứ gắn jetpack AI vào vòng đời phát triển phần mềm mà thử hết sức đi
Hãy di chuyển thật nhanh, và phá vỡ nó cho ra trò
Một quan sát rất đúng thời điểm và cũng hợp với trải nghiệm của tôi
Tôi cần dựng một pipeline tương đối đơn giản kiểu tải hàng loạt → chuyển đổi → endpoint API, và dù đã viết prompt khá chi tiết, tôi vẫn để trống nhiều chi tiết triển khai như nguồn dữ liệu
Opus 4.7 đã làm ra thứ giống khoảng 90% cách tôi sẽ làm, nhưng thêm nhiều phương thức tiện ích và kiểm tra theo từng bước hơn hẳn
Nó rất tốt, và cho tôi thêm dư địa để nghĩ về những vấn đề khó hơn
Tôi chủ yếu là lập trình viên Python, nhưng cũng dùng đều đặn các ngôn ngữ backend khác như Rust hay Go, những thứ tôi quen nhưng chưa đến cùng trình độ
Với khoảng 13 năm kinh nghiệm nghiêng mạnh về một ngôn ngữ và việc học bài bản các ngôn ngữ khác, việc chỉ huy LLM trở nên dễ hơn rất nhiều
Gánh nặng học cú pháp, các thành phần cơ bản, package manager, test, v.v. là không lớn nếu so với cách lập trình trước đây
Gần đây tôi đã giúp một đồng nghiệp không phải lập trình viên tự động hóa báo cáo bằng Claude cowork/code
Người đó hiểu rất rõ mảng business intelligence, nhưng gặp khó với cách diễn đạt cơ bản để vibe code một pyautogui wrapper mở RDP và điền giá trị vào lớp trừu tượng MS Access nằm trên cơ sở dữ liệu của nhà cung cấp
Lập trình viên như một nghề có lẽ vẫn ổn trong 5–10 năm tới