Tương lai của lập trình tự hành: Khi codebase tự vận hành chính mình

Các AI agent hiện nay có thể "một phát ăn ngay" những trò chơi thực sự thú vị. Với hàng rào bảo vệ phù hợp, chúng có thể thực hiện những cuộc di trú cực kỳ ấn tượng trong các codebase phức tạp, thậm chí viết lại toàn bộ sang ngôn ngữ mới. Nhưng gần như mọi công việc phần mềm "thực thụ" vẫn do kỹ sư con người dẫn dắt. Vậy làm sao để phần lớn công việc được xử lý thay chúng ta mà không cần ta phải để mắt tới?

Chu kỳ kỳ vọng của công nghệ

Đáng lẽ agent phải có khả năng tự xây dựng toàn bộ hệ thống phần mềm. Vậy tại sao thực tế lại diễn ra tồi tệ đến vậy? Những nguyên thủy (primitive) mới nào chúng ta cần để mọi thứ vận hành trơn tru? Và điều này có thể đi xa đến đâu?

Sau cơn sốt "tokenmaxxing" là gì?

Rất nhiều tổ chức kỹ thuật đã dành nửa đầu năm nay để đẩy càng nhiều việc càng tốt cho những đội quân agent và các vòng lặp đối kháng. Kết quả khá thất vọng: những núi code đáng ngờ chất đống, nhưng chẳng có cơn sóng thần phần mềm tuyệt vời nào xuất hiện. Lợi tức đầu tư (ROI) cho lượng token khổng lồ đó, nói thẳng ra, rất mờ mịt.

Nói theo ngôn ngữ chu kỳ kỳ vọng, chúng ta đang ở đáy của sự vỡ mộng. Chúng ta đang loay hoay tìm cách hiện thực hóa viễn cảnh không tưởng mà ta mơ ước vài tháng trước, nhưng đến nay vẫn chưa thành hiện thực trong thực tế.

Vậy điều gì xảy ra tiếp theo? Trong mọi chu kỳ ứng dụng công nghệ trước đây, câu trả lời luôn là: tìm ra các phương pháp tốt nhất, xác định xem công cụ mới sáng bóng của ta phù hợp để đóng đinh vào chỗ nào thay vì dùng nó đập nát con ốc vít, rồi tạo ra những khối xây dựng mà ta không nhận ra là cần thiết cho đến khi cầm món đồ chơi mới trên tay.

Một cách chẩn đoán hữu ích để tiến tới đó là tự hỏi: khi phần mềm chủ yếu tự vận hành, kỹ sư sẽ làm gì?

Câu trả lời phổ biến là: thiết lập các vòng lặp (loop)! Xưa ta viết code, rồi ta viết prompt, giờ ta dựng các vòng lặp agent và gõ /goal thật nhiều.

Tôi cho rằng đây là một sai lầm. Hiện tại, việc thiết lập một vòng lặp phần mềm khả thi, tạo ra thay đổi phần mềm có lợi ròng mà không đốt tiền, là một đống việc khổng lồ — nhưng chủ yếu là vì chuỗi công cụ chưa sẵn sàng. Khi có đủ các mảnh ghép phù hợp, những vòng lặp này sẽ dễ dựng, dễ tin cậy và hiệu quả về chi phí. Đó sẽ không phải là nơi ta dồn thời gian.

Thay vào đó, công việc kỹ thuật giá trị nhất sẽ là có ý tưởng hay. Những ý tưởng quan trọng vẫn đến từ bên ngoài nhà máy phần mềm. Thực ra, mục đích của cả cỗ máy này là giảm thiểu số thứ ta phải bận tâm mà không mang lại lợi ích cao.

Tính năng sát thủ vẫn tạo nên công ty. Cursor Tab, tính năng chỉnh sửa bản ghi của Descript, hay OpenRouter trừu tượng hóa các nhà cung cấp suy luận sau một giao diện thanh toán chung — đều là những ý tưởng tạo dựng công ty. Ngoài sáng tạo, ý tưởng hay còn đòi hỏi sự thấu hiểu vấn đề và chuyên môn lĩnh vực, và kỹ sư sẽ cần đóng góp vào quá trình đó.

