Chỉnh màu hiệu: Suy nghĩ về việc chậm lại đi một chút
Tác giả nguyên bản: Mario Zechner
Dịch thuật: Peggy, BlockBeats

Chú thích biên tập viên: Trong bối cảnh trí tuệ nhân tạo sinh sản đang gia tốc vào ngành kỹ thuật phần mềm, tâm trạng ngành đang dịch chuyển từ "ngạc nhiên về khả năng" sang "lo lắng về hiệu suất". Việc viết chậm, sử dụng ít, và tự động hóa không hoàn hảo dường như tạo áp lực bị loại bỏ. Nhưng khi mã Agent thực sự được triển khai vào môi trường sản xuất, một số vấn đề thực tế hơn bắt đầu xuất hiện: lỗi được phóng to, sự phức tạp trở nên không kiểm soát, hệ thống dần trở nên không thể hiểu, việc cải thiện hiệu suất không đồng nghĩa với việc cải thiện chất lượng một cách tỷ lệ tương đương.

Bài viết này dựa trên thực tiễn trên tuyến công việc, đưa ra sự suy ngẫm nhẫn trí về làn sóng "lập mã đa năng" này. Tác giả chỉ ra rằng Agent không học từ lỗi như con người, trong môi trường thiếu các trở ngại và cơ chế phản hồi, các vấn đề nhỏ sẽ được phóng to nhanh chóng; và trong các thư viện mã phức tạp, góc nhìn cục bộ và khả năng gọi lại hạn chế của chúng, lại làm tăng thêm sự lộn xộn trong cấu trúc hệ thống. Bản chất của những vấn đề này không phải ở công nghệ chính mình, mà ở con người dưới áp lực lo lắng, họ đã quá sớm từ bỏ sự đánh giá và kiểm soát.

Do đó, thay vì rơi vào tâm trạng "phải hoàn toàn chấp nhận trí tuệ nhân tạo," hãy hiệu chỉnh lại mối quan hệ giữa con người và công cụ: cho Agent đảm nhận nhiệm vụ cục bộ, kiểm soát được, và giữ việc thiết kế hệ thống, đảm bảo chất lượng và quyết định chính là của chính mình. Trong quá trình này, "chậm lại" ngược lại trở thành một năng lực, nó có nghĩa là bạn vẫn hiểu rõ hệ thống, có thể lựa chọn, và vẫn giữ được cảm giác kiểm soát công việc.

Trong thời đại công cụ liên tục tiến hóa, thực sự khan hiếm, có lẽ không phải là khả năng sinh sản nhanh hơn, mà là khả năng đánh giá khả năng phức tạp, cũng như sự kiên định trong việc chọn lựa giữa hiệu suất và chất lượng.

Dưới đây là nguyên văn:

Khung mặt con rùa, chính là biểu cảm của tôi khi nhìn ngành này

Khoảng một năm trước, Agent mã hóa thực sự có thể giúp bạn "hoàn thành toàn bộ dự án từ đầu đến cuối" đã bắt đầu xuất hiện. Trước đó đã có các công cụ như Aider, Con trỏ sớm hơn, nhưng chúng giống hơn như trợ lý hơn là "đại diện". Các công cụ thế hệ mới rất hấp dẫn, và nhiều người dành rất nhiều thời gian rảnh để làm lại tất cả các dự án mà họ luôn muốn làm mà không có thời gian.

Tôi nghĩ điều này không vấn đề. Làm việc trong thời gian rảnh rỗi mặc dù là niềm vui, và hầu hết thời gian bạn cũng không cần quan tâm đến chất lượng mã và khả năng bảo trì. Điều này cũng cho bạn một con đường học tập về một ngăn kéo công nghệ mới.

Trong suốt kỳ nghỉ Giáng sinh, Anthropic và OpenAI cũng đã phát hành một số "định mức miễn phí", hút người vào như máy đánh bạc. Đối với nhiều người, đây là lần đầu tiên họ thực sự trải nghiệm phép màu của "Agent viết mã". Số lượng người tham gia càng ngày càng nhiều.

