Vấn đề của các codebase do AI tạo ra không nằm ở chất lượng code. Nó nằm ở sự thiếu vắng phán đoán kỹ thuật (engineering judgment). Code mà không có quyết định đứng sau chỉ là văn bản tình cờ compile được.
Hãy làm rõ ngay từ đầu: AI thực sự giỏi viết code. Không hoàn hảo, nhưng đủ năng lực. Nó có thể tạo ra implementation chạy được nhanh hơn bất kỳ con người nào, trên nhiều ngôn ngữ hơn bất kỳ developer đơn lẻ nào biết.
Nhưng đó không phải vấn đề.
Vấn đề là: viết code và ra quyết định kỹ thuật là hai hoạt động hoàn toàn khác nhau — và AI chỉ làm được một trong hai.
Code là phần dễ
Đây là điều mà engineer có kinh nghiệm đều biết, nhưng hiếm khi nói thẳng: phần khó của software engineering chưa bao giờ là việc gõ code. Nó là việc quyết định xây cái gì, cấu trúc ra sao, và quan trọng nhất — không xây cái gì.
Mỗi codebase là kết quả của hàng nghìn quyết định nhỏ:
-
Dùng thư viện hay tự viết?
-
Nên tách thành một service hay hai?
-
Abstraction này có đáng với độ phức tạp nó mang lại không?
-
Xử lý edge case này ngay hay là premature optimization?
-
Boundary giữa các module nên nằm ở đâu?
Đây không phải câu hỏi về syntax hay thuật toán. Đây là câu hỏi về trade-off, context và judgment. Nó đòi hỏi hiểu không chỉ code đang làm gì hôm nay, mà còn sẽ cần làm gì trong 6 tháng tới.
AI không đưa ra những quyết định này. Nó chỉ tạo ra thứ bạn yêu cầu. Và sự khác biệt này tạo ra hậu quả tích lũy theo thời gian.
Prompt không phải là kiến trúc
Khi bạn build với AI, kiến trúc codebase được định hình bởi chuỗi prompt bạn đã viết. Không phải bởi thiết kế có chủ đích. Không phải bởi hiểu rõ domain. Chỉ đơn giản là thứ tự bạn nghĩ ra vấn đề.
-
Thứ Hai: bạn yêu cầu authentication
-
Thứ Ba: bạn yêu cầu settings page
-
Thứ Tư: bạn yêu cầu tích hợp API
Mỗi prompt đều tạo ra code chạy được. Nhưng không ai hỏi:
-
Ba phần này nên liên kết với nhau như thế nào?
-
Boundary nằm ở đâu?
-
Dữ liệu được chia sẻ ra sao?
AI cũng không hỏi. Nó chỉ tạo ra ba phần độc lập, mỗi phần tự “hợp lý” bên trong, nhưng không có sự hiểu biết chung giữa chúng.
Sáu tháng sau, khi cần thay đổi session handling, bạn phát hiện:
-
auth xử lý theo một kiểu
-
settings theo kiểu khác
-
API integration theo kiểu thứ ba
Không phải vì ai đó quyết định như vậy.
Mà vì không ai quyết định cả.
Khoảng trống quyết định (decision vacuum)
Đây là điều xuất hiện trong hầu hết các codebase do AI tạo ra mà chúng tôi audit: không phải code tệ, mà là thiếu hoàn toàn quá trình ra quyết định.
-
Không có architectural decision record
-
Không có lý do tại sao chọn pattern này thay vì pattern khác
-
Không có consistency giữa các phần tương tự
Chỉ có một chuỗi implementation chạy được, mỗi cái được tạo ra trong isolation, ghép lại bằng những gì AI gợi ý tại thời điểm đó.
Code compile.
Test pass (nếu có).
Product chạy.
Nhưng codebase không phản ánh bất kỳ triết lý kỹ thuật nào. Không có “chúng ta làm như vậy vì…”, chỉ có “AI đã tạo như vậy”.
Điều này quan trọng vì software tồn tại lâu hơn prompt đã tạo ra nó. Code cần được maintain bởi những người không có mặt khi prompt được viết. Nếu họ không hiểu vì sao code được cấu trúc như vậy, họ không thể thay đổi nó một cách an toàn.
Bạn không nhận ra… cho đến khi quá muộn
Điểm nguy hiểm của code không có quyết định là: ban đầu nó hoạt động hoàn toàn ổn.
-
AI tạo code chạy được
-
User không quan tâm kiến trúc
-
Doanh thu không phụ thuộc abstraction đẹp
Nhưng chi phí tích lũy âm thầm:
-
Mỗi feature mới mất thêm thời gian vì phải “lách” qua code cũ
-
Mỗi bug khó debug hơn vì thiếu model nhất quán
-
Onboarding chậm hơn vì không có gì rõ ràng để học
-
Refactor trở nên đáng sợ vì không ai biết blast radius
Và rồi một ngày, “lãi kép” đến hạn.
Bạn cần thay đổi lớn — và nhận ra codebase không có “trọng tâm”. Không có kiến trúc rõ ràng để mở rộng. Chỉ có các pattern chắp vá.
Điều này có nghĩa gì trong thực tế
Không ai nói là không nên dùng AI. Chúng ta cũng dùng nó. Nó là một công cụ mạnh.
Nhưng dùng AI mà không có engineering judgment giống như dùng máy CNC mà không có blueprint:
-
Bạn sẽ tạo ra rất nhiều “bộ phận”
-
Rất nhanh
-
Nhưng việc chúng có ghép lại thành hệ thống coherent hay không… phụ thuộc vào những quyết định mà máy không thể đưa ra
Nếu bạn build với AI, vẫn cần một người đóng vai trò architect:
-
Module structure là gì?
-
Pattern nào được dùng nhất quán?
-
Boundary giữa các concern ở đâu?
-
Cái gì không nên build?
-
Làm sao đảm bảo code mới khớp với convention cũ?
Không cần phải là quyết định lớn ngay từ đầu. Nhưng chúng phải tồn tại.
Một codebase không có quyết định chỉ là một đống file tình cờ chạy được.
Sự thật khó chịu
Có một điều mà những cuộc tranh luận kiểu “AI sẽ thay thế developer” không muốn nhắc đến:
AI làm cho việc viết code rẻ hơn.
Nhưng nó làm cho việc tư duy trở nên giá trị hơn.
Khi code trở nên rẻ, bottleneck chuyển sang judgment:
-
Xây cái gì?
-
Cấu trúc ra sao?
-
Khi nào refactor?
-
Cái gì nên bỏ?
Những quyết định này sẽ quyết định codebase của bạn là asset hay liability sau 2 năm.
AI không thể đưa ra những quyết định đó. Đây không phải là vấn đề “huấn luyện thêm”. Đây là bản chất của công cụ:
Nó tạo ra thứ bạn yêu cầu.
Còn việc yêu cầu cái gì — đó mới chính là engineering.