- Agentic coding là cách con người tạo yêu cầu và kế hoạch, còn nhiều coding agent thực hiện, nhưng cấu trúc này liên tục nới rộng khoảng cách giữa con người và phần mã được sinh ra, được commit
- Cách làm này chỉ thành công khi có lập trình viên dày dạn kinh nghiệm đánh giá phản biện ở cấp độ kiến trúc, nhưng việc lạm dụng AI có thể tạo ra nợ nhận thức (cognitive debt) làm suy yếu chính các kỹ năng cần thiết đó
- Giống như nghịch lý giám sát trong nghiên cứu của Anthropic, để dùng Claude hiệu quả thì cần năng lực lập trình đủ để giám sát, nhưng việc dùng coding agent lại có thể làm suy yếu chính năng lực ấy
- LLM thường dễ bị dùng theo hướng tăng lượng mã được tạo ra trong một khoảng thời gian hơn là ưu tiên sự thấu hiểu sâu và tính cô đọng; chúng cũng có thể lấp đầy yêu cầu mơ hồ bằng giả định hoặc ảo giác, dẫn đến nhiều vòng review, chỉnh sửa và tiêu tốn token hơn
- Sự cố của Claude và biến động chi phí token cho thấy sự phụ thuộc nhà cung cấp và tính bất định về chi phí; dùng AI như công cụ hỗ trợ lập kế hoạch, tài liệu, nghiên cứu và ủy quyền có giới hạn thay vì bộ điều phối thay thế việc triển khai có thể giúp giảm nợ hiểu biết
Đánh đổi mang tính cấu trúc
- Coding agent hữu ích và mạnh mẽ, nhưng đã có những đánh đổi cần được cân nhắc cả về định lượng lẫn thực tiễn
- Để giảm bớt sự mơ hồ đến từ tính không quyết định của AI, độ phức tạp của các hệ thống xung quanh sẽ tăng lên
- Kỹ năng của nhiều lập trình viên có thể bị mai một
- Sự cố từ một nhà cung cấp cụ thể như lỗi Claude Code có thể khiến cả đội ngũ bị đình trệ
- Chi phí nhân sự là cố định, còn chi phí token có thể tiếp tục biến động và tăng lên
- Để cách làm này thành công, cần có những lập trình viên giàu kinh nghiệm có thể tư duy phản biện ở cấp độ kiến trúc và phát hiện vấn đề trước khi chúng phình to trong hàng nghìn dòng mã sinh ra
- Nhưng các công cụ AI có thể tác động tiêu cực đến tư duy phản biện và sự rõ ràng nhận thức cần cho việc đó, làm gia tăng nợ nhận thức (cognitive debt)
Không chỉ là một lớp trừu tượng mới đơn giản
- Chỉ diễn giải đây là “lập trình viên chuyển lên tầng trừu tượng cao hơn” là chưa đủ
- Mức độ mơ hồ cao hơn không đồng nghĩa với một mức trừu tượng cao hơn
- Khi FORTRAN, compiler và ngôn ngữ bậc cao xuất hiện, cũng từng có những phản ứng lo ngại về bug, sự bất ổn, suy giảm hiệu quả và sự gia tăng của “phép màu”
- Nhưng phần lớn lo ngại trước đây là các băn khoăn mang tính chuẩn tắc và lý thuyết về việc sẽ mất đi điều gì khi chấp nhận công nghệ mới, còn công cụ AI chỉ sau vài năm đã bộc lộ tác động thực tế rõ rệt
- Tác động này không chỉ giới hạn ở lập trình viên junior mà còn xuất hiện ở cả những người có hơn 10 năm kinh nghiệm
- Lập trình viên junior phải đối mặt với đường cong học tập dốc hơn khi thời gian trực tiếp xử lý mã giảm đi và họ bị đẩy sang vai trò review mã được sinh ra
- Code review là quan trọng, nhưng chỉ là một nửa của quá trình học; khi ma sát từ việc tự viết và debug mã biến mất, năng lực học hỏi cũng suy yếu mạnh
- Vì hiện tượng này cần thời gian để nghiên cứu, bằng chứng giai thoại vẫn quan trọng để nắm bắt tình hình theo thời gian thực, nhưng cũng đã có tài liệu hỗ trợ như báo cáo của MIT Media Lab và bài viết liên quan đến Microsoft
Vì sao lần thay đổi này khác
- Lập trình viên C++ chuyển sang Java hay Python trước đây không vì thế mà than phiền về “sương mù não”, và quản trị hệ thống chuyển sang AWS cũng không cảm thấy mình mất khả năng hiểu mạng
- Việc kỹ sư senior chuyển sang vai trò quản lý, viết code ít hơn và theo thời gian trở nên “rusty” không phải điều mới
- Trước đây, đó là con đường mà các kỹ sư đã tích lũy hàng chục năm lập trình, ma sát và giải quyết vấn đề rồi mới chuyển sang vai trò xử lý quyết định kiến trúc nhiều hơn cú pháp
- Còn hiện nay, các lập trình viên đang chuyển sang workflow cấp cao hơn là quản lý AI agent mà chưa có kiểu kinh nghiệm dài hạn đó
- Vấn đề là các workflow này lại đòi hỏi đúng những kỹ năng vốn chỉ có được sau hàng chục năm kinh nghiệm
- Ngay cả kỹ sư senior cũng không phải ngoại lệ
- Simon Willison nói rằng dù là lập trình viên với gần 30 năm kinh nghiệm, nếu không có một “mô hình tinh thần vững chắc” về ứng dụng có thể làm gì và vận hành ra sao, thì càng thêm tính năng càng khó suy luận
Nghịch lý của người điều phối lành nghề
- Nghiên cứu gần đây của Anthropic bàn về “nghịch lý giám sát” như một rủi ro khi thường xuyên dùng coding agent
- Cốt lõi là để dùng Claude hiệu quả thì cần giám sát, còn để giám sát Claude thì lại cần chính những kỹ năng lập trình có thể bị suy yếu bởi việc lạm dụng AI
- Sandor Nyako, người quản lý 50 kỹ sư tại LinkedIn, nói rằng ông thấy sự mai một kỹ năng lan rộng trong tổ chức và đã đề nghị đội ngũ không dùng AI cho “những công việc cần tư duy phản biện hoặc giải quyết vấn đề”
- Ông cho rằng để phát triển kỹ năng, cần rèn luyện cơ bắp của việc vật lộn với khó khăn và suy nghĩ sâu về vấn đề; nếu không có tư duy phản biện thì cũng khó đặt câu hỏi xem AI có đúng hay không
- Tiêu chuẩn thế nào là “lạm dụng” vẫn chưa rõ, nhưng nghiên cứu dựa trên dữ liệu và tư liệu giai thoại cho thấy kỹ năng có thể suy yếu nhanh chỉ trong vài tháng
- Việc dùng coding agent tạo ra một mâu thuẫn: nó làm suy yếu chính những kỹ năng cần thiết để quản lý agent cho tốt
LLM đẩy nhanh những phần sai hướng
- Không phải lúc nào mục tiêu cũng là viết code nhanh hơn
- Đặc biệt là không cần tạo nhanh hơn một lượng lớn mã mà bạn chưa hiểu hoàn toàn hoặc không thể review trong thời gian hợp lý
- Trước thời AI, ưu tiên của một lập trình viên giỏi nhìn chung là như sau
- Hiểu mối quan hệ giữa đoạn code và toàn bộ codebase
- Xác nhận rằng nó phù hợp với các tiêu chuẩn hiệu quả đã được tài liệu hóa
- Giảm số dòng mã cần thiết để đạt mục tiêu trong khi vẫn giữ được tính dễ đọc
- Cân nhắc thời gian xử lý
- Agentic coding và LLM trên thực tế đã đảo ngược các ưu tiên này
- Năng lực hiện tại và cách sử dụng hiện nay có xu hướng tập trung vào việc tăng tốc bằng cách tăng lượng mã được sinh ra trong một khoảng thời gian nhất định
- Tốc độ là sản phẩm phụ tự nhiên của trình độ cao, nhưng nếu cưỡng ép đẩy nhanh thì sẽ dẫn đến giảm độ chính xác
- Có thể dùng LLM theo cách nâng cao sự thấu hiểu sâu và tính cô đọng, nhưng việc áp dụng cưỡng ép cùng với cơn sốt đo lường bằng lượng token trên toàn tổ chức cho thấy thực tế sử dụng thường không đi theo hướng đó
Lập trình cũng là lập kế hoạch
- Một số lập trình viên lập kế hoạch tốt hơn và suy nghĩ tốt hơn bằng code
- Việc suy nghĩ và làm việc thông qua code không phải lao động lặp lại vô nghĩa, mà là quá trình buộc con người phải nghĩ ở cấp độ kỹ thuật về bảo mật, hiệu năng, trải nghiệm người dùng và khả năng bảo trì
- Dax, người tạo ra OpenCode, trong một cuộc phỏng vấn về Spec Driven Development, nói rằng khi làm việc mới hoặc khó, anh tìm ra mình cần làm gì thông qua quá trình tự gõ code
- Anh thích tự chạm vào type, tương tác giữa các hàm và cấu trúc thư mục để hình thành khái niệm, thay vì trước tiên viết ra một bản spec khổng lồ
- Điều con người nói ra không phải lúc nào cũng trùng với ý định thực sự, còn LLM thì lấp đầy sự mơ hồ bằng giả định hoặc ảo giác
- Kết quả là nhiều review hơn, nhiều lần agent sửa hơn, nhiều token bị tiêu tốn hơn và khoảng cách với sản phẩm sinh ra lớn hơn
- Ngược lại, ngay cả khi viết prompt rất rõ ràng và có cấu trúc, LLM vẫn có thể xuất ra các method bị ảo giác
- LLM không phải compiler mà là cỗ máy dự đoán token tiếp theo, nên không thể thay thế một hệ thống mang tính quyết định bằng hệ thống xác suất rồi kỳ vọng độ mơ hồ sẽ về 0
- Ngay cả các lập trình viên senior tích cực dùng AI cũng bắt đầu coi sự tách rời này là một vấn đề ngày càng lớn
Phụ thuộc nhà cung cấp và bất định chi phí
- Trong thời gian Claude gặp sự cố, đã xuất hiện các bài đăng cho thấy một số lập trình viên và đội kỹ thuật bị khựng lại
- Một số workflow và cả năng lực lập trình giờ đã đạt đến mức phụ thuộc rất lớn vào một nhà cung cấp AI cụ thể
- Những kỹ năng trước đây chỉ cần bàn phím và trình soạn thảo văn bản giờ lại đòi hỏi phải có thuê bao với nhà cung cấp mô hình AI
-
Chi phí token khó dự đoán
- Các nhà cung cấp mô hình đang được trợ giá mạnh, và bản thân các mô hình cũng đứng trên một nền tảng luôn thay đổi
- Mỗi lần ra mắt mô hình mới thường lặp lại cùng một mô thức: benchmark cao, cơn sốt bùng lên, rồi sau khi dùng thực tế xuất hiện phàn nàn rằng nó đã bị “nerf”
- Kèm theo đó là than phiền rằng để xử lý cùng một việc lại phải đốt token nhiều gấp 2–3 lần
- Chi phí nhân sự có thể biết trước, nhưng chi phí token thì khó dự đoán theo ngày, theo tháng lẫn theo năm
- Nếu cả đội lấy agentic coding làm mặc định, tài khoản chi phí sẽ phải được giữ ở mức rất linh hoạt
- Primeagen nói rằng nếu dùng workflow agentic hoàn toàn thì “nhà cung cấp mô hình về cơ bản sẽ sở hữu bạn”
- Có thể hình thành một cấu trúc ngành nơi bạn phải trả chi phí tiêu thụ token chỉ để làm những việc trước đây vốn dựa vào tư duy phản biện và năng lực giải quyết vấn đề
- Đây không chỉ là phụ thuộc nhà cung cấp sản phẩm, mà gần như là phụ thuộc nhà cung cấp đối với năng lực kỹ thuật của cả ngành
- Nền tảng tài chính lẫn trí tuệ có thể rung chuyển bất cứ lúc nào, còn LLM cục bộ thì chưa sẵn sàng để hấp thụ quy mô sử dụng như vậy
- Đây không phải vấn đề lý thuyết mà đã được đưa tin, và chính các nhà cung cấp mô hình cũng đang trực tiếp làm nổi bật nó
- Một nghiên cứu khác của Anthropic cho biết kỹ năng debug đã giảm mạnh 47%
- Nếu AI được đưa vào nơi làm việc, đặc biệt là trong kỹ thuật phần mềm, theo cách quá quyết liệt, con người có thể dựa vào AI để ra kết quả nhanh mà không xây dựng được kỹ năng cốt lõi để debug khi có vấn đề
Cách tiếp cận hạ thấp vai trò của AI
- LLM có thể là công cụ mạnh để học tập và nâng cao năng lực
- Chúng có thể giúp khám phá khái niệm và kỹ thuật sâu hơn, rộng hơn, và thử nghiệm ý tưởng mới với ít công sức hơn trước
- Bản thân công cụ sinh code không phải là điều mới
- Emmet, autocomplete và snippet đều là những công cụ giúp viết ít hơn và sinh mã nhiều hơn
- COBOL cũng từng cố gắng gói nhiều lệnh hơn trong ít thao tác viết hơn bằng các từ kiểu tiếng Anh như
MOVE, WRITE
- Khẩu hiệu của jQuery cũng là “write less, do more”
- Có thể xem LLM là một phần bổ sung nữa cho nhóm công cụ sinh code đó
- Điểm khác biệt quan trọng nằm ở việc dùng LLM và coding agent như các quy trình hỗ trợ
- Có thể tận dụng AI để brainstorming ở giai đoạn lập kế hoạch nhưng vẫn chủ động tham gia vào triển khai, thay vì hy sinh kỹ năng cá nhân để đổi lấy năng suất
- Chỉ ủy quyền khi thực sự cần sẽ giúp vừa có lợi ích về năng suất vừa giảm nợ hiểu biết
Cách dùng hằng ngày
- Dùng LLM để tạo spec và kế hoạch, nhưng triển khai do con người dẫn dắt
- Đây là cách đảo ngược workflow “orchestration”, và tùy công việc mà tự code từ 20% đến 100%
- Ngay cả khi dùng model, vẫn thường xuyên viết pseudocode để rút ngắn khoảng cách giữa yêu cầu và phần mã được sinh ra
- Model được dùng để sinh mã tạm thời, làm tài liệu tương tác và công cụ nghiên cứu
- Dùng nó như công cụ ủy quyền có trách nhiệm để đặt câu hỏi, lặp lại, refactor và làm rõ cách tiếp cận
- Không sinh ra lượng code nhiều hơn mức có thể review trong một lần
- Nếu quá nhiều để review, hãy giảm tốc độ, chia nhỏ công việc, và khi cần thì tự refactor để hiểu toàn diện kết quả cuối cùng
- Không giao cho LLM hay agent những triển khai mà bản thân chưa từng làm hoặc không thể tự làm một mình
- Ngoại lệ là cho mục đích học tập hay tutorial, và các kết quả đó thường sẽ bị bỏ đi sau này
- Tóm lại, nên dùng AI như Ship’s Computer chứ không phải Data trong Star Trek
Làm việc tốt hơn thay vì chỉ nhanh hơn
- Mức tăng năng suất từ model là có thật
- Đồng thời, ma sát và mức độ thấu hiểu đến từ việc trực tiếp và thường xuyên xử lý công việc cũng thực sự quan trọng
- Những nỗ lực dân chủ hóa lập trình mà không hiểu lập trình đã nhiều lần thất bại
- Muốn hiểu code thì phải ăn khớp trực tiếp với code
- Nếu không tiếp tục gắn bó và tự viết code, bạn có thể mất đi sự hiểu biết và kết nối đó
- Khi mất đi sự hiểu biết, năng lực quản lý agent tốt hơn cũng suy yếu, và giai đoạn lập trình bằng AI sẽ trở thành một thời kỳ chuyển tiếp kỳ lạ và căng thẳng không cần thiết
Có thể đây là một thí nghiệm lớn hơn
- Xu hướng hiện nay giống như một thí nghiệm quy mô lớn khác mà chúng ta đang tự tiến hành lên chính mình khi chưa hiểu đủ tác động dài hạn
- Khi mạng xã hội được đưa vào sử dụng rộng rãi, chúng ta cũng không hiểu hết hệ quả dài hạn, và sau đó nhiều vấn đề như suy giảm khả năng chú ý đã xuất hiện trên diện rộng
- Lần này, thứ được đem ra đặt cược còn nguy hiểm hơn
- Jeremy Howard, người tạo ra fast.ai, nói rằng những ai đặt cược tất tay vào AI agent đang tự đảm bảo sự trở nên vô dụng của chính mình
- Nếu thuê ngoài mọi suy nghĩ cho máy tính, con người sẽ ngừng quá trình nâng cao năng lực, học hỏi và trở nên giỏi hơn
1 bình luận
Ý kiến trên Hacker News
Trong vài năm qua làm việc với lập trình tác tử, tôi đã học được về ngôn ngữ, hệ thống và công cụ mình dùng còn nhiều hơn cả 35 năm tự tay lập trình
Khả năng quyết định hệ thống, kỹ thuật và cách tiếp cận thì tôi vẫn giỏi hơn công cụ rất nhiều, nhưng các công cụ này giống như một thực tập sinh cực kỳ uyên bác, biết rất nhiều chi tiết lặt vặt. Kinh nghiệm còn ít và cũng nhiệt tình mắc lỗi, nhưng ít nhất lúc đầu thì biết tiếp thu phản hồi và biến thành hành động. Chỉ là chúng không thực sự hiểu và nội tại hóa, nên thường hay quên
Việc cho rằng bạn phải biết toàn bộ mọi thứ mình đang làm là cực kỳ ngây thơ. Chỉ cần làm ở hai đội trở lên là đã có rất nhiều phần bạn không thể hiểu hoàn toàn, còn với codebase lâu năm thì gần như mọi phần đều có thể xa lạ. Trong một monorepo khổng lồ tích lũy qua hàng chục năm, ngay cả phần mà mọi người xem bạn là chuyên gia mà bạn thật sự hiểu rõ được thì cũng đã là may mắn
Những người đưa ra kiểu lập luận này thường либо rất junior, либо gần như làm việc một mình, hoặc như thể đã bám vào một dự án suốt 20 năm. Không ai làm trong đội hay tổ chức lớn có thể nói rằng mình biết toàn bộ codebase, và người làm lập trình tác tử cũng vậy. Dù sao thì bạn vẫn có thể hỏi tác tử và nhận câu trả lời, còn với tư cách người đã dành cả đời đọc code của người khác, tôi cũng đọc được code do LLM viết. Code tệ do máy hay do người viết thì với tôi cũng chẳng khác biệt gì, và ít nhất máy còn biết nhận phản hồi của tôi rồi hành động theo
Tôi đã thấy nhiều team phần mềm bị chững lại chỉ vì một vấn đề nhỏ nhưng lại cần thêm kỹ năng như ngôn ngữ cấp thấp, assembly, thuật toán ít phổ biến, hay giao thức mạng
Ngược lại, đôi khi họ bị chặn không phải vì không đủ khả năng diễn giải thứ mình thấy, mà vì đang dùng những thứ hộp đen như thư viện độc quyền hay hệ điều hành độc quyền, nên không thể đào vào bên trong và cũng không có cách xác minh cách nó thực sự hoạt động
Vì thế tôi nghĩ phải luôn có khả năng tìm hiểu đến cùng mọi thứ mình đang làm, dù nhu cầu đó chỉ rất hiếm khi xuất hiện
Điều quan trọng là không sợ học phần còn lại của hệ thống, và duy trì một chỉ mục trong đầu
Trên hết, phải có khả năng nắm được mọi thứ rất nhanh. Như vậy mới xử lý được theo bề rộng. Khi cần thì đào sâu, khi cần thì lướt ở mức cao, tức là chọn đúng mức độ phù hợp với vấn đề
Hồi xưa ở đại học, người ta dạy sinh viên khoa học máy tính cả nền tảng kỹ thuật nói chung. Tôi hỏi “khi nào thì tôi cần biết kỹ thuật hóa học hay hệ thống điều khiển analog?”, họ trả lời: “Có lẽ sẽ chẳng bao giờ dùng. Nhưng bạn phải có thể nắm được nó đủ nhanh để lập trình, rồi quên đi sau đó. Chúng tôi đang trao cho bạn một nền tảng vững chắc”
Điều này cũng áp dụng nguyên vẹn trong một codebase lớn
Các công cụ như git-ai [0] lưu lại phiên làm việc của LLM và gắn từng chỉnh sửa file với một hành động tác tử cụ thể, đồng thời cho phép tác tử truy vấn đoạn hội thoại xung quanh một mảnh code nhất định, tức là người dùng đã prompt gì, suy luận của LLM tạo ra đoạn code đó là gì, v.v. Điều này có thể thay đổi thế cân bằng, nhưng hiện chưa được dùng rộng rãi
[0] https://usegitai.com/
Là một senior developer với hơn 25 năm kinh nghiệm, gần đây tôi bị quăng vào một cuộc họp kiểu “vào 5 phút được không”, và tôi thật sự ghét kiểu họp bị kéo vào giữa chừng không có chút bối cảnh nào như vậy
Câu hỏi được bắn ra rất nhanh mà không có phần giới thiệu nào, và là về một tích hợp bên ngoài trong số hàng chục cái. Tệ hơn nữa là phía đó còn dùng hệ thuật ngữ riêng khác với chúng tôi
Vì đã phụ thuộc rất nhiều vào model khi làm các tích hợp này, tôi đã rất vất vả để hiểu các câu hỏi. Đó là công việc cực kỳ tẻ nhạt, lại có sẵn đặc tả bên ngoài dày cộp
Tôi vẫn thấy tích cực ở chỗ, nếu không dùng model thì có bỏ ra gấp 10 lần thời gian cũng có lẽ không thể hoàn thành các tích hợp này. Nhưng giờ tôi đang cân nhắc nghiêm túc việc viết lại tài liệu các điểm “à ha” để những khoảnh khắc khó chịu như thế này không lặp lại nữa
Chưa bao giờ tôi cảm thấy thiếu hiểu biết và xấu hổ đến vậy trong một cuộc họp, và tất cả những gì tôi có thể nói chỉ là “tôi sẽ kiểm tra lại rồi trả lời câu đó, cả câu này nữa, và cả câu kia nữa”
Nợ nhận thức là thứ hoàn toàn có thật, và với cá nhân tôi nó còn đau hơn technical debt. Technical debt là thứ cả đội cùng gánh, còn nợ nhận thức thì mang tính cá nhân, và nếu chính tôi là người tạo ra nó thì lẽ ra tôi phải biết rõ hơn chứ
Từ giờ, nếu chưa làm một danh sách thuật ngữ Markdown kiểu flashcard 5 phút về “cái này là gì”, “cái kia là gì”, thì tôi sẽ xem như công việc chưa hoàn thành
Là senior developer, bạn là người phải đạp phanh trước những hành vi mà mình thấy không ổn. Bạn có thẩm quyền đó. Chỉ cần nói: “Câu hỏi thú vị đấy. Để đưa ra góc nhìn của tôi thì tôi cần thêm bối cảnh. Bạn có thể mô tả ngắn gọn kiến trúc hệ thống hoặc giải thích vấn đề thực tế mà cách tiếp cận này đang cố giải quyết không?”
Khi bị đối xử như vậy, câu “để trả lời đúng các câu hỏi này tôi cần xem lại tài liệu và code” là một phản hồi hoàn toàn ổn, lại khá ngoại giao
Những cuộc họp nơi chuyên môn không được xem là thứ để xây dựng, mà chỉ được dùng để xác nhận một kiểu thiên kiến xác nhận đầy sáng tạo, thì chẳng vui vẻ gì
Muốn tìm ra vấn đề trong code được sinh ra thì lập trình viên phải thực sự quan tâm. Nhiều lập trình viên, nhất là ở các công ty lớn, vốn đã khá buông xuôi với công việc và chỉ tìm cách đóng ticket bằng ít công sức nhất có thể rồi đẩy trách nhiệm đi chỗ khác
Những người như vậy, dù có năng lực, cũng sẽ không cố gắng hiểu code sinh ra đủ sâu để tìm ra những vấn đề mà tác tử bỏ sót. Đặc biệt là trong cơn sốt tốc độ do AI dẫn dắt như hiện nay thì lại càng thế
Code sinh ra nhìn bề ngoài thì có vẻ đúng ngôn ngữ, nhưng thường vô thức bắt chước các thành ngữ quen thuộc một cách incoherent, khiến bug thật sự có thể bị che giấu ngẫu nhiên theo những cách mà một lập trình viên bình thường, thậm chí cả một lập trình viên tệ, cũng khó mà nghĩ ra
LLM không có cơ chế tự thẩm định nội bộ, nên reviewer phải đánh giá từng dòng với điều đó trong đầu, đồng thời phải dựng lại từ đầu những cơ sở ngầm và tri thức ngầm mà LLM vốn chưa từng có. Vì thế đôi khi lại bị kéo vào những thứ không phải vấn đề và lãng phí thời gian đắt đỏ
Đến lúc này, khoản đầu tư bỏ ra thường còn lớn hơn cả việc tự viết từ đầu
Có khi bây giờ các công ty đang mua AI rác, rồi ở bước tiếp theo lại được hứa hẹn “giải pháp” cho nó. Chủ nghĩa tư bản đang vận hành đúng như người ta dự đoán
Bài này có vẻ hơi trượt khỏi trọng tâm một chút
Dùng AI nhiều thì đúng là có hao hụt kỹ năng
Nhưng tôi muốn thừa nhận con voi ngượng ngùng giữa căn phòng. AI đang khiến con người tăng tốc quá nhanh. Không phải bản thân đầu ra nhanh là xấu, mà là đầu ra và code đang đi trước quá xa so với mức độ hiểu biết và kinh nghiệm tổng thể đã tạo ra chúng. Người có kiến thức sâu, đưa ra quyết định an toàn khi xây dựng thì lại được tưởng thưởng kém hơn người chỉ biết nói về giá trị kinh doanh
AI có thể tốt và có thể tạo ra giải pháp tốt, nhưng rốt cuộc nó không biết mình đang làm gì, và ngay cả trong trường hợp tốt nhất cũng vẫn cần một người điều phối rất mạnh
Chúng ta đang ngụp trong vũng bùn của phát triển bị dẫn dắt bởi kinh doanh, còn những quyết định tệ thì không bị trừng phạt đủ nặng về mặt danh tiếng
Nói cách khác, tôi không chắc hao hụt kỹ năng có phải vấn đề quá lớn không. Có thể nó chỉ là dấu hiệu cho thấy bản chất công việc của chúng ta đang thay đổi. Có lẽ đang đến thời kỳ mà việc hiểu kiến trúc tốt sẽ được đánh giá cao hơn khả năng thuộc nằm lòng chuẩn C++ và dùng đúng hàng trăm tính năng của nó
Trong phát triển thông thường, ta có xu hướng qua lại nhiều hơn giữa “liệu mình có thật sự muốn xây cái này không” và “nếu làm thế này thì điều gì có thể sai”, lý tưởng nhất là trước khi PR được duyệt hay được merge và deploy. Giờ thì một phần của việc đó đang bị đẩy sang kiểu “để xem sau này ai sẽ than phiền”. Nói như câu phòng bệnh hơn chữa bệnh
Hơn nữa, đoạn code đó còn không theo phong cách C++ thành ngữ của dự án, và LLM thì hoàn toàn phớt lờ các API sẵn có. Vẫn sửa được và maintainer lẽ ra phải chặn, nhưng lượng code được sinh ra khiến mọi người phải tốn quá nhiều năng lượng
Những bài blog kiểu này gần như chắc chắn cũng được viết với sự trợ giúp của AI, vậy mà vẫn đang là chủ đề bình luận suốt nhiều năm ở đây và khắp Internet. Teo tóp kỹ năng là một mối lo nghiêm trọng, ai hoài nghi AI từ 2022 đến nay cũng đã nhắc đi nhắc lại điều đó, nhưng có người và có nơi dường như chẳng hề quan tâm
Đến một thời điểm nào đó, nếu bạn chỉ còn biết kéo cần của cỗ máy rác mà không có chút hiểu biết nào về code, thì việc sếp hỏi tại sao bạn phải nhận hơn 50.000 USD mỗi năm cũng là điều hợp lý
Dùng AI để đi nhanh hơn là tối ưu sai thứ cần tối ưu. Ở mọi nơi tôi từng làm, bản thân việc “viết code” luôn chiếm ít thời gian nhất so với tất cả những việc khác cần làm để triển khai tính năng
Hãy lấy một tính năng mà chỉ mất một ngày để code. Trước hết, phải lên kế hoạch cho mọi thứ theo nghi thức của Agile hay Waterfall mà công ty dùng, chia nhỏ công việc, tạo ticket JIRA, quyết định ai làm. Chỉ riêng khâu này có thể mất vài ngày hoặc vài tuần. Sau đó phải viết tài liệu thiết kế nêu phương án đề xuất và nhận review từ đồng nghiệp, thành viên trong team; nếu là tính năng thực chất thì lại thêm khoảng một tuần. Nếu liên quan nhiều team thì còn phải lấy sự đồng thuận và thống nhất thiết kế từ các team đó, vậy là cộng thêm một tuần nữa. Ở một số nơi còn cần phê duyệt để bắt đầu công việc, tùy lịch và độ rảnh của người duyệt mà lại mất thêm vài ngày
Sau đó bạn dành một ngày viết code và cho test chạy qua
Tiếp theo là code review, với nhiều vòng qua lại cùng team và có thể phải qua thêm các đợt review khác. Lại thêm vài ngày hoặc vài tuần nữa. Ở công ty lớn hơn, còn phải qua đủ kiểu review từ các bộ phận khác như pháp lý, quyền riêng tư, hiệu năng, accessibility, QA. Dù làm song song thì cứ bảo thủ mà cộng thêm 2 tuần. Cuối cùng là đưa lên staging và để nó “chín” một thời gian trong nhóm dogfooder nội bộ để có đủ tự tin rằng nó hoạt động đúng. Thêm 1 tuần. Giờ thì đã sẵn sàng đẩy từ staging lên production, nhưng công ty nào nghiêm túc cũng không đẩy ngay 100% vào production. Phải tăng dần tỷ lệ, theo dõi phản hồi và chỉ số để phòng khi cần rollback. Chỉ riêng toàn bộ giai đoạn rollout cũng có thể mất thêm 2 tuần
Vậy là với một tính năng mất cỡ hai tháng từ thiết kế đến phát hành, chúng ta lại đang phát cuồng chỉ để rút phần mất một ngày xuống còn 5 phút
Khi xây dựng phần mềm, hãy nhớ rằng nó là ảnh chụp nhanh của sự thấu hiểu đối với vấn đề. Nó nói với mọi người, kể cả chính bạn trong tương lai, về cách tiếp cận, độ rõ ràng và mức độ phù hợp của lời giải cho vấn đề trước mắt. Vì thế hãy chọn điều mình muốn nói một cách khôn ngoan
Cách diễn đạt rằng chúng ta đang cố biến phần mất một ngày thành 5 phút trong một tính năng mất hai tháng từ thiết kế đến phát hành là rất trúng
Những việc như vậy từng là một phần không nhỏ trong công việc hằng ngày của mọi kỹ sư ở các công ty ổn định. Gọi là “platform engineering” hay gì cũng được, nhưng mảng này coi như đã chết
Ngoài ra, những ý tưởng có rủi ro kỹ thuật cao mà trước đây không ai dám thử vì phần thưởng không tương xứng với rủi ro và công sức, giờ đã trở nên trong tầm tay. Không chỉ đơn giản là “đi nhanh hơn”, mà tốc độ thử nghiệm một thứ gì đó đang thay đổi chính bản chất của quy trình kỹ thuật
Nếu kỹ sư phần mềm đủ rẻ, thì phần lớn nhu cầu tồn tại của các quy trình này sẽ biến mất. Các công ty vốn đã có những quy trình như vậy chắc sẽ gặp khó, vì phá bỏ bộ máy quan liêu đó là chuyện cực kỳ khó, nhưng những công ty vốn không có hoặc có thể loại bỏ chúng sẽ giành được lợi thế cạnh tranh đáng kể
Đây không phải điều mới. Startup từ lâu đã luôn cạnh tranh với các công ty hiện hữu bằng tốc độ thực thi. Điểm mới là khả năng duy trì tốc độ đó lâu hơn
Các khâu review như pháp lý, quyền riêng tư, hiệu năng, accessibility, QA cũng đều đang nằm trong tầm ngắm. Nếu công ty có thể chuyển trách nhiệm pháp lý của các khâu review này sang nhà cung cấp bên ngoài thì họ sẽ làm
[0] Tạm bỏ qua sự mỉa mai là phần lớn quy trình này rốt cuộc lại bị đẩy lên chính những nhân viên mà nó định tiết kiệm thời gian cho
Big Tech thì có nhiều thủ tục kiểu khoa trương như vậy, còn công ty nhỏ có thể di chuyển nhanh và thô hơn nhiều
Chất lượng code cuối cùng vẫn phụ thuộc vào bạn
Không có gì ngăn cản bạn lặp đi lặp lại với tác tử, tinh chỉnh cho đến khi code đạt chất lượng y hệt như thể chính bạn đã viết
Những bài kiểu này khá gây bực bội. Dù vậy, cái mà tác giả nói về chi phí token là có thật và nguy hiểm
Tôi dùng công cụ AI để brainstorm cách tiếp cận và thỉnh thoảng sinh code, nhưng phần gõ thật thì tôi tự làm. Như vậy theo thời gian sẽ ít có nguy cơ quên mất cơ chế và ngôn ngữ lập trình hơn
Thành thật mà nói, nếu toàn bộ chỉ còn là prompt cho LLM viết code rồi review, chắc tôi cũng chẳng buồn làm maintainer mã nguồn mở nữa. Nó chẳng mang lại cảm giác thỏa mãn gì cả
Nếu là công việc được trả lương thật sự thì tôi cũng tò mò xem cách mình dùng LLM sẽ khác đi thế nào. Tôi trở thành lập trình viên phần mềm vì yêu chính kỹ nghệ này. Tôi thích hành động tạo ra thứ gì đó, thích việc dùng bộ não để biến ý tưởng thành code. Nếu nghề này chỉ còn là prompt cho LLM thì tôi không biết mình có tiếp tục không. Ít nhất chắc tôi sẽ bắt đầu tìm hướng chuyển nghề
Tôi dùng cách đó với code phải bảo trì. Dù vậy model vẫn trộn vào khá nhiều thông tin sai nên đôi khi vẫn dính bẫy. Thường là những thứ trước đây đúng nhưng bây giờ đã sai
Với script vứt đi được hoặc dễ xác minh thì tôi vẫn cho nó sinh ra, nhưng tôi bảo nó tránh over-engineering hoặc cố bắt hết mọi edge case. Với script, để một bước lỗi rồi lộ ra luôn thường lại dễ hiểu hơn
Tôi tránh các ngôn ngữ như PowerShell vì cảm thấy khó đọc, và thích sinh ra những thứ đủ ngắn để nằm trọn trong một màn hình, để tôi có thể đọc và hiểu toàn bộ. Python, Bash, Batch là các ngôn ngữ script tôi dùng nhiều nhất
Tôi vẫn từ chối hơn 50% gợi ý của AI. Vì chúng quá tầm thường, hoặc di chuyển code vô cớ, hoặc đôi khi đơn giản là sai
Điều buồn cười là công nghệ này rốt cuộc chỉ là một trong hai thứ
Hoặc là công nghệ dành cho quản lý: có thể giao việc mà không cần chuyên môn, nhưng cũng chẳng biết nó sai hay bất khả thi; hoặc là công nghệ dành cho coder: có chuyên môn nhưng lại ngày càng mất chính chuyên môn đó
Vì vậy tôi không rõ nó là vì ai, ngoài VC và cổ đông đến hết quý sau
Hơi ngoài chủ đề một chút, nhưng tôi thấy buồn cười khi bài viết nói Spec Driven Development là tương lai
Về mặt kỹ thuật thì thời còn làm Waterfall chúng ta đã làm như vậy rồi. Tôi cũng hơi nhớ cái thời có tài liệu tử tế. Suốt 10 năm qua, thậm chí có thể lâu hơn, tôi thường chỉ nhận các ticket JIRA đúng một dòng và hầu như không chỉ rõ gì, đến mức nhiều lần phải gọi điện cho người ta hỏi thêm
Tôi vẫn đang tránh làm việc với AI. Tôi định thử vài model local cho mục đích thực nghiệm, nhưng tôi từ chối trả tiền cho thứ được dựng từ đồ của người khác. Và cho đến giờ thì model local vẫn chưa đáp ứng kỳ vọng