Điều nguy hiểm nhất mà một tác tử viết mã AI có thể tạo ra là đoạn mã chạy đúng. Theo bài phân tích gốc của The New Stack, mã không lỗi vẫn có thể âm thầm phá vỡ ranh giới miền. Nó có thể nối sai các thành phần và làm đội ngũ mất khả năng hình dung kiến trúc tổng thể.
Nếu một lập trình viên mới viết mã kém, bản dựng hoặc môi trường thử nghiệm thường báo lỗi. Nhóm phát triển có thể phát hiện và hoàn tác thay đổi. Sau đó, họ thảo luận về nguyên nhân. Trái lại, một tác tử viết mã AI có thể tạo ra 500 dòng mã hoạt động đúng và không có lỗi rõ ràng. Mã đó vẫn có thể vi phạm các giả định thiết kế. Vì mọi kiểm thử chức năng đều qua, thay đổi đó có thể được hợp nhất mà không gây chú ý.
Qua nhiều lần như vậy, dịch vụ thanh toán có thể phụ thuộc vào thành phần xác thực người dùng. Tầng trình bày có thể truy cập trực tiếp cơ sở dữ liệu. Các quan hệ phụ thuộc mới cũng xuất hiện ở những nơi kiến trúc ban đầu không cho phép. Hệ thống vẫn chạy, nhưng mô hình tinh thần mà đội ngũ dùng để hiểu nó bắt đầu tan rã.
Nợ thấu hiểu nguy hiểm hơn mã nguồn lộn xộn
Nợ kỹ thuật thường gợi đến mã khó đọc, giải pháp tạm thời hoặc phần việc phải sửa sau. Nợ thấu hiểu là khoảng cách ngày càng lớn giữa tốc độ mã được tạo ra và mức độ con người hiểu kiến trúc của mã đó.
Vấn đề không chỉ nằm ở logic rối. Nhóm phát triển có thể không còn biết vì sao một thành phần tồn tại, tại sao một miền không được phép gọi miền khác hoặc điều gì sẽ xảy ra nếu thay đổi một giao diện. Khi đó, mỗi yêu cầu mới đều làm tăng nguy cơ sửa đúng một chức năng nhưng phá vỡ thiết kế chung.
Nếu doanh nghiệp chỉ xem AI như công cụ gõ mã nhanh hơn, kiến trúc có thể xuống cấp ngay trong lúc năng suất bề ngoài tăng lên. Cách kiểm soát phù hợp không phải yêu cầu mọi người đọc thêm tài liệu, mà là biến quy tắc kiến trúc thành điều kiện có thể thực thi.
Tài liệu không đủ để ngăn kiến trúc lệch hướng
Một hướng dẫn thường gặp khi áp dụng AI vào phát triển phần mềm là viết tài liệu rõ hơn để tác tử hiểu quy tắc. Tuy nhiên, tài liệu có thể lỗi thời và không tự ngăn được một thay đổi sai.
Nếu tác tử tìm thấy đường ngắn hơn để hoàn thành nhiệm vụ bằng cách bỏ qua tầng dịch vụ, nó có thể chọn đường đó. Người đánh giá mã cũng khó lần theo toàn bộ cây phụ thuộc trong khối lượng lớn thay đổi do AI tạo ra. Đây là một phần nguyên nhân khiến việc AI làm thay đổi quy trình rà soát mã trở thành vấn đề kiến trúc, thay vì chỉ là câu chuyện năng suất.
Ranh giới quan trọng cần được kiểm tra giống một yêu cầu nghiệp vụ. Khi tác tử vi phạm điều kiện kiến trúc, quy trình tích hợp liên tục và triển khai liên tục phải làm bản dựng thất bại. Con người không còn là lớp phòng thủ duy nhất.
Kiểm thử kiến trúc Python có thể thực thi: nội dung và cách triển khai
Trong hệ sinh thái Java, ArchUnit được dùng để kiểm soát ranh giới kiến trúc. Với Python, pytest-archon có thể đảm nhiệm vai trò tương tự bằng cách biểu diễn quy tắc dưới dạng kiểm thử.
Giả sử một ứng dụng thương mại điện tử được xây dựng theo kiến trúc nguyên khối mô đun. Nhóm phát triển đặt ra hai ranh giới:
- Miền thanh toán không được nhập mã từ miền vận chuyển.
- Mô hình miền không được phụ thuộc vào hạ tầng như AWS SDK hoặc SQLAlchemy.
Tác tử AI được giao thêm chức năng tính phí vận chuyển dựa trên hạng thanh toán của người dùng. Để hoàn thành nhanh, tác tử nhập trực tiếp bộ tính phí vận chuyển vào dịch vụ thanh toán. Kiểm thử chức năng qua và ứng dụng vẫn chạy, nhưng ranh giới giữa hai miền đã bị phá vỡ.
Bước 1: Cài đặt công cụ kiểm thử
Trước tiên, cài pytest-archon trong môi trường phát triển:
pip install pytest-archonBước 2: Viết quy tắc kiến trúc thành kiểm thử
Thay vì chỉ ghi quy tắc trên trang tài liệu nội bộ, nhóm phát triển tạo tệp test_architecture.py trong thư mục kiểm thử:
from pytest_archon import archrule
def test_billing_is_isolated_from_shipping():
"""
Bảo đảm mô đun thanh toán không nhập logic vận chuyển.
Quy tắc này ngăn liên kết chặt giữa hai miền riêng biệt.
"""
(
archrule(
"billing_isolation",
comment="Miền thanh toán không được biết miền vận chuyển"
)
.match("ecommerce.billing*")
.should_not_import("ecommerce.shipping*")
.check("ecommerce")
)
def test_domain_models_are_pure():
"""
Bảo đảm mô hình miền không nhập thành phần hạ tầng.
"""
(
archrule(
"pure_domain",
comment="Mô hình miền không được nhập hạ tầng"
)
.match("ecommerce.*.models")
.should_not_import("sqlalchemy*")
.should_not_import("boto3*")
.check("ecommerce")
)Quy tắc đầu tiên cấm mã trong miền thanh toán nhập thành phần vận chuyển. Quy tắc thứ hai ngăn mô hình miền phụ thuộc vào SQLAlchemy hoặc boto3. Nếu tác tử tạo ra một quan hệ phụ thuộc bị cấm, kiểm thử sẽ phát hiện dù chức năng mới vẫn cho kết quả đúng.
Bước 3: Khép kín vòng phản hồi cho tác tử
Khi tác tử gửi yêu cầu hợp nhất mã, pytest chạy tự động trong quy trình tích hợp liên tục. Nếu dịch vụ thanh toán nhập bộ tính phí vận chuyển, bản dựng có thể trả về lỗi như sau:
FAILED tests/test_architecture.py::test_billing_is_isolated_from_shipping
AssertionError: Quy tắc 'billing_isolation' bị vi phạm:
ecommerce.billing.invoice nhập ecommerce.shipping.calculatorNgười đánh giá không phải tự lần theo toàn bộ cây nhập mô đun. Kết quả kiểm thử thất bại có thể được đưa trở lại cửa sổ ngữ cảnh của tác tử thông qua Aider hoặc một tập lệnh tích hợp liên tục tùy chỉnh. Tác tử nhận được ranh giới cụ thể đã vi phạm và có thể sửa mã mà không cần con người chỉ ra từng dòng.
Ba cách hạn chế nợ thấu hiểu
Dùng ranh giới cứng thay cho quy ước mềm
Tác tử có khả năng tuân theo điều kiện cứng tốt hơn một gợi ý được ghi trong tài liệu. Vì vậy, cấu trúc thư mục không nên là lớp bảo vệ duy nhất. Nhóm phát triển cần xác lập ranh giới mô đun rõ ràng và dùng import-linter hoặc pytest-archon để chặn các lệnh nhập bị cấm.
Đường đi dễ nhất đối với tác tử cũng phải là đường phù hợp với kiến trúc. Nếu cách phá vỡ ranh giới nhanh hơn cách tuân thủ, tài liệu khó ngăn tác tử chọn giải pháp ngắn nhất.
Đặt giới hạn cứng cho độ phức tạp
API và ranh giới rõ ràng không loại bỏ nguy cơ mã phức tạp bên trong từng mô đun. Ví dụ của The New Stack đặt tình huống AI tạo mã chắp vá trong mô đun thanh toán, dẫn đến thời gian ngừng hoạt động do điều kiện tranh chấp lúc 3 giờ sáng. Khi đó, kỹ sư vẫn phải hiểu và bảo trì phần mã mà tác tử đã viết.
Các kiểm thử kiến trúc nên chạy cùng công cụ kiểm soát độ phức tạp chu trình như Ruff, Radon hoặc SonarQube. Giới hạn độ phức tạp trong quy trình tích hợp liên tục buộc tác tử chia một hàm quá lớn thành các phần nhỏ hơn.
Rà soát giao diện thay vì đọc mọi dòng
Sự chú ý của lập trình viên là tài nguyên có hạn. Khi đánh giá yêu cầu hợp nhất do AI tạo ra, nhóm phát triển không nhất thiết phải giải mã từng vòng lặp và phép gán biến trước tiên.
Hãy kiểm tra những thay đổi nhìn thấy từ bên ngoài hệ thống. Yêu cầu hợp nhất có thêm quan hệ phụ thuộc không? Có công bố điểm cuối API mới không? Lược đồ dữ liệu có đổi không? Nếu các giao diện và ranh giới không thay đổi, mô hình tinh thần của đội ngũ có nhiều khả năng vẫn được giữ nguyên.
Tạo hàng rào để AI không phá vỡ thiết kế
Công cụ viết mã AI có năng lực mạnh nhưng tập trung vào nhiệm vụ được giao. Khả năng bảo trì dài hạn không tự trở thành ưu tiên nếu yêu cầu và môi trường thực thi không buộc tác tử phải quan tâm đến nó.
Chỉ dựa vào con người để kiểm soát thiết kế sẽ khiến nợ thấu hiểu tiếp tục tích tụ. Mục tiêu không phải làm chậm quá trình sử dụng AI, mà là khiến môi trường phát triển có khả năng chống lại thay đổi sai kiến trúc.
Đội ngũ không cần đọc kỹ từng dòng mã do AI tạo ra. Họ cần biến ranh giới thiết kế thành kiểm thử, đặt giới hạn độ phức tạp và để quy trình tích hợp liên tục chặn sai phạm trước khi mã được hợp nhất.
Hãy bắt đầu bằng một ranh giới kiến trúc quan trọng nhất trong hệ thống của bạn và biến nó thành kiểm thử tự động ngay trong quy trình tích hợp liên tục.