Hiện nay, việc viết mã cho Agent cũng bắt đầu được thực hiện vào các thư viện mã sản xuất. Sau 12 tháng, chúng ta bắt đầu thấy hậu quả của "sự tiến bộ" này. Dưới đây là quan điểm của tôi vào lúc này.

Mọi thứ đều hỏng hết

Mặc dù hầu hết chỉ là trải nghiệm, nhưng phần mềm hiện tại thực sự mang lại cảm giác "sẽ hỏng bất cứ lúc nào". 98% khả dụng, đang từ trạng thái ngoại lệ chuyển biến sang thường dạ, ngay cả dịch vụ lớn cũng không phải là ngoại lệ. Giao diện người dùng đầy rẫy các lỗi vô lý, lỗi mà đội QA ban đầu sẽ nắm bắt ngay tức khắc.

Tôi thừa nhận, tình hình như vậy đã tồn tại trước khi Agent xuất hiện. Nhưng hiện nay, vấn đề rõ ràng đang gia tăng.

Chúng ta không thể thấy được tình hình thực sự bên trong các công ty, nhưng đôi khi có thông tin rò rỉ ra ngoài, ví dụ như tin đồn về "sự cố do AI gây ra khiến Amazon Web Services (AWS) đình chỉ". Amazon Web Services sau đó đã ngay lập tức "chỉnh sửa" thông tin, nhưng ngay sau đó đã triển khai một kế hoạch tái cơ cấu trong 90 ngày.

Satya Nadella (CEO của Microsoft) gần đây liên tục nhấn mạnh rằng, ngày càng có nhiều mã nguồn trong công ty được AI viết. Mặc dù không có bằng chứng cụ thể, nhưng có vẻ như có một cảm giác: chất lượng của Windows đang giảm. Ngay cả từ một số bài đăng blog được đăng tải bởi Microsoft, họ dường như cũng chấp nhận điều này.

Các công ty tuyên bố "100% sản phẩm được tạo ra bởi AI" gần như luôn luôn mang đến sản phẩm tồi tệ nhất mà bạn có thể tưởng tượng. Không dành cho ai, nhưng rò rỉ bộ nhớ tính bằng GB, sự lộn xộn trong giao diện người dùng, tính năng không hoàn chỉnh, sự sụp đổ thường xuyên... Tất cả đều không phải là điều mà họ nghĩ là "thanh minh về chất lượng", không phải là một ví dụ tích cực của "hãy để Agent thay bạn làm mọi thứ".

Riêng tư, bạn sẽ nghe thấy nhiều hơn, cho dù là từ công ty lớn hay từ nhóm nhỏ, cùng nói một điều: họ đã bị "Agent viết mã" đẩy họ vào bước đường cùng. Thiếu kiểm tra mã nguồn, giao phó quyết định thiết kế cho Agent, và rách quá nhiều tính năng không cần thiết — kết quả không thể tốt.

Tại sao chúng ta không nên sử dụng Agent như vậy

Chúng ta hầu như đã từ bỏ mọi kỷ luật kỹ thuật và nhận định chủ quan, bước vào một cách làm việc "nghiện" hóa: mục tiêu duy nhất — tạo ra nhiều mã nguồn nhất trong thời gian ngắn nhất, không cần quan tâm đến hậu quả ra sao.

Bạn đang cố gắng xây dựng một tầng lớp biên tập để điều khiển một đội quân Agent tự động hóa. Bạn đã cài đặt Beads, nhưng hoàn toàn không biết rằng nó về bản chất gần như là một loại "phần mềm độc hại" không thể gỡ bỏ. Chỉ vì mạng nói "mọi người đều làm vậy". Nếu không làm như vậy, bạn sẽ "thất bại hoàn toàn" (ngmi).

Bạn đang tự tiêu diệt trong một vòng lặp "Matryoshka" liên tục.

Xem đi——Anthropic đã sử dụng một nhóm Agent để tạo ra trình biên dịch C, mặc dù vẫn còn vấn đề, nhưng thế hệ tiếp theo nhất định sẽ sửa chữa được, phải không?

