Nhiều người nói rằng AI sẽ giúp việc phát triển phần mềm trở nên rẻ hơn nhiều. Họ tưởng tượng các mô hình sẽ thay thế kỹ sư, hoàn thành các tác vụ chỉ trong vài phút. Câu chuyện đó nghe rất hấp dẫn, nhưng không hoàn toàn đúng. Kinh tế học của việc xây dựng phần mềm đã thay đổi, chứ không hề biến mất. Nợ kỹ thuật (technical debt) không hề bốc hơi khi trợ lý lập trình đầu tiên ra mắt. Chúng ta chỉ đơn giản là tìm thấy một cách mới để chi trả cho nó.
Hóa đơn cũ: Số lượng nhân sự
Trong nhiều thập kỷ, nợ kỹ thuật đã tạo ra một vòng lặp hủy diệt quen thuộc. Một mã nguồn sẽ trở nên giòn và dễ gãy. Các tính năng từng mất vài ngày bắt đầu mất đến vài tuần. Thời hạn bị trễ, vì vậy ban lãnh đạo lại mở thêm các đợt tuyển dụng. Các đội ngũ lớn hơn lại càng làm mọi thứ chậm lại. Chi phí phối hợp tăng vọt, các buổi stand-up nhân lên, và Định luật Conway (Conway’s Law) bắt đầu ngự trị: phần mềm bắt đầu phản chiếu sự thiếu giao tiếp của những người tạo ra nó. Nhiều lỗi hơn lọt qua. Mỗi bản vá lại thêm vào những lớp phức tạp mới. Các công ty phải trả giá cho sự mục nát này bằng loại tiền tệ duy nhất mà họ biết: lương nhân viên. Chi phí đó rất rõ ràng. Nó hiện hữu trong mọi đợt xem xét ngân sách hàng quý.
Hóa đơn mới: Token và Ngữ cảnh
AI tạo sinh không phá vỡ vòng lặp này. Nó chỉ đơn giản là đưa ra một phương thức thanh toán thay thế. Thay vì thuê năm kỹ sư để vượt qua các rào cản, giờ đây một công ty chỉ cần quẹt thẻ tín dụng để mua thêm tài nguyên tính toán (compute). Các triệu chứng trông có vẻ khác, nhưng căn bệnh cốt lõi thì vẫn vậy.
Khi một mô hình bắt đầu gặp lỗi—ảo tưởng về các API nội bộ, bỏ lỡ các trường hợp biên (edge cases) quan trọng, tạo ra các bài kiểm tra vượt qua vì những lý do sai lệch—phản xạ thường thấy hiếm khi là tái cấu trúc (refactor). Phản xạ thường là chi tiền cho việc suy luận (inference). Các đội ngũ mua thêm nâng cấp cửa sổ ngữ cảnh (context window), chắp vá các vòng lặp thử lại đa tác nhân (multi-agent retry loops), chuyển khối lượng công việc sang các mô hình tiên tiến (frontier models) lớn hơn, hoặc nhấn nút tạo lại (regenerate) liên tục cho đến khi sự khác biệt (diff) trông có vẻ chấp nhận được. Những chiến thuật này duy trì tốc độ ảo trong một hoặc hai sprint. Bảng Jira vẫn hiển thị màu xanh. Trong khi đó, kiến trúc thực tế vẫn không hề được chạm tới: vẫn là những phụ thuộc (dependencies) rối rắm, cùng một trạng thái toàn cục (global state) có thể thay đổi, cùng một khối kiến trúc nguyên khối (monolith) mà không ai trong đội ngũ hiện tại hiểu rõ hoàn toàn.
Tại sao mã nguồn "bẩn" lại tốn Token
Các mô hình ngôn ngữ lớn suy luận tốt nhất dựa trên các trừu tượng hóa (abstractions) sạch sẽ. Tuy nhiên, hầu hết các kho lưu trữ (repositories) của doanh nghiệp đều giống như những di chỉ khảo cổ. Chúng chứa các phụ thuộc gói vòng lặp, các tác dụng phụ (side effects) ẩn giấu trong các kịch bản khởi tạo, và logic nghiệp vụ bị rải rác khắp các database triggers, các lớp middleware và các thành phần front-end. Trong môi trường đó, mô hình không dành năng lượng để viết logic mới. Nó đốt token vào việc thấu hiểu.
Một phần đáng kể của cửa sổ ngữ cảnh 128.000 token có thể bị tiêu tốn chỉ để duy trì cấu trúc của hệ thống trong bộ nhớ. Phần còn lại là những gì dành cho việc giải quyết vấn đề thực sự. Nó giống như việc yêu cầu một kỹ sư kết cấu thiết kế một tầng mới trong khi bắt họ phải vẽ lại bản thiết kế của tòa nhà hiện tại từ trí nhớ trước mỗi lần tính toán. Kết quả là những giải pháp hời hợt. Mô hình phản chiếu sự hỗn loạn mà nó thấy vì nó thiếu thẩm quyền, hoặc thiếu ngữ cảnh kiến trúc, để dọn dẹp căn phòng trước.
Đầu ra nhanh hơn, bàn giao chậm hơn
Tốc độ tạo nội dung thô không đồng nghĩa với tốc độ bàn giao sản phẩm. Nếu kiến trúc của bạn thiếu tính mô-đun, mọi thay đổi do AI tạo ra đều đòi hỏi sự xem xét kỹ lưỡng của con người và kiểm thử hồi quy (regression testing). Một mô hình có thể tạo ra mười pull request trong một buổi chiều, nhưng những pull request đó vẫn phải chạy qua môi trường tích hợp, trình quét bảo mật, danh sách kiểm tra tuân thủ và các bản thử nghiệm canary trên môi trường production. Nếu không có ranh giới mô-đun rõ ràng, AI sẽ đưa lỗi vào hệ thống với tốc độ của máy móc. Nó có thể sửa đổi một tiện ích dùng chung, cập nhật ba điểm gọi hàm (call sites) ở xa với những giả định sai lệch tinh vi, và tạo ra các điều kiện tranh đua (race conditions) mà con người chỉ phát hiện được khi nhận được thông báo khẩn cấp lúc 3 giờ sáng. Điểm nghẽn chuyển dịch từ bàn phím sang quy trình xác thực (validation pipeline), và quy trình đó vốn không được thiết kế để xử lý khối lượng thay đổi tăng gấp mười lần.
Trần giới hạn ẩn giấu
Trong kỷ nguyên trước AI, giới hạn cứng là ngân sách tuyển dụng của bạn. Ít nhất thì điều đó cũng dễ dàng đọc được trên một bảng tính. Giờ đây, sự ràng buộc lại nằm ẩn trong các hạng mục mà hầu hết các đội ngũ tài chính hiếm khi theo dõi: chi phí suy luận, lưu trữ embedding, mở rộng cửa sổ ngữ cảnh, và tình trạng tắc nghẽn kiểm thử tự động làm nghẹt các trình chạy CI. Các bảng điều khiển năng suất vẫn sáng đèn màu xanh, trong khi chi phí thực sự của mỗi tính năng mới đang âm thầm tích tụ.
Entropy kiến trúc mới là kẻ phản diện thực sự ở đây. Các LLM giúp mở rộng quy mô sản xuất mã nguồn một cách tuyệt vời, nhưng chúng không làm giảm độ phức tạp. Chúng không gỡ rối các microservices, loại bỏ mã chết, hay thu gọn các hệ thống phân cấp kế thừa. Một khi hệ thống vượt qua ngưỡng mà con người khó có thể lý giải được, AI cũng sẽ gặp khó khăn tương tự. Tại điểm uốn đó, chi phí sẽ tăng vọt cho dù bạn