Vì sao AI Coding thường làm lệch kiến trúc hệ thống mà bạn không nhận ra

AI coding có một khả năng rất dễ khiến developer mê mẩn: viết code nhanh một cách hơi vô lý. Bạn mô tả feature, AI sinh code, test chạy, giao diện hiện ra, endpoint trả dữ liệu. Mọi thứ trông khá ổn. Team cảm thấy như vừa có thêm một thực tập sinh siêu cấp, không ngủ, không than, không hỏi tăng lương.

Nhưng rồi sau vài tháng, một cảm giác kỳ lạ bắt đầu xuất hiện. Hệ thống vẫn chạy. Feature vẫn hoạt động. Không có vụ nổ production ngoạn mục nào để cả đội họp khẩn. Chỉ là nhìn vào codebase, bạn bắt đầu thấy hơi lấn cấn. Controller dài hơn bình thường. Service layer phình to như đang ăn Tết quanh năm. Validation xuất hiện ở những nơi trước đây team từng thề là sẽ không bao giờ để nó xuất hiện.

Không có một thay đổi lớn nào đủ rõ để ai đó chỉ tay và nói: “A, đây là lúc kiến trúc lệch.” Nhưng khi nhìn toàn cảnh, mọi thứ bắt đầu hơi lạ. Cảm giác này trong software architecture có một cái tên rất quen:

Architecture Drift.

Điều nguy hiểm là architecture drift hiếm khi đến theo kiểu ồn ào. Nó đến rất âm thầm, qua các thay đổi nhỏ, hợp lý cục bộ và dễ được chấp nhận trong từng pull request. Đó là lý do AI coding có thể làm lệch kiến trúc hệ thống mà team không nhận ra cho tới khi việc maintain bắt đầu khó hơn hẳn, estimation ngày càng kém chính xác và ai cũng thấy code “không đến nỗi tệ nhưng sao cứ mệt”.

Architecture Drift là gì?

Architecture drift là tình trạng kiến trúc hệ thống thay đổi dần theo thời gian mà không có chủ đích rõ ràng. Không phải vì team quyết định redesign. Không phải vì có RFC nào bảo phải đổi pattern. Mà vì nhiều thay đổi nhỏ tích lũy lại, mỗi thay đổi nhìn riêng thì có vẻ hợp lý, nhưng cộng dồn lại thì hệ thống trượt dần khỏi cấu trúc ban đầu.

Ban đầu mọi thứ thường rất vô hại. Thêm một chút logic vào controller cho nhanh. Lặp lại một đoạn validation ở service cho chắc. Bỏ qua một abstraction vì “ticket này gấp”. Đổi chỗ xử lý lỗi cho tiện debug. Mỗi lần chỉ một ít thôi, nên không ai thấy cần kéo còi báo động. Nhưng sau vài chục pull request, codebase bắt đầu khó hiểu hơn, và cái “kiến trúc sạch đẹp” trong đầu mọi người chỉ còn tồn tại trong slide kickoff ngày xưa.

Điểm đáng sợ của architecture drift là nó không nhất thiết tạo bug ngay. Nó tạo ra ma sát. Mà ma sát trong software engineering là loại chi phí lãi kép rất âm thầm. Hôm nay mất thêm 10 phút để hiểu một file. Tuần sau mất thêm 20 phút để sửa một feature cũ. Hai tháng sau onboarding một người mới tốn thêm một tuần. Không ai la lên vì một chuyện quá nhỏ. Nhưng cả đội đang chậm dần mà không có một thủ phạm rõ mặt.

Vì sao AI coding dễ gây architecture drift?

AI coding không phải là “thủ phạm xấu xa” cố tình phá kiến trúc. Vấn đề nằm ở cách nó tạo ra lời giải: rất nhanh, rất hợp lý ở phạm vi cục bộ, nhưng không có cùng loại hiểu biết toàn cục như một kỹ sư đã sống lâu với hệ thống. Chính điều này khiến AI coding đặc biệt dễ tạo ra architecture drift nếu được phép sửa trực tiếp trong repository mà không có ràng buộc đủ mạnh.

1. AI không thực sự hiểu kiến trúc hệ thống như con người hiểu

AI không “hiểu” hệ thống theo kiểu một tech lead hiểu. Nó không nhớ vì sao team cố giữ controller mỏng. Nó không biết service này từng bị tách ra từ một khối monolith như thế nào. Nó không cảm nhận được rằng repository pattern đang tồn tại vì quý sau dự án sẽ phải hỗ trợ thêm một storage backend khác.

AI nhìn vào context có sẵn và suy diễn cách viết tiếp sao cho hợp lý nhất với phần nó nhìn thấy. Nếu controller hiện tại đã chứa khá nhiều logic, AI rất có thể sẽ tiếp tục đổ logic vào đó. Vì trong context hiện tại, điều đó trông tự nhiên. Nhưng cái trông tự nhiên cục bộ chưa chắc đã đúng với định hướng kiến trúc toàn cục.