Xem tiếp——Cursor đã sử dụng một nhóm lớn Agent để tạo ra một trình duyệt, mặc dù hiện tại gần như không thể sử dụng, vẫn cần can thiệp thủ công đôi khi, nhưng thế hệ tiếp theo nhất định sẽ xử lý được, phải không?

"Phân tán", "Phân chia để trị", "Hệ thống tự trị", "Nhà máy đen tối", "Giải quyết vấn đề phần mềm trong sáu tháng", "SaaS đã chết, bà tôi mới dùng Claw tạo Shopify"...

Những câu chuyện này nghe rất sảng khoái.

Tất nhiên, phương pháp này có lẽ thực sự "vẫn hoạt động" đối với dự án phụ của bạn gần như không có ai sử dụng (bao gồm cả bạn). Có thể, thực sự tồn tại một thiên tài, có thể sử dụng phương pháp này để tạo ra một sản phẩm phần mềm không phải là rác rưởi, thực sự được người khác sử dụng. Nếu bạn chính là người đó, thì tôi thực sự ngưỡng mộ.

Nhưng ít nhất trong cộng đồng lập trình viên xung quanh tôi, tôi chưa thấy một trường hợp nào phương pháp này thực sự hiệu quả. Tất nhiên, có thể chỉ là chúng tôi quá tệ thôi.

Lỗi tích tụ qua quá trình thiếu học tập, chật chội và phát nhanh

Vấn đề của Agent là: chúng sẽ mắc lỗi. Điều này vốn không có gì đáng ngạc nhiên, con người cũng thường mắc lỗi. Có thể chỉ là một số lỗi về tính chính xác, dễ xác định và cũng dễ sửa chữa, thêm một bài kiểm tra hồi quy sẽ tạo thêm tính ổn định. Hoặc có thể là một số lỗi về mã không hợp lý mà linter không thể nhận biết: một phương pháp không cần thiết ở đây, một loại không hợp lý ở đó, và còn mã lặp lại nữa. Những lỗi nhỏ như vậy đơn lẻ khi nhìn vào không có gì lớn lao, những lập trình viên con người cũng sẽ mắc phải.

Nhưng "máy móc" không phải con người. Sau một số lần lặp lại cùng một lỗi, con người thường sẽ học từ sai lầm và không tái phạm nữa—dù là vì bị trách mắng hoặc là do quá trình học tập thực sự.

Nhưng Agent không có khả năng học như vậy, ít nhất là theo mặc định không có. Chúng sẽ lặp đi lặp lại cùng một lỗi, thậm chí có thể "tạo ra" những kết hợp lỗi mới mẻ dựa trên dữ liệu huấn luyện.

Dĩ nhiên bạn có thể thử "huấn luyện" chúng: viết các quy tắc trong AGENTS.md, để chúng tránh mắc phải lỗi đó; thiết kế một hệ thống nhớ phức tạp, để chúng truy vấn lịch sử lỗi và nguyên tắc tốt nhất. Điều này thực sự hiệu quả ở một số vấn đề cụ thể. Nhưng điều cần thiết là—bạn phải nhận ra trước khi chúng mắc lỗi.

Một điểm khác biệt quan trọng khác là: Con người là rào cản, trong khi Đạo Đức không phải.

Con người không thể viết ra hai mươi nghìn dòng mã trong vài giờ. Ngay cả khi tỷ lệ mắc lỗi không ít, họ chỉ có thể đưa vào hệ thống một số lượng hạn chế lỗi mỗi ngày, việc lỗi này tích lũy xảy ra chậm rãi. Thông thường, khi "cảm giác đau từ lỗi" tích luỹ đến một mức độ nhất định, con người (vì bản năng ghê tởm cảm giác đau) sẽ dừng lại sửa chữa. Hoặc con người sẽ bị thay thế, và người khác sẽ đến sửa chữa. Tóm lại, vấn đề sẽ được xử lý.