Kiến trúc sát thủ vẫn có đòn bẩy cao. Một sự đơn giản hóa đúng đắn vẫn tiết kiệm được vô khối phức tạp về sau, biểu hiện ở ít lỗi hơn và việc lặp sản phẩm dễ dàng hơn. Chỉ cần nghĩ trước một chút là những tính năng giá trị cao sẽ trở nên dễ hái về sau. Vẫn còn rất nhiều giá trị trong việc xây dựng mô hình dữ liệu đúng đắn hơn, thêm hàng đợi đúng chỗ, hay tạo giàn giáo cho cách kiểm thử sản phẩm tốt hơn.

Phần nào nên tự hành?

Ngoài lĩnh vực "có ý tưởng hay", chúng ta nên cố gắng chuyển công việc codebase sang GPU. Ví dụ, liệu agent có thể đảm nhận trọn vẹn những việc sau?

• Phát hiện và sửa hầu hết lỗi. Tính năng mới không hoạt động đúng khi người dùng đăng nhập qua SSO. Xóa hàng loạt không cập nhật bộ đếm dòng ở đầu trang như xóa từng cái. Agent nên bắt được những lỗi này và sửa giúp ta. Phần lớn lỗi thường có ngữ nghĩa rõ ràng — ta không cần kỹ sư con người phân xử phần mềm phải hoạt động ra sao, thậm chí có thể không cần tài liệu hay đặc tả nào.
• Gỡ lỗi trong production. Khi một lỗi xuất hiện, agent nên tương quan nó với một commit gần đây, thay đổi lưu lượng, khác biệt hạ tầng hay điều kiện bất ngờ, rồi thường là vá giúp ta. Backend về cơ bản không bao giờ nên ném lỗi 500 nữa. Log console trên trình duyệt gần như phải sạch lỗi.
• Tối ưu hóa agent. Chúng ta thực sự cần viết bao nhiêu prompt cho agent? Liệu các nền tảng như Braintrust, Raindrop, Arize hay Langfuse có thể cô lập những bệnh lý phổ biến của agent, đề xuất cập nhật, kiểm thử ngược và triển khai chúng?
• Nhất quán frontend. Ngôn ngữ thị giác của bất kỳ ứng dụng nào phải mạch lạc nội bộ. Ứng dụng nên dùng font, màu sắc, biểu tượng, khoảng cách nhất quán. Hệ thống thiết kế nên tự khởi tạo và tự thực thi, với con người đưa ra quyết định xác nhận.
• Độ bóng bẩy của ứng dụng. Ứng dụng nên cư xử theo cách người dùng mong đợi. Ctrl-click phải mở liên kết trong tab mới. Nút bị vô hiệu hóa phải có giải thích lý do. Trường biểu mẫu phải được giữ lại khi tải lại. Giao diện phải hiển thị hợp lý trên di động, điều hướng được bằng trình đọc màn hình. Có hàng tá kỳ vọng chất lượng cuộc sống cơ bản như vậy.
• Tối ưu hóa tăng trưởng. Lặp đi lặp lại việc chuyển đổi biểu mẫu, tối ưu onboarding, sản xuất hàng loạt trang marketing. Có những cẩm nang thí nghiệm hoạt động khá tốt, và agent nên chạy những cẩm nang đó thay ta.

Điều này không có nghĩa là tăng trưởng đã chết — nó còn sống mạnh hơn bao giờ hết! Nhưng công việc sẽ trông giống những mưu kế và vụ cướp hơn là tối ưu CTA. Đội tăng trưởng đặt mục tiêu, agent lặp lại không chỉ dựa trên code mà dựa trên thực tế bằng cách đưa thay đổi tới người dùng và học hỏi, còn tất cả chúng ta tập trung vào những ý tưởng tầm cao hơn.

Danh sách còn dài. GitHub Copilot cho ta tự động hoàn thành từng dòng code, còn agent sẽ cho ta tự động hoàn thành cả sản phẩm.

Những nguyên thủy còn thiếu

Nếu muốn mọi thứ thành công, ngăn xếp phát triển sẽ cần một số nguyên thủy mới. Tất cả đều sẽ là điều kiện tối thiểu:

