- Thực tế chi phí viết code giảm mạnh đang làm lung lay toàn bộ thói quen kỹ thuật phần mềm
- Trước đây, do việc tạo ra code có chi phí cao, nên đã hình thành văn hóa phát triển hiệu quả xoay quanh thiết kế, ước lượng và lập kế hoạch
- Với sự xuất hiện của coding agent, một lập trình viên giờ có thể đồng thời thực hiện nhiều công việc (triển khai, refactor, kiểm thử, tài liệu hóa)
- Tuy nhiên, việc tạo ra “code tốt” vẫn đòi hỏi tiêu chuẩn chất lượng cao và sự phán đoán của lập trình viên
- Vì vậy, thách thức đặt ra là phải xây dựng những thói quen phát triển mới ở cấp độ cá nhân và tổ chức
Sự thay đổi về chi phí viết code
- Trước đây, để viết ra vài trăm dòng code sạch và đã được kiểm thử thường mất hơn một ngày
- Vì thế, lập trình viên đánh giá giá trị và mức độ ưu tiên của tính năng dựa trên thời gian và chi phí hạn chế
- Thiết kế dự án, ước lượng tiến độ, lập kế hoạch tính năng đều xoay quanh “việc sử dụng thời gian coding một cách hiệu quả”
- Việc đưa coding agent vào sử dụng đã làm chi phí nhập code giảm mạnh, khiến các tiêu chí đánh giá cũ bị lung lay
- Một kỹ sư có thể chạy song song nhiều agent để thực hiện các công việc phát triển đồng thời trên nhiều mặt
- Sự thay đổi này buộc chúng ta phải xem xét lại cấu trúc đánh giá giá trị theo thời gian trước đây
“Code tốt” vẫn còn đắt đỏ
- Việc tạo ra code mới nay gần như miễn phí, nhưng tạo ra “code tốt” vẫn rất tốn kém
- Các điều kiện của code tốt bao gồm:
- Hoạt động chính xác, đạt được mục tiêu mà không có lỗi
- Được chứng minh là đáng tin cậy thông qua quy trình kiểm chứng
- Tập trung vào giải quyết đúng vấn đề, đồng thời xử lý các tình huống lỗi theo cách có thể dự đoán
- Giữ cấu trúc đơn giản và tối thiểu để tăng khả năng bảo trì và mức độ dễ hiểu
- Kiểm thử và tài liệu phải luôn được cập nhật
- Có tính đến khả năng thay đổi trong tương lai nhưng không thêm độ phức tạp không cần thiết
- Đáp ứng các thuộc tính chất lượng phi chức năng như khả năng truy cập, bảo mật, khả năng mở rộng, khả năng bảo trì
- Coding agent có thể hỗ trợ một phần của quá trình này, nhưng trách nhiệm bảo đảm chất lượng cuối cùng vẫn thuộc về lập trình viên
Sự cần thiết của những thói quen phát triển mới
- Trong môi trường agentic engineering (kỹ thuật phần mềm dựa trên agent), các thói quen phát triển cũ không còn phù hợp nữa
- Cả cá nhân lẫn tổ chức đều phải hình thành cách làm việc và tiêu chí đánh giá mới
- Hiện nay, toàn ngành vẫn đang trong quá trình xác lập các best practices (thực hành tốt nhất) này
- Cách tiếp cận được đề xuất là: ngay cả khi cảm thấy “không đáng tốn thời gian”, hãy thử chạy một phiên agent bất đồng bộ để thực nghiệm
- Tệ nhất thì 10 phút sau kiểm tra lại và thấy chỉ kết thúc bằng sự lãng phí token mà thôi
Vị trí của bài viết trong hướng dẫn Agentic Engineering Patterns
- Bài viết này là một phần của “Principles”, chương đầu tiên trong hướng dẫn Agentic Engineering Patterns
- Ở chương tiếp theo, chủ đề hiểu code (Understanding code) sẽ tiếp nối với Linear walkthroughs
- Sau đó, trong phần Testing and QA, sẽ có các chủ đề như Red/green TDD và First run the tests
- Dự kiến mỗi tuần sẽ bổ sung thêm 1–2 chương; cấu trúc sẽ giống sách nhưng ở định dạng “guide”
1 bình luận
Ý kiến trên Hacker News
Tôi không chắc cách nói “code vốn luôn đắt” có đúng hay không
Thực ra thứ đắt đỏ là không phải bản thân code mà là toàn bộ những gì xung quanh nó — đảm bảo tính đúng đắn, bảo trì, phối hợp giữa các nhóm, hỗ trợ dài hạn, v.v. mới là các yếu tố chi phí thực sự
Nếu quy trình kiểm thử hay phê duyệt quá mức, chính quy trình đó có thể chiếm phần lớn chi phí
LLM trong ngắn hạn đã làm giảm mạnh chi phí tạo ra code chạy được, nhưng về dài hạn có thể làm tăng gánh nặng bảo trì, bảo mật và kiểm thử
Cuối cùng, phải nhìn vào dữ liệu dài hạn mới biết liệu thay đổi thực sự đã xảy ra hay chưa
Trước đây, ngay cả việc viết vài trăm dòng code cũng đã tốn kém
Tôi thử đưa 256 dòng JavaScript vào công cụ SLOCount kiểu những năm 2000 (bản WebAssembly), thì nó ước tính chi phí vào khoảng $6,461 theo mặt bằng thời đó
Tất nhiên con số đó chỉ nên xem cho vui
Giờ tôi giống một người quản lý chính mình hơn là trực tiếp làm việc
Tôi có cảm giác năng suất đã tăng khoảng 2,5 lần so với trước
Thu thập yêu cầu, thiết kế, kiểm thử, triển khai và bảo trì vẫn luôn cần thiết, và phần lớn chi phí phát sinh ở giai đoạn bảo trì
Giống như định luật Amdahl, kể cả khi chi phí coding tiến gần về 0 thì chi phí ở các giai đoạn khác vẫn trở thành giới hạn
Vấn đề là điều đó vốn khó do bản tính con người
Những yếu tố chất lượng như tính đúng đắn, khả năng bảo trì, hiệu năng là các chi phí ẩn chỉ có thể lĩnh hội qua kinh nghiệm
Tôi không đồng ý với lập luận “code vốn luôn đắt”
Thực ra code đắt là vì người ta cố viết ‘code tốt’
Nếu hạ tiêu chuẩn xuống thì code được sinh ra sẽ nhanh và rẻ, nhưng công sức đưa nó trở lại thành code tốt thì vẫn như cũ
Nếu muốn bảo vệ agent coding thì phải tiếp cận bằng một logic khác
Khi tự viết, tôi hiểu lý do của từng dòng, nhưng với code do AI tạo ra thì phải xác minh từng câu lệnh
Trong tháng vừa rồi tôi làm phần lớn công việc bằng agent, và liên tục xuất hiện những lỗi edge case mà con người thường sẽ không tạo ra
Kết cục là chi phí review tăng cao, làm biến mất lợi ích ngắn hạn
Tuy vậy nhờ có coding agent mà chi phí đó đã giảm đi rất nhiều
Các chỉnh sửa tỉ mỉ được agent xử lý thay nên có thể tạo ra code chất lượng tốt hơn nhanh hơn
Độ phức tạp sẽ tích lũy, nên xử lý cẩn thận ngay từ lúc viết lần đầu là rẻ nhất
Hiện tại lợi ích ngắn hạn là lớn, nhưng về dài hạn tiếng ồn có thể tăng gấp 10 lần
LLM phù hợp với lập trình chiến thuật, tức là hiện thực tính năng nhanh
Vì vậy việc quản lý độ phức tạp ở cấp độ hệ thống lại càng quan trọng hơn
Việc sinh code rẻ đúng như người ta vẫn nói, nhưng kỹ năng biến nó thành kết quả có giá trị mới là năng lực thực sự
Agentic engineering rốt cuộc là kỹ năng dẫn dắt đầu vào rẻ tiền thành đầu ra có giá trị
Agentic engineering không chỉ là viết phần mềm, mà là làm ra công cụ để giải quyết nhanh một vấn đề cụ thể
Nhưng khi việc giải quyết vấn đề đã xong thì bản thân AI không còn thú vị nữa
Nhiều người lấy AI làm mục đích tự thân, nhưng giá trị thực nằm ở giải quyết vấn đề
Như Alan Watts từng nói, khi đã nhận được thông điệp thì hãy cúp máy
Công cụ rẻ hơn không đồng nghĩa giá trị tự động xuất hiện
Năng lực thiết kế và cấu trúc hóa mới là giá trị thật
Cuối cùng chất lượng của quyết định mới là điều cốt lõi
Gọi vốn không phải bằng chứng của giá trị
Tôi hoài nghi về lập luận “code vốn luôn đắt”
Ngay cả định nghĩa của code sạch và đã được kiểm thử cũng đã mơ hồ
Nếu kiểm thử quá mức thì chi phí tăng vọt, và quy trình phê duyệt mang tính tổ chức cũng là một yếu tố chi phí lớn
LLM làm giảm chi phí ngắn hạn nhưng có thể làm tăng chi phí bảo trì dài hạn
Hồi tôi còn là thực tập sinh, tôi từng làm rẻ ở một startup, nhưng sự cố, hỏng dữ liệu và nợ kỹ thuật cứ tích tụ
Bề ngoài thì có vẻ rẻ nhưng chi phí ẩn lại rất lớn
Nhờ LLM mà giờ có vẻ như ta có thể có code chất lượng tốt với chi phí rẻ hơn, nhưng tôi vẫn đang trong quá trình thích nghi
Giờ làm v1 thì rẻ, nhưng những quyết định phức tạp của một sản phẩm trưởng thành vẫn rất đắt
Giá trị kinh tế của phần mềm nằm ở thông tin được chứa trong code
Viết code chỉ là quá trình ánh xạ thông tin đó, và chất lượng của thông tin mới là thứ quyết định giá trị thực
Việc viết code nhanh hơn không làm chất lượng thông tin tốt hơn
Nó giống như trong tư vấn, làm slide nhanh hơn không tự nhiên tạo ra giá trị
Khi tốc độ hiện thực hóa quá nhanh, mô hình tinh thần của lập trình viên sẽ lệch khỏi code
Bài liên quan: Cognitive Debt by Simon Willison
Vì tôi có thể lặp lại việc refactor rất nhanh
AI rồi sẽ ngày càng hiểu ngữ cảnh hơn, nhưng đổi lại con người sẽ phải từ bỏ dần phần phán đoán của mình
Đến lúc máy hoàn toàn nắm được ý định thì con người sẽ bị đẩy ra khỏi vòng lặp
Cốt lõi của mọi phương pháp phát triển là sự thật rằng yêu cầu luôn thay đổi
Vì thế code tốt là “code dễ thay đổi”
Tôi nghi ngờ liệu các LLM agent hiện nay có tạo ra được loại code đó hay không
Có lẽ chúng sẽ chỉ dừng ở mức prototype cho đến khi đủ đáng tin cậy hoàn toàn
Nếu đặc tả không rõ ràng thì cả kiểm thử lẫn xác minh giá trị đều trở nên khó khăn
Kể cả khi có test thì cũng chỉ có khoảng 70% chắc chắn
Nhanh hơn tự code, và kết quả cũng ra code có thể bảo trì được
Nếu nêu rõ code sạch và thực hành tốt, hoàn toàn có thể ra kết quả đủ khả năng bảo trì
Rốt cuộc vẫn là Garbage in, garbage out
Như tôi đã viết trong bài (The Final Bottleneck),
tốc độ viết code đã nhanh hơn nhưng các giai đoạn phía sau không theo kịp
Đây không chỉ là vấn đề thói quen, mà cấu trúc trách nhiệm, thiết kế ngôn ngữ và toàn bộ cấu trúc hệ thống đều phải thay đổi
Nếu năng suất thực sự tăng 10 lần thì hẳn các startup đã làm đảo lộn thị trường rồi
Có thể làm được không có nghĩa là nhất thiết phải làm
Những cách tiếp cận như AI evals(measure-first-optimize-last, ai-evals.io) đi theo hướng đó
Sự bùng nổ tính năng là điều chẳng ai mong muốn
Mỗi dòng code đều là một khoản nợ pháp lý/trách nhiệm (liability)
Trong thời đại LLM tuôn ra code, khoản nợ đó tăng vọt
Bản thân công cụ không xấu, nhưng cấu trúc mà một chương trình không có trách nhiệm đi viết lại codebase thì rất nguy hiểm
“Code rẻ” chỉ có nghĩa là việc tạo ra nó rẻ hơn, chứ chi phí phê duyệt để triển khai vẫn rất lớn
Nếu bỏ qua bước phán đoán thì đó không phải tăng năng suất mà là tạo ra khoảng trống kiểm soát (control gap)
Chỉ vì nhanh hơn mà trao chìa khóa vạn năng là rất nguy hiểm
Dù theo cách nào thì nó cũng không hề rẻ
Tôi gần như hoàn toàn đồng ý với quan điểm này
Việc viết code đã rẻ hơn, nhưng chi phí review và xác minh vẫn còn lớn
Đặc biệt trong các monorepo hàng triệu dòng, điều cốt lõi là nâng cao khả năng kiểm thử
Tôi thấy biết ơn vì kiểu thảo luận này giúp giữ sự cân bằng trong bầu không khí quá khích trên Twitter
Code churn đã trở nên dễ hơn, nhưng xác minh chất lượng trở thành thách thức mới
Những thay đổi khối lượng lớn do LLM tạo ra dẫn đến các lỗi tinh vi, và dòng chảy đó không dừng lại
Code không hề rẻ
Còn có cả chi phí token, và cấu trúc chi phí thực tế vẫn chưa rõ ràng
Dữ liệu còn thiếu vì các startup chưa có doanh thu đang độc chiếm chuỗi cung ứng GPU
LOC càng tăng thì nợ càng tăng
Khoảng cách từ ý nghĩ đến thực thi đã ngắn hơn, nhưng bản thân code vẫn là một trách nhiệm
Hiện tại còn rẻ nhờ trợ cấp, nhưng nếu chi phí phần cứng, điện năng và nhân lực giảm xuống thì có thể còn rẻ hơn nữa