Nhưng khi bạn sử dụng một bộ quân đội Đạo Đức đã được sắp xếp, không có rào cản, cũng không có "cảm giác đau". Những lỗi nhỏ ban đầu này sẽ chồng chất lên với tốc độ không thể bền vững. Bạn đã bị loại bỏ khỏi vòng lặp, thậm chí không biết những vấn đề nhỏ nhặt này, ban đầu dường như vô hại, đã trở thành một quái vật khổng lồ. Khi bạn thực sự cảm nhận được sự đau đớn, thường đã quá muộn.

Cho đến một ngày, khi bạn muốn thêm một tính năng mới, nhưng phát hiện ra kiến trúc hệ thống hiện tại (vốn đã tích tụ sai lầm) hoàn toàn không thể hỗ trợ sửa đổi; hoặc người dùng bắt đầu phàn nàn, vì lần phát hành gần đây gặp vấn đề, thậm chí mất dữ liệu.

Lúc đó bạn mới nhận ra: bạn không còn có thể tin tưởng vào tập mã này nữa.

Điều tồi tệ hơn là, hàng ngàn bài kiểm thử đơn vị, kiểm thử trạng thái, và kiểm thử cuối cùng do Đạo Đức tạo ra, cũng không còn đáng tin cậy. Cách duy nhất để xác định "hệ thống có hoạt động bình thường hay không" vẫn còn lại chỉ là kiểm thử thủ công.

Chúc mừng, bạn đã tự đào mộ cho mình (cũng như công ty).

Người Bán Độ Phức Tạp

Bạn đã hoàn toàn không biết hệ thống đang xảy ra điều gì, vì bạn đã nhường quyền kiểm soát cho Đạo Đức. Và Đạo Đức, về bản chất, đang "bán độ phức tạp". Chúng đã thấy rất nhiều quyết định thiết kế tồi tệ trong dữ liệu huấn luyện, và trong quá trình học càng mạnh họ càng củng cố những mẫu đó. Khi bạn để chúng thiết kế hệ thống, kết quả thì không thể hiệu nào.

Cuối cùng, những gì bạn nhận được là: một hệ thống cực kỳ phức tạp, xen lẫn với một loạt các bản sao kém chất lượng của "thực tiễn tốt nhất trong ngành", và trước khi vấn đề trở nên quá mức kiểm soát, bạn không hạn chế chúng.

Nhưng vấn đề chưa dừng lại ở đó. Đội Đạo Đức của bạn không chia sẻ quá trình thực thi với nhau, họ cũng không thấy toàn bộ kho mã nguồn, cũng như không hiểu rõ các quyết định trước đó của bạn hoặc các Đạo Đức khác. Do đó, quyết định của họ luôn "cục bộ".

Điều này dẫn trực tiếp đến những vấn đề đã được đề cập ở trên: mã lặp đi lặp lại nhiều, cấu trúc trừu tượng không cần thiết, các dạng không đồng nhất. Những vấn đề này ngày càng chồng chất, và cuối cùng tạo ra một hệ thống phức tạp không còn khả năng đảo ngược.

Thực tế, điều này khá giống với việc viết mã doanh nghiệp của con người. Điều khác biệt duy nhất là mức độ phức tạp đó thường là kết quả của cả nhiều năm tích luỹ: sự đau khổ được phân tán trên nhiều người, mỗi người không đạt đến ngưỡng "phải sửa", sự dung nạp của tổ chức vốn rất cao, vì vậy sự phức tạp và tổ chức kết hợp để "tiến hóa cùng nhau".

Nhưng khi kết hợp giữa con người và Agentic, quá trình này sẽ được tăng tốc đáng kể. Hai người, cộng thêm một số Agentic, chỉ trong vài tuần đã có thể đạt đến mức độ phức tạp này.

Tỷ lệ gợi nhớ của Tìm kiếm Agentic rất thấp

Bạn có thể hy vọng rằng Agentic sẽ giúp bạn "dọn dẹp sau cùng", giúp bạn tái cấu trúc, tối ưu hóa, làm cho hệ thống trở nên sạch sẽ. Nhưng vấn đề là: họ không thể làm được nữa.

Bởi vì thư viện mã quá lớn, phức tạp và họ luôn chỉ nhìn thấy một phần. Điều này không chỉ là do cửa sổ bối cảnh không đủ lớn, hoặc cơ chế bối cảnh dài trước mặt hàng triệu dòng mã không hoạt động đơn giản như vậy. Vấn đề ẩn sau đó khá tinh vi.