• Môi trường phát triển dễ đọc với agent. Các lỗi, phần lớn, đến từ những vùng mà agent không thấy được. Nếu ứng dụng của bạn có tích hợp bên thứ ba mà agent không thể vận hành từ đầu đến cuối, những tích hợp đó sẽ có lỗi. Nếu repo không có thiết lập trình duyệt cho agent tốt, toàn bộ frontend là vùng xám nơi agent bay mù. Và cứ thế.
• Bộ nhớ toàn cục. Việc agent mắc nhiều sai lầm ngớ ngẩn thực ra vẫn ổn. Điều không ổn là chúng cứ lặp lại cùng một sai lầm. Nếu bạn phải nói với agent rằng bảng audit log chỉ ghi thêm, không bao giờ được cập nhật tại chỗ, thì ổn — nhưng nếu sau đó bạn phải nói điều này với từng agent chạm vào khu vực đó, bạn lại quay về vòng lặp làm việc cấp thấp. Bất kỳ hệ thống bộ nhớ nào ta tạo ra cũng cần hoạt động xuyên suốt chuỗi công cụ. Khi bạn mắng một bot SRE vì thực hiện thao tác production không an toàn, agent cần hiểu lý do, và mọi agent tương lai đều phải biết về sự điều chỉnh đó.
• Phòng chống thối rữa codebase. Agent có để lại code chết không? Có năm cách làm một việc mà lẽ ra chỉ nên có một? Hệ thống kiểu dữ liệu có trực quan không? Mô hình dữ liệu có khớp với sản phẩm ta muốn giao không? Cần một thứ gì đó xử lý tất cả những điều này, nếu không codebase sẽ bắt đầu xoáy trôn ốc.

Chúng ta vẫn cần phần lớn các nguyên thủy từ kỷ nguyên trước, ví dụ APM (nhưng sẽ chủ yếu được agent truy vấn bằng cách đọc log, chứ không qua giao diện nhiều widget), CI (nhưng với hàng đợi hợp nhất tốt hơn) và kiểm thử A/B (nhưng do agent vận hành).

Làm sao xây dựng ngăn xếp phát triển dễ đọc với agent?

Nơi các đội kỹ thuật cần làm rất nhiều việc lúc này là tạo ra những môi trường phát triển đám mây thật tốt, giúp agent dễ dàng vận hành code theo mọi cách cần thiết trước khi có thể biết liệu nó có lỗi hay không. Ở thời điểm này, yếu tố giới hạn của agent phát triển là môi trường chúng hoạt động, chứ không phải bản thân mô hình và giàn khung.

Nói cách khác: agent đã đủ giỏi để làm nhiều việc hơn rất nhiều, nếu chúng hoạt động trong môi trường đủ tốt. Nhưng chúng tạo ra lỗi ở nơi chúng không thấy: các điều kiện tranh chấp (race condition) mà agent không có cách tái hiện một cách hệ thống, những truy vấn chậm nơi chúng mù tịt về hình dạng dữ liệu.

Ở nơi agent có điểm mù, chúng mắc lỗi, điều này giới hạn niềm tin, nghĩa là công việc cần được xem xét kỹ lưỡng hơn, và điều đó giới hạn mức độ ta có thể bàn giao. Vì vậy, khoản đầu tư quan trọng nhất mà một đội kỹ thuật có thể làm lúc này là khiến môi trường phát triển của họ cực kỳ thân thiện với agent.

Nhưng hiện tại đó là một hố sâu không đáy gồm những việc lặt vặt và xử lý riêng lẻ, không có cách định lượng bạn đang làm tốt đến đâu. Cần ý tưởng hay và kỹ thuật tập trung để lấp những khoảng trống môi trường phát triển này. Một thiết lập phát triển cục bộ với dữ liệu kiểm thử đại diện là một mục tiêu luôn dịch chuyển.

Công việc này cũng đặc thù theo từng codebase, và vẫn là một nghệ thuật mà rất ít người làm giỏi. Đó là một lý do khiến nhiều nhà máy phần mềm thất vọng đến vậy. Chúng ta cần những cách tốt hơn nhiều để thực hiện kiểu đầu tư này.