Nói cách khác, AI giỏi đọc dấu chân gần nhất. Kiến trúc hệ thống lại cần người hiểu bản đồ toàn bộ khu rừng.

2. AI tối ưu cho việc hoàn thành task, không tối ưu cho kiến trúc dài hạn

Mục tiêu mặc định của AI rất đơn giản:

Hoàn thành task được yêu cầu bằng một lời giải trông hợp lý.

Nó không tự nhiên ưu tiên mạnh các thứ như:

• architecture consistency
• long-term maintainability
• độ bền của pattern qua hàng trăm lần thay đổi
• tính đồng đều giữa các module tương tự nhau

Nếu đoạn code chạy được, test qua được và giải quyết được yêu cầu trước mắt, AI coi như đã làm tốt nhiệm vụ. Điều này hoàn toàn hợp lý nếu bạn đang làm prototype hoặc proof of concept. Nhưng với production system, “chạy được hôm nay” chưa bao giờ là định nghĩa đủ của “đúng”. Production quan tâm cả chuyện hệ thống còn sống khỏe sau 6 tháng sửa liên tục hay không.

3. Mỗi prompt là một lần suy đoán lại cách hệ thống nên hoạt động

Khi dùng vibe coding hoặc các kiểu AI-assisted coding trực tiếp, mỗi prompt giống như một lần AI phải dựng lại mô hình tinh thần về hệ thống dựa trên context hiện có. Nếu context đầy đủ và may mắn, lời giải sẽ khá bám kiến trúc. Nếu context thiếu, nhiễu hoặc đã lệch sẵn, AI sẽ tiếp tục xây trên cái nền lệch đó.

Đây là chỗ architecture drift trở nên rất dễ xảy ra. Một lần AI hiểu hơi khác đi một chút, chênh vài độ. Không sao. Năm lần như vậy, kiến trúc bắt đầu nghiêng. Hai mươi lần như vậy, cả đội phải sống với một codebase mà ai cũng thấy “hình như không còn giống ngày xưa nữa”.

Nói vui một chút, mỗi prompt đều có thể là một lần AI “đoán ý team lead”. Mà ai từng đi họp nhiều sẽ biết, con người còn đoán ý nhau sai lên sai xuống, huống hồ mô hình chỉ nhìn thấy một lát cắt của repo.

4. AI có xu hướng tiếp nối pattern đang tồn tại, kể cả khi pattern đó vốn đã xấu

Đây là một điều rất thực tế. Nếu codebase của bạn đã có một vài điểm lỏng, AI thường sẽ không tự đứng ra làm cảnh sát kiến trúc để sửa lại cho đúng. Nó hay tiếp tục pattern hiện hữu vì đó là điều trông “nhất quán” trong ngữ cảnh hiện tại.

Ví dụ, nếu một số controller đã chứa business logic, AI sẽ học từ chính điều đó và tiếp tục đẩy thêm logic vào controller mới. Nếu validation đang nằm rải rác ở nhiều nơi, AI có thể xem đây là chuyện bình thường và lặp lại. Kết quả là codebase không chỉ drift, mà còn drift theo hướng khuếch đại các điểm xấu có sẵn.

Vì sao team thường không nhận ra ngay?

Đây là phần nguy hiểm nhất. Architecture drift hiếm khi tạo ra một khoảnh khắc “gãy” rõ ràng. Không có đèn đỏ bật lên báo rằng từ commit này trở đi hệ thống đã lệch. Thay vào đó, team chỉ cảm nhận bằng những tín hiệu mơ hồ:

• mỗi lần sửa feature cũ mất thời gian hơn trước
• review khó hơn nhưng không rõ vì sao
• cùng một loại bài toán mà mỗi nơi viết một kiểu
• người mới vào repo thấy khó hiểu hơn mức đáng lẽ
• team thấy “hệ thống nặng nề hơn” dù business chưa tăng quá nhiều

Vì không có một cú nổ rõ ràng, mọi người dễ quy những dấu hiệu này cho đủ thứ khác: do deadline, do thiếu người, do sprint này hơi nhiều việc, do feature phức tạp hơn trước. Trong khi thủ phạm thật có thể chỉ là kiến trúc đã bị kéo lệch dần qua hàng loạt thay đổi cục bộ tưởng như vô hại.

Đó là lý do bài toán này rất đáng để nói tới. Không phải vì AI làm gì cũng sai, mà vì AI có thể làm sai theo cách lịch sự đến mức chẳng ai phát hiện ngay.

Dấu hiệu cho thấy hệ thống đang bị architecture drift

Có một số dấu hiệu khá điển hình mà team nên để ý:

• controller bắt đầu chứa business logic thay vì chỉ điều phối request
• service layer phình to, ôm quá nhiều trách nhiệm
• validation xuất hiện ở nhiều lớp khác nhau mà không có quy tắc rõ
• cùng một logic được viết lại nhiều lần ở các module tương tự
• naming convention và cách chia file không còn nhất quán
• mỗi feature mới lại cần “lách” một chút vì kiến trúc hiện tại không còn khớp

Khi những dấu hiệu này xuất hiện lặp lại, hệ thống bắt đầu khó maintain không phải vì bài toán nghiệp vụ quá phức tạp, mà vì cấu trúc bên dưới không còn giúp team suy nghĩ rõ ràng nữa. Lúc đó, code không chỉ là nơi triển khai logic. Nó trở thành nơi tạo ra mệt mỏi.

Vấn đề không nằm ở AI, mà ở workflow AI coding

Điều quan trọng cần hiểu là:

AI không phải là bản chất của vấn đề.

Vấn đề nằm ở cách chúng ta tổ chức workflow AI coding. Khi AI được phép chỉnh sửa code trực tiếp trong repository mà không có một nguồn chân lý kiến trúc rõ ràng, nó buộc phải dựa vào context để đoán cấu trúc hệ thống. Context càng lớn, càng nhiễu hoặc càng đã drift sẵn, khả năng đoán lệch càng cao.

Nói cách khác, nếu bạn thả AI vào một căn phòng hơi bừa rồi bảo “em cứ xếp đồ giúp anh sao cho hợp lý”, kết quả có thể vẫn gọn hơn một chút ở từng góc nhỏ. Nhưng chưa chắc căn phòng giữ được logic sắp xếp ban đầu. Muốn bền, bạn phải có quy tắc sắp đồ trước đã.

Làm sao để tránh architecture drift khi dùng AI coding?

Một hướng tiếp cận hiệu quả là đưa kiến trúc hệ thống ra khỏi phần code sửa tay hàng ngày và biểu diễn nó bằng một lớp mô tả rõ ràng hơn. Lớp mô tả đó có thể là:

• contract
• document có cấu trúc
• architecture definition
• workflow spec hoặc schema

Sau đó, thay vì để AI sửa trực tiếp nhiều lớp code trong repo, team để AI hỗ trợ ở tầng mô tả này và sinh code từ mô tả đó. Đây chính là lý do contract coding và document as code trở nên quan trọng. Chúng tạo ra một nơi chính thức để kiến trúc được thể hiện và được bảo vệ.

Khi kiến trúc nằm trong contract hoặc document, AI không còn phải đoán toàn bộ hệ thống từ những mảnh context rời rạc. Nó có một đường ray rõ hơn để bám theo. Và khi code được sinh ra theo cùng một bộ quy tắc, khả năng drift cũng giảm đi rất nhiều.

Một vài nguyên tắc thực tế để giảm drift

• Giữ pull request nhỏ để phát hiện lệch kiến trúc sớm hơn
• Tách rõ thay đổi business logic và thay đổi refactor
• Định nghĩa convention kiến trúc đủ cụ thể để AI có thể bám theo
• Dùng contract hoặc document làm nguồn chân lý cho các phần lặp của hệ thống
• Review ở mức kiến trúc, không chỉ ở mức code chạy được hay không

Đây không phải chuyện “kìm hãm AI”. Đây là chuyện giúp AI làm việc trong một hệ thống có lan can. Mà lan can thì không làm bạn đi chậm hơn. Nó chỉ giúp bạn đỡ rơi khỏi cầu khi đi nhanh.

Kết luận

AI coding dễ làm lệch kiến trúc hệ thống vì nó tối ưu cho lời giải cục bộ và tốc độ hoàn thành task, chứ không tự nhiên tối ưu cho tính nhất quán kiến trúc dài hạn. Khi được phép sửa code trực tiếp trong repository, AI dựa vào context để suy đoán hệ thống. Những suy đoán hơi lệch nhưng có vẻ hợp lý đó, khi tích lũy theo thời gian, chính là con đường ngắn nhất dẫn tới architecture drift.

Điều khó chịu nhất là drift không làm hệ thống nổ tung ngay. Nó làm hệ thống mệt dần, khó hiểu dần, khó review dần và khó mở rộng dần. Đó là lý do nhiều team chỉ nhận ra vấn đề khi maintenance đã bắt đầu đắt hơn rất nhiều so với lúc ban đầu.

Muốn dùng AI coding lâu dài, đừng chỉ hỏi “AI viết nhanh cỡ nào”. Hãy hỏi thêm: “Kiến trúc hệ thống đang được bảo vệ bằng cái gì?”

Đó cũng là lý do ngày càng nhiều team tìm đến những workflow mới để kết hợp AI với software architecture theo cách có kỷ luật hơn. Và trong bài tiếp theo, chúng ta sẽ đi vào một câu hỏi thực chiến hơn nữa:

Có thể dùng AI coding an toàn trong backend production không?