AI đang tạo ra một loại Tech Debt mới - và không ai nói về nó

Ba loại nợ - Bằng tiếng Anh đơn giản

Hãy để tôi giải thích chính xác những gì đang tích lũy trong cơ sở mã ngay bây giờ.

1. Nợ nhận thức - Cuộc khủng hoảng vô hình

Margaret-Anne Storey đã mô tả điều này một cách hoàn hảo: chương trình không phải là mã nguồn của nó. Chương trình là một lý thuyết — một mô hình tinh thần tồn tại trong tâm trí các nhà phát triển, nắm bắt những gì phần mềm thực hiện, ý định được triển khai như thế nào và điều gì xảy ra khi bạn thay đổi mọi thứ.

Theo mặc định, các công cụ AI đẩy nhà phát triển từ chế độ tạo sang chế độ đánh giá. Bạn ngừng giải quyết vấn đề và bắt đầu đánh giá các giải pháp mà người khác đưa ra.

Vấn đề là việc xem xét kết quả đầu ra của AI cảm thấy hiệu quả. Bạn đang đọc mã, phát hiện vấn đề, chỉnh sửa. Nhưng bạn không xây dựng mô hình tinh thần cho phép bạn suy luận về hệ thống một cách độc lập.

Một nhóm sinh viên đã minh họa điều này một cách hoàn hảo — họ đã sử dụng AI để xây dựng nhanh chóng và có phần mềm hoạt động được. Khi họ cần thực hiện một thay đổi đơn giản vào tuần thứ bảy thì dự án bị đình trệ. Không ai có thể giải thích lý do thiết kế. Không ai hiểu các thành phần tương tác như thế nào. Lý thuyết chung của chương trình đã bốc hơi.

// Mã này hoạt động. Bạn có thể giải thích lý do trong 30 giây không?
// Nếu bạn tạo nó bằng AI và không ngừng tìm hiểu nó — 
// bạn đã tích lũy được khoản nợ nhận thức.
const processPayment = async (userId, số tiền,  tiền tệ) => {
  const [người dùng, rateLimit, lừa đảo] = await Promise.tất cả([
    db.người dùng.findById(userId),
     redis.nhận(`rate:${userId`),
    fraudService.kiểm tra(userId, số tiền)
  ]);
  if (!người dùng || rateLimit > 10 || lừa đảo.điểm > 0,7) {
    ném mới PaymentError(người dùng ? 'RATE_LIMITED' : 'USER_NOT_FOUND');
  
   // Bạn có thể phát hiện ra lỗi không? Điều gì xảy ra nếu gian lận.score chính xác là 0,7?
  // Điều gì sẽ xảy ra nếu rateLimit là null?
  // AI đã tạo ra điều này. Bạn có hiểu nó trước khi gửi nó không?
};

2. Nợ xác minh - Cái bẫy niềm tin sai lầm

Mỗi lần bạn nhấp vào phê duyệt một điểm khác biệt mà bạn chưa hiểu rõ, bạn đang vay mượn cho tương lai.

Không giống như nợ kỹ thuật — tự xuất hiện thông qua xích mích ngày càng gia tăng, xây dựng chậm, phụ thuộc rối rắm — nợ xác minh tạo ra niềm tin sai lầm. Cơ sở mã có vẻ sạch sẽ. Các bài kiểm tra đều có màu xanh.

Sáu tháng sau, bạn phát hiện ra rằng mình đã xây dựng chính xác những gì thông số kỹ thuật đề ra — và không có điều gì khách hàng thực sự mong muốn.

# Khoản nợ xác minh tích lũy ở đây:
# ✅ Tất cả các bài kiểm tra đều đạt
# ✅ Không có lỗi linting 
# ✅ Đã phê duyệt đánh giá mã
# ✅ Đã triển khai vào sản xuất
# Nhưng không ai hỏi:
 # ❌ Điều này có thực sự giải quyết được vấn đề của người dùng không?
# ❌ Điều gì xảy ra trong các trường hợp nguy hiểm mà AI không xem xét?
# ❌ Điều này có phù hợp với các mẫu kiến trúc của chúng tôi không?
# ❌ Liệu nhà phát triển tiếp theo có hiểu được điều này không?

3. Nợ kiến trúc - Khi các khuôn mẫu bị phá vỡ

Các tác nhân AI tạo mã hoạt động nhanh nhưng có xu hướng lặp lại các mẫu thay vì trừu tượng hóa chúng. Bạn kết thúc với năm cách triển khai hơi khác nhau của cùng một logic trên năm tệp. Mỗi người đều làm việc. Không ai trong số họ chia sẻ một tiện ích chung.

Mã do AI tạo ra có xu hướng đi theo hướng tốt đẹp. Nó xử lý tốt các trường hợp mà dữ liệu huấn luyện đã xử lý tốt - đầu vào tiêu chuẩn, trạng thái dự kiến, mã lỗi phổ biến. Các trường hợp biên, điều kiện chạy đua và lỗi cụ thể của cơ sở hạ tầng được xử lý hời hợt hoặc không xử lý gì cả.

Khi một tác nhân AI cần chức năng, nó sẽ tìm đến một gói hàng. Nó không cân nhắc xem cơ sở mã hiện tại đã đáp ứng được nhu cầu hay chưa, liệu phần phụ thuộc có được duy trì hay không hay kích thước gói có hợp lý cho một chức năng hay không.

Kết quả là cái mà tôi gọi là "sự hỗn loạn mạch lạc" — mã hợp lý về mặt cá nhân và không mạch lạc về mặt tổng thể.

Thứ Hai: Sử dụng AI để tạo tính năng (nhanh)
Thứ ba: Đọc từng dòng không cần AI hỗ trợ (chậm)
Thứ tư: Cấu trúc lại những gì bạn không hiểu (trung bình)
Thứ năm: Các trường hợp thử nghiệm mà AI không xem xét (trung bình)
Thứ sáu: Hợp nhất

Quy tắc dành cho nhà phát triển cấp dưới:
✅ Dùng cho tấm ván khuôn và giàn giáo
✅ Sử dụng cho các mẫu được hiểu rõ
✅ Sử dụng để tạo thử nghiệm
⚠️ Xem xét mọi thứ một cách cẩn thận
❌ Đừng để họ là kiến trúc sư một mình
❌ Không gộp code không giải thích được
❌ Đừng bỏ qua bài ôn tập vì bài kiểm tra đã vượt qua