Trước khi Agentic cố gắng sửa chữa hệ thống, họ phải tìm thấy tất cả mã cần phải sửa đổi, cũng như các triển khai đã tồn tại có thể tái sử dụng. Bước này, chúng tôi gọi là tìm kiếm agentic (tìm kiếm Agentic).

Cách Agentic thực hiện điều này phụ thuộc vào công cụ bạn cung cấp cho họ: có thể là Bash + ripgrep, có thể là chỉ mục mã có thể truy vấn, dịch vụ LSP, cơ sở dữ liệu vector...

Nhưng dù dùng công cụ nào, bản chất vẫn giống nhau: mức độ gợi nhớ sẽ càng thấp nếu thư viện mã càng lớn. Và mức độ gợi nhớ thấp có nghĩa là: Agentic không thể tìm thấy tất cả mã liên quan, tự nhiên cũng không thể thực hiện sửa đổi đúng đắn.

Đó cũng là lý do tại sao những lỗi nhỏ nhặt ban đầu về "mùi mã" sẽ xuất hiện, nó không tìm thấy triển khai đã tồn tại, vì vậy sẽ chế tạo lại bánh xe, mang lại sự không nhất quán. Cuối cùng, những vấn đề này sẽ lan rộng, chồng chất lên nhau, tạo ra một "bông hoa" vô cùng phức tạp.

Vậy chúng ta nên làm gì để tránh tất cả điều này?

Chúng ta nên làm thế nào để hợp tác với Agentic (ít nhất là hiện tại)

Cách mã hóa Agentic giống như một linh hồn biển, với tốc độ tạo mã siêu nhanh và loại trí tuệ "đoạn trí độc nhất nhưng đôi khi thấy rất ấn tượng" làm bạn bị cuốn hút. Chúng thường có thể hoàn thành một số nhiệm vụ đơn giản với tốc độ đáng kinh ngạc và chất lượng cao. Vấn đề thực sự bắt đầu khi bạn có ý niệm như vậy - "Quá mạnh, máy tính, hãy làm giúp tôi việc!"

Việc giao nhiệm vụ cho Agentic chính xác không vấn đề gì. Các nhiệm vụ Agentic tốt thường có một số đặc điểm: phạm vi có thể được giới hạn rõ ràng, không cần phải hiểu rõ toàn bộ hệ thống; nhiệm vụ là một vòng lặp đóng, nghĩa là Agentic có thể tự đánh giá kết quả; đầu ra không nằm trên con đường chính, chỉ là một số công cụ tạm thời hoặc phần mềm sử dụng nội bộ, không ảnh hưởng đến người dùng thực sự hoặc doanh thu; hoặc bạn chỉ cần một "vịt bằng cao su" để hỗ trợ tư duy - cơ bản là đưa ý tưởng của bạn đi chạm vào kiến thức nén và dữ liệu hợp thành của internet.

Nếu thỏa mãn các điều kiện này, đây chính là nhiệm vụ phù hợp để giao cho Đại Lý, với điều kiện rằng bạn, với tư cách là con người, vẫn là người kiểm tra chất lượng cuối cùng.

Ví dụ, bạn muốn tối ưu thời gian khởi chạy ứng dụng bằng phương pháp tự nghiên cứu được đề xuất bởi Andrej Karpathy? Tuyệt vời. Nhưng điều quan trọng là bạn phải hiểu rõ rằng mã nguồn mà nó tạo ra hoàn toàn không thể sử dụng trong môi trường sản xuất. Phương pháp tự nghiên cứu hiệu quả vì bạn đã cung cấp cho nó một hàm đánh giá để nó có thể tối ưu hóa xung quanh một chỉ số nào đó (ví dụ: thời gian khởi chạy hoặc loss). Nhưng hàm đánh giá này chỉ bao phủ một chiều hẹp rất hẹp. Đại Lý sẽ mạnh mẽ bỏ qua tất cả các chỉ số không có trong hàm đánh giá, như chất lượng mã nguồn, độ phức tạp của hệ thống, và thậm chí đôi khi còn có thể bỏ qua cả tính chính xác—nếu hàm đánh giá của bạn thậm chí còn có vấn đề.

