- AI agent không thực sự lập trình mà chỉ mô phỏng phân bố của việc lập trình, và đầu ra lỗi ngày càng khó nhận ra hơn
- Đã thử dùng nó để viết một phần của tinygrad và reverse một chip USB <-> PCIe, nhưng vẫn còn nghi ngờ rằng tự làm có thể đã tốt hơn và nhanh hơn
- Agent giúp tăng tốc tiến độ ban đầu, nhưng ở giai đoạn hoàn thiện lại khiến người ta phải dựa vào các lần thử lặp đi lặp lại như đang kéo cần gạt máy đánh bạc, và không thể đi đến đích
- Tổ chức quy mô lớn có thể chịu thiệt hại chất lượng nặng hơn cá nhân hiệu suất cao vì vòng phản hồi chậm và sản lượng gấp 10 lần nhưng không có tự kiểm tra
- AI hữu ích cho tìm kiếm và tạo prototype nhanh, nhưng khó xem là một kỹ sư phần mềm thực thụ; điều cốt lõi là biết khi nào nên dùng và khi nào không nên dùng
Phê phán cốt lõi đối với AI agent
- Xu hướng đưa AI agent vào phát triển phần mềm có thể là một sai lầm rất tốn kém, và agent gần với một mô hình thống kê tinh vi mô phỏng phân bố của việc lập trình hơn là bản thân việc lập trình
- Sản phẩm đầu ra bị hỏng, nhưng lại hỏng theo những cách ngày càng khó phát hiện hơn; mô hình thống kê càng chính xác thì những vấn đề này lại càng khó nhận ra
- Trong 6 tháng qua, tác giả đã dùng agent để viết một phần của tinygrad và reverse chip USB <-> PCIe, nhưng vẫn nghi ngờ rằng nếu tự làm thì có thể đã tốt hơn và nhanh hơn
- Agent đẩy nhanh tiến độ giai đoạn đầu, nhưng ở bước hoàn thiện lại khiến người ta liên tục hy vọng kết quả sẽ tốt lên như đang kéo cần gạt máy đánh bạc, và rốt cuộc không thể hoàn tất đến cùng
- Vì đã thử nhiều model, harness và prompt khác nhau, nên phản biện kiểu “bạn dùng sai cách rồi” không mấy thuyết phục, và nghe khá giống với việc bảo rằng chỉ cần đặt cược theo một cách nhất định thì sẽ thắng máy đánh bạc
- Bản thân AI vẫn hữu ích; trong nhiều truy vấn tìm kiếm, nó hoạt động như một Google tốt hơn, và với các prototype nhanh không quá bận tâm đến độ hoàn thiện thì nó rất nhanh
- Tuy vậy, rất khó xem nó là một kỹ sư phần mềm, và nó cũng không gần với tiêu chuẩn của bất kỳ công ty nào mà tác giả từng làm việc cùng; điều quan trọng là biết khi nào nên dùng và khi nào không nên dùng
Tác động lên tổ chức và chất lượng
- AFL tìm được nhiều bug hơn LLM, nhưng các lập trình viên không sợ mất địa vị vì thế; cờ vua và Go cũng trở nên phổ biến hơn sau AI, nên khó coi các phê phán AI chỉ đơn thuần là nỗi bất an về địa vị
- Tương lai nơi một trợ lý robot đáng tin cậy giúp dọn dẹp code là điều đáng mong chờ, nhưng có vẻ nỗi sợ mất mát đang bị tận dụng để bán agent theo cách khiến các công ty lớn phải hành động
- So với cá nhân hiệu suất cao hay tổ chức nhỏ, tổ chức quy mô lớn có khả năng chịu thiệt hại nặng hơn từ agent
- Người có hiệu suất cao có thể sửa lỗi, thường nhận ra khi sản phẩm đầu ra cẩu thả, và trừ phi phạm vi rất hạn chế thì họ vẫn duy trì cách làm là đọc kỹ và hiểu từng dòng
- Tổ chức lớn có vòng phản hồi chậm và sự đồng bộ yếu, nên khi người hiệu suất thấp tạo ra sản lượng gấp 10 lần bằng agent mà không tự kiểm tra, chất lượng đầu ra trung bình có thể giảm xuống
- Agent sẽ tạo ra nhiều code, app và tính năng hơn trước, nhưng đây có thể là một thời đại chất đầy sản phẩm đầu ra cẩu thả hơn là những viên ngọc chất lượng cao
- Câu chuyện Apple đang thúc đẩy mọi kỹ sư dùng AI nên được nhìn qua những câu hỏi cụ thể như “trong 2 năm tới macOS sẽ tốt hơn hay tệ đi” thay vì những kỳ vọng trừu tượng
- Con người ngầm giả định rằng đằng sau một sản phẩm đầu ra là một trạng thái tinh thần và quá trình mang tính con người, nhưng với đầu ra AI thì giả định này không còn đúng nữa
- Những yếu tố từng được dùng làm chỉ báo thay thế cho chất lượng trong quá khứ như ngữ pháp và cú pháp trở nên kém hữu ích trước đầu ra AI, và sự khác biệt lộ ra khi tương tác theo cách của con người hoặc xây dựng thứ gì đó dựa trên nó
- Về LLM, tác giả ngày càng nghiêng về lập trường LeCun/Marcus, dẫn đến kết luận rằng các mô hình này không thể lập trình và quá trình mới là điều quan trọng
- Deep learning vẫn có thể là lời giải, nhưng để tạo ra agent lập trình thực sự thì cần world model, chứ không phải kiểu RLVR mà trong đó nó comment out failing test rồi nói rằng mọi test đều đã pass
- Điều cốt lõi của thời đại này có thể là ai sẽ trụ vững mà không tự làm hại chính mình giữa cơn quá nhiệt tập thể quanh AI
1 bình luận
Ý kiến trên Hacker News
Vấn đề lớn của diễn ngôn hiện tại là nó quá trắng đen. Nghi ngờ LLM thì bị xem là Luddite, còn tin tưởng thì thành kiểu “ai pilled”
Trong đa số trường hợp, LLM đưa bạn đi được khoảng 80~95%, đôi khi ít hơn hoặc tốt hơn mức đó. Thỉnh thoảng nó cũng dẫn bạn đến một hướng hoàn toàn sai
Nhưng mọi người dường như chỉ cãi nhau xem liệu LLM có thể một mình trong tủ đồ trở thành một kỹ sư phần mềm hoàn hảo hay không, rồi dựa vào đó mà phủ nhận cả những khả năng rất lớn ở các kịch bản khác
Nếu nghĩ đến việc chỉ riêng Internet thôi đã có thể giúp phần lớn tổ chức năng suất hơn hiện tại đến mức nào, thì các công ty thực tế thường còn không làm nổi một phần rất nhỏ trong số những gì có thể làm. Tôi cũng nhìn LLM theo góc đó
Lỗi không nằm ở mô hình ngôn ngữ mà ở chính chúng ta
Ban đầu, Luddite chủ yếu là những người phản đối các cỗ máy dùng để làm ra hàng hóa chất lượng thấp một cách “gian trá và lừa bịp”, lách các tiêu chuẩn lao động và cướp đi kế sinh nhai của những người thợ lành nghề
Tôi không dùng agent, mà viết phần mềm ở cấp độ hàm thông qua giao diện chat đơn giản và các cuộc hội thoại nối tiếp. Workflow tạo ra khá “lai ghép”, và hưởng lợi rất nhiều từ kinh nghiệm cùng chuyên môn của tôi. LLM chỉ làm cho quá trình mượt hơn thôi
Với tôi, cách này đang hoạt động tốt và tôi không muốn quay lại như trước
Những người ngày nay bị gọi là “Luddite” phần lớn chỉ là những người dám nghi ngờ sự cường điệu quanh “AI”. Thường thì họ cũng chẳng phải nhà hoạt động gì
Với mức năng lực AI hiện tại, cá nhân tôi thấy hữu ích khi xem nó gần giống một công cụ tìm kiếm rất tốt hoạt động trên nền tri thức sẵn có. Nó giống bước tiếp theo của khả năng tìm kiếm, đi từ sách tham khảo sang Stack Overflow rồi GitHub
Lập trình viên là một trong những nghề phải tái sử dụng và tái phát minh cùng một kỹ thuật thường xuyên hơn hầu hết mọi nghề tôi có thể nghĩ ra, nên vốn đã rất hợp với một công cụ tìm kiếm cực giỏi về prior art. Việc AI có thể điều chỉnh prior art đó cho phù hợp với một use case cụ thể khiến nó còn mạnh hơn nữa
Nhưng cũng như việc nối các mẩu code copy từ Stack Overflow lại với nhau không tạo ra thành công lớn, AI hiện tại cũng chưa thể xây dựng trọn vẹn một dự án hoàn chỉnh
Nếu là một codebase legacy cũ kỹ và không mấy được dùng, bạn có thể để AI agent đọc code, ví dụ hỏi “ứng dụng X làm Y như thế nào”. Nhưng tôi sẽ không để nó tự tung tự tác tạo tính năng hay giao cho nó việc refactor
Làm vậy sẽ tạo ra quá nhiều commit và gây hỗn loạn cho đội phát triển, rất có thể còn tệ hơn đống hổ lốn mà họ vốn đã phải xử lý. Dạo này tôi hơi thất vọng về AI, và cách mô tả này tóm tắt trải nghiệm của tôi rất đúng
Điều khó nhất trong kỹ nghệ phần mềm là giải đúng bài toán cần giải. Tôi cho rằng khả năng xác định bài toán nào cần được giải là yếu tố phân biệt các kỹ sư senior hàng đầu
Đơn giản hóa thì đó là bài toán mà khi giải xong, giá trị nó bổ sung cho sản phẩm là lớn nhất so với độ phức tạp và chi phí phụ đi kèm
Từ lâu tôi từng làm ở một sản phẩm web, nơi một junior designer ban đầu nghĩ rằng sẽ hay nếu backend có thể được quản lý bằng các công cụ LDAP. Thế là schema và cấu trúc cơ sở dữ liệu của sản phẩm bắt chước OpenLDAP và dùng các khóa CN phức hợp, khiến toàn bộ codebase phải xử lý cấu trúc đó mỗi lần đọc ghi DB. Khi thiết kế schema DB, khả năng tương thích LDAP không phải là đúng bài toán cần giải
Phần mềm giải đúng bài toán đôi khi khó nhận ra, vì cách nó hoạt động trông quá hiển nhiên, nên người ta khó thấy rằng đáng lẽ đã có thể chọn một thiết kế khác
Theo thời gian, thứ thường giới hạn bán kính nổ của những thiết kế đang giải sai bài toán là ma sát mà chính các thiết kế đó tạo ra. Việc phát triển chậm lại, và cả việc tiếp tục phát triển thêm để giải nhiều bài toán sai hơn cũng chậm theo. Đó là một cơ chế tự giới hạn
Đây chính là điều khiến tôi đặc biệt lo về các LLM coding agent. Chúng che lấp lớp ma sát đó. Không sửa vấn đề mà chỉ đẩy chi phí sang phía sau
Vì thế sẽ xuất hiện những codebase có độ phức tạp tăng vô hạn so với giá trị mà chúng mang lại, và không còn cơ chế nào để kiểm soát
Người mới sẽ không trải qua vòng phản hồi giúp họ rèn được trực giác kỹ thuật và gu phán đoán xem trong một thiết kế cụ thể, bài toán nào mới là bài toán đúng cần giải
Ở quy mô toàn ngành, có khi chúng ta còn quên mất rằng từng tồn tại khái niệm giải đúng bài toán
Tôi không biết phải làm sao nữa. Có lẽ nên lập kế hoạch nghỉ hưu sớm thôi
Hiện nay có những người mua peptide chợ xám, rồi tự tiêm những chất được ghi là “không dùng cho người” chỉ dựa vào vài giai thoại đáng ngờ và cảm giác chủ quan. Kiểu như để làm da đẹp hơn và tăng cơ
Họ có đột nhiên biến thành zombie hết không? Không. Họ có thực sự biết vài năm nữa cơ thể mình sẽ ra sao không? Cũng không. Nó có thể dẫn đến thảm họa không? Có thể lắm
Khi nghĩ đến việc trong khoảng 6 tháng gần đây, cả ngành đã chuyển hướng dữ dội sang dùng AI làm công cụ tạo mã chính, tôi lại nhớ tới phép so sánh này. AI là peptide, còn codebase là cơ thể. Theo nghĩa đen, không ai biết cách này sẽ bảo trì được đến mức nào. Đơn giản là vì vẫn chưa đủ thời gian để biết
Có thể sẽ ổn, cũng có thể sẽ thành một mớ hỗn độn hoàn toàn. Cả đội ngũ kỹ sư có thể buông tay rồi ngủ quên, ngộ nhận rằng mình hiểu mình đang xây cái gì dù thực ra không hiểu, và đến lúc LLM không còn gánh nổi nữa thì cũng chẳng còn đủ năng lực để sửa hay bảo trì
https://www.bbc.co.uk/news/articles/cdr268m5pxro
Với codebase cá nhân của tôi, nếu không phải là trường hợp thực sự không quan tâm đến khả năng bảo trì hay tuổi thọ thì tôi không làm vậy nữa
Hiện tại tôi đang ở phía “đã không tự viết code một thời gian”. Tôi muốn thấy một ví dụ mà vấn đề đủ lớn để quay lại viết tay
Vấn đề chính của tôi là chất lượng lên xuống thất thường theo từng đợt phát hành model, và đặc biệt là xu hướng nhét API hoặc tài liệu cũ vào, nhất là trong các công cụ dòng lệnh
Tôi hiểu việc model vật lộn với một codebase nguyên khối cả triệu dòng tích tụ rác suốt 10 năm. Nhưng với codebase mới thì tôi không hình dung nổi vì sao nó lại khổ sở đến vậy
Việc code không khó đến thế, nên nhiều khi tự code còn dễ hơn là đọc và viết tiếng Anh. Dù vậy, có thể tôi bị thiên lệch vì chỉ dùng Haskell
Một trong những rủi ro của quản lý kỹ thuật là nó có thể biến bạn thành người không còn làm được việc đó nữa
Nhưng điều đó có thực sự quan trọng không?
Dù vậy, tôi vẫn lạc quan hơn tác giả một chút. Tôi có cảm giác vẫn có thể quản lý quy trình để ngăn chuyện đó xảy ra
Môi trường thực thi tác tử mới chỉ xuất hiện hơn 1 năm, và chỉ mới khá đáng tin cậy được khoảng nửa năm mà đã thấy mệt mỏi lớn. Theo tôi, điều này cho thấy sự bào mòn tinh thần của lập trình có AI hỗ trợ nhiều hơn là câu hỏi liệu LLM có thật sự biết lập trình hay không
Để theo dõi cho kịp việc tác tử đang làm gì với codebase, tần suất ra quyết định tăng vọt, và bạn phải đọc một lượng mã nguồn lẫn văn bản khổng lồ
Sự mệt mỏi mang tính cá nhân và tâm lý này, cùng với cảm xúc tiêu cực đi kèm, đang bị chuyển hóa một cách thiếu chính xác thành cái nhìn bi quan về tiềm năng phát triển của chính công nghệ
Nếu tất cả những người dùng nó đúng cách đều thấy nản, còn những người thích nó thì lại chất thành núi những mớ tạp nham không thể bảo trì, thì chẳng bao lâu nữa chúng ta sẽ vứt nó vào sọt rác của lịch sử
Có rất nhiều thứ “có tiềm năng”, nhưng rốt cuộc cũng có vô số thứ chẳng trở thành gì cả
Tôi vẫn sẽ tiếp tục dùng LLM, nhưng theo tôi, tính hữu dụng của kiểu viết code dạng tác tử có lẽ đã qua đỉnh rồi
Một phần công việc của tôi là tìm cách biến các mô hình kiểu này thành công cụ hữu ích trong tập đoàn lớn nơi tôi đang làm. Nó gần giống như ném cà chua vào tường, và ở một mức độ nào đó tôi cũng thấy một vấn đề dường như là đầu ra của chúng có những giới hạn nhất định như anh ấy nói
Đồng thời, trong bài viết của anh ấy không hề có đoạn mã hay hiện vật cụ thể nào để bám vào kiểu như “mô hình đã làm rất tệ ở đây và lẽ ra phải làm thế này”. Cách phê bình này trông giống một mô thức lặp đi lặp lại trong các bài blog và Twitter kiểu “LLM hoàn toàn không dùng được”
Rõ ràng các mô hình làm tốt hơn tự động hoàn thành, và trong công việc phát triển hằng ngày của tôi chúng còn tạo ra được những phần lớn của codebase mà một kỹ sư junior hoặc tầm trung có thể đã viết
Nếu không ai trích dẫn cụ thể chúng thực sự mắc lỗi gì, thì làm sao chúng ta có thể nắm được năng lực thực tế?
Nó gần như luôn tạo ra mã chạy được, và thường cũng làm được việc bạn yêu cầu. Nhưng nó hơi sai theo những cách cực kỳ bực bội khiến bạn muốn quăng ghế. Hơn nữa, nó còn không có nổi gu để nhận ra cái gì sai và sai như thế nào
Vậy thì nêu ví dụ cụ thể cũng không được, mà không nêu ví dụ cụ thể cũng không được. Thế thì coi như game over
Tôi biết mình đang phạm lỗi quy kết cho cả tập thể, nhưng ý tôi vẫn là vậy
Chắc chắn phải có những tài liệu như vậy, nên nếu ai biết nội dung nào có ví dụ hay thì mong được chỉ giúp
Tôi không nghi ngờ chuyện nhóm coder top vài phần trăm viết tốt hơn Claude hay Codex rất nhiều. Nhưng tôi tò mò không biết chúng kém hơn bao nhiêu so với một lập trình viên trung bình bình thường
Theo tôi đoán thì các mô hình sẽ tiếp tục tốt lên
Khi tôi bắt đầu làm kiểu agentic coding từ 1~2 năm trước, tôi tin chắc nó chỉ hữu ích ở mức tự động hoàn thành. Đầu năm nay đã có chuyện gì đó xảy ra khiến các mô hình đạt tới một mức năng lực mới
Giờ thì ai tôi biết cũng đang làm agentic coding, và điều đó thực sự đáng kinh ngạc. Tôi nghĩ phải đẩy nó xa nhất có thể. Cảm giác như sự tăng tốc của nhân loại đang ở ngay trước mắt
Trong 2 năm qua đã có khoảng 6GW trung tâm dữ liệu mới được công bố, nhưng thực tế đi vào hoạt động và bắt đầu cung cấp dịch vụ thì chưa tới 1GW. Lịch giao hàng của phần còn lại cứ tiếp tục bị lùi
Hơn nữa, các trung tâm dữ liệu nói như thể số chip bên trong sẽ trụ được 6 năm, nhưng điều đó cũng đang lộ ra là không thực tế
Tôi mong mọi người thôi nói kiểu “sự tăng tốc của nhân loại”. Không có ai đang giải quyết ung thư, biến đổi khí hậu, bất bình đẳng hay những vấn đề thực tế quan trọng khác bằng LLM cả
Nếu công nghệ này đủ ổn để tăng năng suất cho bạn, thì đó là vì bạn không làm việc gì mới, tiên phong hay mang tính đổi mới. Lý do duy nhất LLM biết làm công việc của bạn là vì đoạn mã đó đã được viết ra theo nghĩa đen đủ nhiều lần để xuất hiện đầy đủ trong dữ liệu huấn luyện
Hãy thử dùng LLM để viết C++26, HDL, hoặc một stack cực kỳ ngách, bạn sẽ được kiểm tra lại thực tế
Không phải AFL tự nó tìm ra nhiều lỗ hổng hơn LLM. AFL và các chuyên gia giàu kinh nghiệm trong thực tế mới là bên tìm ra lỗ hổng
AFL gây ra lỗi, và khá nhiều hoặc thậm chí phần lớn trong số đó không thể khai thác được. Con người, và giờ là agent, phải sàng lọc và đánh giá chúng
Hơn nữa, việc đó diễn ra trên một kho phần mềm không an toàn bộ nhớ từ thời trước AFL. Thời hoàng kim của AFL là 10 năm trước, còn bây giờ mọi mục tiêu đều đã khó hơn
Bổ sung thêm bối cảnh, tác giả là George “geohot” Hotz. Anh ấy có một lịch sử exploit dài, và có lẽ điều nổi tiếng nhất là đã gần như làm comma.ai cho xe tự lái theo kiểu vibe coding với ngân sách thấp từ rất lâu trước khi AI vibe coding thực sự xuất hiện
https://en.wikipedia.org/wiki/George_Hotz