Câu hỏi “LLM có viết được code dễ bảo trì không?” thực ra đang bị đặt sai ở rất nhiều đội ngũ. Vấn đề hiếm khi nằm ở chuyện model có đủ thông minh hay không. Vấn đề thường nằm ở cách anh em giao việc, cách giới hạn phạm vi, và cách kiểm soát chất lượng sau khi model nhả code ra.
Nếu dùng AI như một máy bắn code số lượng lớn, dự án sẽ rất nhanh rơi vào trạng thái chạy được nhưng khó sửa, khó review, và càng về sau càng đắt. Nhưng nếu xem AI như một thằng cộng tác viên viết rất nhanh, cần brief kỹ và bị ràng buộc bởi tiêu chuẩn kỹ thuật rõ ràng, thì chuyện maintainable code hoàn toàn khả thi.
Maintainable code trong thời AI thực ra là gì?
Một đoạn code dễ bảo trì không phải là đoạn code “trông thông minh”. Nó phải đạt mấy điều cơ bản:
- Người mới vào dự án đọc được tương đối nhanh.
- Sửa một chỗ không làm vỡ ba chỗ khác.
- Có ranh giới rõ giữa business logic, IO, UI, config và integration.
- Có test hoặc ít nhất có cách kiểm chứng hành vi.
- Có naming, structure và convention nhất quán qua nhiều file.
- Có thể refactor tiếp mà không cần phụ thuộc vào tác giả ban đầu.
LLM có thể hỗ trợ tạo ra mấy thứ này, nhưng cũng rất dễ phá nát chúng nếu prompt chỉ là “làm cho tao một app hoàn chỉnh”.
Vì sao AI-generated code hay bị chê là khó bảo trì?
1. Nó tối ưu cho việc hoàn thành nhiệm vụ trước mắt
Model thường ưu tiên tạo ra thứ giải quyết yêu cầu đang được hỏi. Nếu không bị ép nghĩ dài hạn, nó sẽ chọn đường ngắn nhất:
- nhét logic vào một file lớn
- copy-paste pattern lặp lại
- thêm utility mới thay vì tái sử dụng abstraction đang có
- viết workaround thay vì sửa tận gốc
Kết quả là nhìn demo rất ổn, nhưng sau 2 tuần bắt đầu xuất hiện “nợ cấu trúc”.
2. Context không đủ nên quyết định kiến trúc bị cục bộ
Một trong những lý do lớn nhất khiến code AI khó sống lâu là model chỉ thấy một lát cắt của hệ thống. Nếu anh em đưa cho nó một file rồi bảo “sửa giúp”, nó sẽ local-optimize theo file đó. Nó không tự hiểu toàn bộ dependency graph, guideline nội bộ, hay những quyết định kiến trúc đã có từ trước.
3. Prompt mơ hồ tạo ra code mơ hồ
Những prompt kiểu sau gần như đảm bảo tạo ra mã khó bảo trì:
- “thêm tính năng đăng nhập bằng Google”
- “refactor lại cho sạch hơn”
- “xây hộ tôi hệ thống quản lý kho”
Model vẫn làm được, nhưng nó phải tự đoán:
- cấu trúc thư mục
- pattern state management
- chiến lược error handling
- cách log, validate, test
- mức độ tách lớp
Càng nhiều thứ phải đoán, xác suất sinh ra mã khó nuôi càng cao.
Khi nào LLM viết được code dễ bảo trì?
Câu trả lời ngắn: khi anh em ép nó làm việc trong một hệ thống có luật.
1. Có specification đủ cụ thể
Brief tốt không chỉ mô tả tính năng, mà còn mô tả ràng buộc thực thi. Ví dụ:
- dùng service layer thay vì gọi DB trực tiếp từ controller
- không tạo thêm dependency mới
- mọi hàm public phải có test
- không file nào vượt quá X dòng nếu không có lý do rõ ràng
- không trộn validation với business logic
Khi đó model không còn “sáng tạo lung tung”, mà bị buộc phải đi trong lane hẹp.
2. Có codebase chuẩn để noi theo
LLM bắt chước pattern cực nhanh. Nếu dự án vốn đã sạch, naming rõ, cấu trúc module nhất quán, AI thường sinh code tương đối hợp hệ. Ngược lại, nếu codebase đang lộn xộn, model sẽ học luôn sự lộn xộn đó và nhân bản nó ra nhanh hơn con người.
Nói cách khác: AI không chỉ khuếch đại năng suất, nó còn khuếch đại cả chất lượng lẫn sự cẩu thả đang tồn tại.
3. Có bước review tách riêng khỏi bước generate
Một workflow rất đáng dùng là tách thành hai vòng:
- vòng 1: model A sinh code theo task hẹp
- vòng 2: model B hoặc reviewer người review theo checklist maintainability
Checklist review nên hỏi thẳng:
- Có chỗ nào đang duplicate logic không?
- API boundary đã rõ chưa?
- Tên hàm, tên biến có phản ánh business meaning không?
- Có hidden side effect không?
- Có thể viết test cho đoạn này dễ không?
- Nếu mai đổi requirement, phải sửa bao nhiêu nơi?
AI rất mạnh ở bước generate, nhưng muốn code sống lâu thì bước critique gần như bắt buộc.
Một quy trình thực dụng để dùng AI mà không phá codebase
Đây là cách mình thấy hợp với team làm sản phẩm thực tế.
Bước 1: Giao việc theo lát cắt nhỏ
Thay vì “xây tính năng thanh toán”, hãy tách ra:
- tạo interface payment provider
- implement adapter cho Stripe
- viết validation input cho create-payment
- thêm unit test cho fee calculation
- cập nhật màn hình trạng thái thanh toán
Task càng nhỏ, model càng ít cơ hội bịa kiến trúc.
Bước 2: Gắn kèm nguyên tắc bắt buộc
Trong prompt hoặc instruction file, ghi rõ:
- pattern kiến trúc đang dùng
- style code bắt buộc
- convention đặt tên
- yêu cầu test
- điều không được làm
Nếu có sẵn examples tốt trong repo, trỏ thẳng tới file mẫu để model bắt chước đúng format.
Bước 3: Yêu cầu plan trước khi code
Cho model nói trước:
- nó sẽ sửa những file nào
- vì sao chọn cách đó
- có rủi ro gì
- phần nào cần confirm thêm
Chỉ riêng bước này đã giảm rất nhiều ca “code chạy được nhưng đi sai hướng”.
Bước 4: Bắt nó giải thích trade-off
Ví dụ:
- vì sao tách service riêng thay vì nhét vào controller?
- vì sao chọn retry ở tầng client thay vì job queue?
- vì sao dùng composition thay vì inheritance ở đây?
Nếu model không giải thích được trade-off một cách mạch lạc, thường là code nó viết cũng chưa đáng tin.
Bước 5: Review bằng checklist maintainability
Đừng review theo cảm giác. Dùng checklist cứng:
- dễ đọc
- ít phụ thuộc chéo
- ít duplicate
- testable
- rollback dễ
- quan sát được qua log/metric
Checklist càng cụ thể thì AI càng dễ bị bắt lỗi kiểu “nhìn qua tưởng ổn”.
Những dấu hiệu cho thấy anh em đang dùng AI sai cách
Nếu trong team đang có mấy biểu hiện này, gần như chắc chắn sẽ sinh ra code khó bảo trì:
- prompt quá rộng, giao nguyên feature lớn trong một phát
- merge code AI sinh ra mà không đọc kỹ
- không có rule về structure, naming, test
- để model tự chọn framework, thư viện, pattern
- dùng nhiều agent nhưng không có một source of truth về kiến trúc
- mỗi task lại đổi style vì dùng prompt khác nhau
Nhiều người chê “AI viết code rác”, nhưng thực tế là quy trình đang khuyến khích nó viết rác.
Tin tốt: maintainability là bài toán quy trình, không chỉ là bài toán model
Các model mới hơn chắc chắn đang giúp ích: context dài hơn, khả năng reasoning tốt hơn, agent flow mạnh hơn. Nhưng ngay cả model rất mạnh cũng không tự biến một tổ chức thiếu kỷ luật kỹ thuật thành nơi sản sinh code sạch bền vững.
Cái quyết định nhiều hơn vẫn là:
- repo có chuẩn không
- team có review thật không
- task có được chia đúng không
- prompt có ép được các ràng buộc quan trọng không
- có đo chất lượng sau merge không
Nếu mấy phần này ổn, AI là lực đẩy cực mạnh. Nếu mấy phần này không ổn, AI chỉ làm nợ kỹ thuật đến nhanh hơn.
Kết luận
LLM có thể viết code dễ bảo trì, nhưng không theo kiểu autopilot. Nó làm tốt nhất khi anh em dùng nó như một công cụ tăng tốc trong quy trình đã có kỷ luật: task nhỏ, context đủ, rule rõ, review nghiêm và test tử tế.
Nói gọn hơn: AI không thay thế được engineering judgment. Nó chỉ làm cho judgment tốt trở nên hiệu quả hơn, và judgment tệ trở nên nguy hiểm hơn.
Với các team đang đẩy mạnh vibe coding, câu hỏi hữu ích hơn không phải là “AI có viết được code maintainable không?”, mà là “quy trình của mình có buộc AI tạo ra code maintainable hay chưa?”.
Top comments (0)