Ý tưởng cốt lõi thực sự rất đơn giản: hãy để Đại Lý thực hiện những công việc nhàm chán, những việc không giúp bạn học được điều mới, hoặc những công việc thăm dò mà bạn không có thời gian để thử nghiệm. Sau đó, bạn đánh giá kết quả, chọn ra những phần thực sự hợp lý, đúng đắn, rồi hoàn thiện việc triển khai cuối cùng. Tất nhiên, bạn cũng có thể sử dụng Đại Lý để hoàn thành bước này cuối cùng.

Nhưng điều mà tôi muốn nhấn mạnh hơn là: thật sự, hãy chậm lại một chút.

Hãy dành thời gian để suy nghĩ, bạn đang làm gì, tại sao bạn làm điều đó. Hãy tự cho mình một cơ hội nói "không," "không, chúng ta không cần điều này." Đặt một giới hạn cụ thể cho Đại Lý: cho phép nó tạo ra bao nhiêu mã mỗi ngày, số lượng này nên phù hợp với khả năng xem xét thực tế của bạn. Tất cả những phần quyết định xác định "hình dạng tổng thể" của hệ thống, như kiến trúc, API, đều nên được viết bởi chính bạn. Bạn có thể sử dụng tính năng tự động hoàn chỉnh để có cảm giác "viết mã bằng tay," hoặc cặp lập trình với Đại Lý, nhưng quan trọng nhất là: bạn phải có mặt trong mã nguồn.

Vì, viết mã một cách tự bản thân, hoặc xem mã nguồn được xây dựng từng bước một, quá trình này sẽ mang lại một loại "ma sát." Chính quy trình này của "ma sát" khiến bạn hiểu rõ hơn về mình đang muốn làm gì, hệ thống hoạt động như thế nào, cảm giác "tổng thể" như thế nào. Đây chính là nơi mà kinh nghiệm và "gu mẫu" đóng vai trò, và đây chính là những điều mà ngay cả các mô hình tiên tiến nhất hiện tại cũng chưa thể thay thế. Hãy chậm lại, chấp nhận một chút ma sát, đó chính là cách bạn học và phát triển.

Cuối cùng, bạn sẽ có một hệ thống vẫn có thể bảo trì—ít nhất cũng không tồi hơn trước khi Đại Lý xuất hiện. Đúng, hệ thống trong quá khứ cũng không hoàn hảo. Nhưng người dùng của bạn sẽ biết ơn bạn, vì sản phẩm của bạn "dễ sử dụng," chứ không phải là một đống rác được tạo ra mù quáng.

Bạn sẽ thực hiện ít chức năng hơn, nhưng đúng đắn hơn. Học cách từ chối, chính là một loại năng lực. Bạn cũng có thể ngủ ngon, bởi bạn ít nhất cũng biết hệ thống đang xảy ra chuyện gì, bạn vẫn giữ quyền kiểm soát. Chính sự hiểu biết này sẽ giúp bạn khắc phục vấn đề gợi lại của agentic search, làm cho đầu ra của Đại Lý đáng tin cậy hơn, cần ít việc sửa chữa hơn.

Khi hệ thống gặp vấn đề, bạn có thể tự mình can thiệp để sửa chữa; khi thiết kế từ đầu đã không hợp lý, bạn cũng có thể hiểu vấn đề và tái cấu trúc nó thành một dạng tốt hơn. Còn việc có Agent hay không, thực ra không quan trọng.

Tất cả điều này đều cần sự kỷ luật. Tất cả điều này đều không thể thiếu con người.

[Link bài gốc]

Chào mừng bạn tham gia cộng đồng chính thức của BlockBeats:

Nhóm Telegram đăng ký: https://t.me/theblockbeats

Nhóm Telegram thảo luận: https://t.me/BlockBeats_App

Tài khoản Twitter chính thức: https://twitter.com/BlockBeatsAsia