Điều đó nghĩa là có rất nhiều đòn bẩy trong việc giúp các đội đưa chuỗi công cụ phát triển của họ sẵn sàng cho agent. Làm sao một đội kỹ thuật biết đâu là quả ngọt dễ hái? Họ nên ưu tiên công việc thế nào để nhà máy của họ hoạt động tốt hơn? Làm sao biết mình đang làm tốt? Nếu biến việc này thành khoa học thay vì nghệ thuật, và giúp các đội kỹ thuật tiến bộ có phương pháp, các nhà máy sẽ bắt đầu rền vang.

Đây là phỏng đoán tốt nhất của chúng tôi về con đường phía trước:

1. Khai thác codebase để tìm lỗi. Trở nên thật giỏi trong việc chọn ra những lỗi quan trọng.
2. Sửa lỗi. Theo dõi những khoảng trống khiến việc xác nhận bản vá đúng đắn, hoặc xác nhận lỗi có thật ngay từ đầu, trở nên khó khăn.
3. Dùng dấu vết từ việc sửa lỗi để ưu tiên công việc cần làm nhằm khiến codebase dễ chịu hơn với agent.

Nói cách khác: kế hoạch bí mật của Detail là tạo ra một sản phẩm tự khởi động công việc của chính nó, rồi dùng công việc đó để giúp các đội kỹ thuật biết nên đầu tư vào đâu và hiệu quả ra sao.

Nếu ta có thể khởi động một kho công việc hữu ích cho bất kỳ codebase nào — trong trường hợp này là những lỗi mà đội kỹ thuật muốn được sửa — ta có thể dùng nó để xác định những cách có ROI cao nhằm làm codebase tốt hơn cho agent. Ta có thể đánh giá mức độ sẵn sàng cho agent của một repo. Kỹ sư có thể cày cuốc lấp những khoảng trống quan trọng trong môi trường phát triển cho đến khi gần như mọi lỗi cấp thấp có thể được xử lý tự động, rồi tập trung vào công việc giá trị thực sự: có ý tưởng hay cho tính năng và tìm ra những trừu tượng hóa giúp đơn giản hóa việc triển khai.

Đó là cách ta đạt tới "cao nguyên năng suất", và đó là cách những đội kỹ thuật tốt nhất sẽ vận hành trong sáu tháng tới. Không phải tokenmaxxing, chắc chắn cũng không phải cấm AI, mà là dùng một quy trình như thế này để leo dốc mức độ sẵn sàng cho agent và dần dần bàn giao ngày càng nhiều công việc.

Điều này không mới

Công nghệ tiến bộ bằng cách bàn giao những mối bận tâm cấp thấp hơn cho các hệ thống quản lý chúng thay ta.

Vào thập niên 2010, chúng ta chuyển phần mềm lên đám mây, và giờ không phải bận tâm nó chạy ở đâu về mặt vật lý, hay thậm chí dịch vụ nào chạy trên máy ảo nào. Một đội kỹ thuật nhỏ hơn, tập trung hơn, giờ có thể xây dựng một sản phẩm phần mềm thành công. Chúng ta được sống trong mặt phẳng logic trong khi các nền tảng lo phần còn lại. Nhưng chúng ta đã đi qua một cuộc chuyển đổi tương tự rất lộn xộn lúc ban đầu, và phải loay hoay tìm ra nhiều nguyên thủy còn thiếu trên đường đi.

Xưa kia, thiết lập CI và CD là dự án kéo dài nhiều tháng, nhưng giờ khi đã có nguyên thủy phù hợp và công cụ trưởng thành, nó chỉ là công việc của một buổi chiều — trừ khi bạn đang di trú mainframe của ngân hàng hay đại loại thế. Một cuộc chuyển đổi tương tự sẽ diễn ra với các "vòng lặp".

Công nghệ tiến bộ bằng cách bàn giao những mối bận tâm cấp thấp cho các hệ thống tự quản lý chúng. Lập trình tự hành là bước tiếp theo trong hành trình đó.

Đối với độc giả Việt Nam, xu hướng này đặc biệt đáng lưu ý: các đội kỹ thuật trong nước vốn thường mỏng nhân sự so với khối lượng công việc, nên tiềm năng của agent tự hành càng lớn. Tuy nhiên, bài học cốt lõi vẫn là đừng chạy theo số lượng token đốt ra, mà hãy đầu tư vào hạ tầng và môi trường phát triển để agent thực sự hoạt động hiệu quả. Đây là khoản đầu tư chiến lược, không phải một cuộc đua ngắn hạn.