Claude Không Phải Là Kiến Trúc Sư: Đừng Để AI Quyết Định Hệ Thống Của Bạn

Trong tháng qua, tôi đã chứng kiến một hiện tượng lặp đi lặp lại ở ba tổ chức khác nhau với ba stack công nghệ hoàn toàn riêng biệt. Mô hình thì giống nhau: Một người — có thể là quản lý sản phẩm, team lead hay thậm chí là CTO sau một hội nghị — nảy ra một ý tưởng. Họ mở Claude, ChatGPT hay Copilot (công cụ nào không quan trọng) và hỏi nó xem nên xây dựng cái gì.

AI làm điều nó luôn làm: xác nhận ý tưởng một cách nhiệt tình, đề xuất một kiến trúc và bắt đầu phác thảo các thành phần. Nó hùng hồn, tự tin và nghe giống như một kỹ sư cấp cao đã suy nghĩ sâu sắc về vấn đề này.

Nhưng thực tế là nó chưa hề suy nghĩ về vấn đề đó cả. Nó chỉ đang khớp mẫu (pattern-matching) với dữ liệu đào tạo và tạo ra phản hồi nghe có vẻ hợp lý nhất. Nhưng vì nó nghe quá hay nên chẳng ai phản biện lại. Chưa kịp hiểu chuyện gì thì, Claude đã trở thành kiến trúc sư.

Vấn đề của sự tán dương vô điều kiện

Các tác nhân AI có xu hướng "dễ tính" một cách bệnh lý. Hỏi Claude xem ý tưởng của bạn có tốt không, nó sẽ nói là tốt. Hỏi xem kiến trúc microservices có hợp lý với team 3 người không, nó sẽ giải thích tại sao microservices là lựa chọn xuất sắc. Hỏi xem nên xây dựng pipeline ML tùy chỉnh hay dùng dịch vụ quản lý, nó sẽ nhiệt tình vẽ ra thiết kế.

Nó không nói dối. Nó thậm chí chưa chắc đã sai. Nó chỉ không thể làm được điều khiến một kiến trúc sư thực sự có giá trị: nói "không".

Kỹ năng quan trọng nhất của một kiến trúc sư giỏi không phải là thiết kế hệ thống. Đó là biết nên không xây dựng hệ thống nào. Đó là việc đẩy lùi sự phức tạp. Đó là hỏi "tại sao?" năm lần cho đến khi yêu cầu thực sự hiện ra khỏi những lời sáo rỗng. Đó là nói với CTO rằng ý tưởng nảy ra sau hội nghị của họ hoàn toàn không phù hợp với team hiện tại.

Claude sẽ không bao giờ làm thế. Nó được đào tạo để hữu ích. Hữu ích ở đây đồng nghĩa với việc dễ dãi. Dễ dãi đồng nghĩa với việc bạn nhận được một lời tán dương và một "tháp Jenga" được mệnh danh là kiến trúc.

Tháp Jenga

Đây là cách kiến trúc do AI thiết kế trông như trong thực tế.

Về mặt kỹ thuật, nó nghe rất ổn. Các thành phần có ý nghĩa khi đứng riêng lẻ. Các mẫu thiết kế rất quen thuộc — hướng sự kiện ở đây, CQRS ở kia, service mesh vì sao không chứ. Nó trông giống hệt sản phẩm của một kiến trúc sư cấp cao. Nó vượt qua bài kiểm tra "nhắm mắt cho qua".

Nhưng nó không được thiết kế cho team của bạn. Nó không được thiết kế cho các ràng buộc của bạn. Nó không được thiết kế cho thực tế tẻ nhạt của môi trường sản xuất của bạn — các khóa chặt VPC, các tích hợp hệ thống cũ (legacy), team chưa bao giờ vận hành Kubernetes trong môi trường production, các yêu cầu tuân thủ khiến một nửa các dịch vụ quản lý bị cấm sử dụng.

Nó được thiết kế cho mức trung bình của mọi thứ mà Claude từng thấy. Một phương pháp tốt nhất (best practice) chung chung cho một vấn đề chung chung tại một công ty chung chung. Nói cách khác, nó được thiết kế cho không ai cả.

Kiến trúc thực sự chứa đầy những sự đánh đổi chỉ hợp lý trong bối cảnh cụ thể. Bạn chọn Postgres thay vì DynamoDB vì team bạn biết Postgres và bạn muốn ra mắt trong hai tuần thay vì mất một tháng để học mô hình dữ liệu mới. Bạn bỏ qua service mesh vì bạn có bốn dịch vụ, không phải bốn mươi. Bạn dùng monolith vì vấn đề đơn giản và microservices chỉ là sự phát triển theo định hướng sự nghiệp (career-driven development).

Những quyết định này cần sự phán xét. Chúng đòi hỏi việc hiểu team. Chúng đòi hỏi sự hiểu biết về các ràng buộc thực tế của tổ chức, không phải những ràng buộc trông đẹp trên bảng trắng. Một tác nhân AI không có bất kỳ bối cảnh nào trong số này, và tệ hơn — nó không biết là mình không có.

Đường ống thẻ Jira

Điều thực sự khiến tôi lo lắng là những gì xảy ra tiếp theo.

Khi Claude đã thiết kế xong kiến trúc, những người đã yêu cầu nó thiết kế lại nhờ nó chia nhỏ công việc. Nó tạo ra các Epic, Story, tiêu chí chấp nhận. Được định dạng gọn gàng, lập luận chặt chẽ, sẵn sàng thả vào Jira.

Và bây giờ, các kỹ sư — những người đã dành nhiều năm để mài giũa nghề nghiệp, những người hiểu rõ lĩnh vực, những người biết "xác chết chôn ở đâu" — không còn giải quyết vấn đề nữa. Họ đang triển khai thiết kế của Claude, từng thẻ một.

Hãy suy nghĩ về những gì vừa xảy ra. Những người có nhiều bối cảnh nhất, nhiều kinh nghiệm nhất và chịu ảnh hưởng lớn nhất đã bị giảm xuống thành người triển khai thẻ. Thực thể có ít bối cảnh nhất, không có kinh nghiệm và không chịu trách nhiệm lại là người đưa ra các quyết định kiến trúc.

Không chỉ là kém hiệu quả. Đó là sự lộn ngược.

"Nhưng đã có người cấp cao duyệt"

Đây là lời bào chữa tôi nghe nhiều nhất. "Claude đề xuất cách tiếp cận này, nhưng một kỹ sư cấp cao đã xem xét nó."

Hãy thành thực về ý nghĩa của "đã xem xét" trong thực tế. Một tech lead bận rộn được đưa một đề xuất kiến trúc hùng hồn. Nó mạch lạc. Nó dùng đúng thuật ngữ. Nó giải quyết các yêu cầu đã nêu. Sơ đồ có ý nghĩa. Nó trông giống như thứ chính họ có thể đã thiết kế.

Họ sẽ phản biện bao nhiêu? Trong một thế giới nơi câu trả lời cho "Tôi nghĩ cái này không đúng" là "Claude đã mất hai mươi phút cho cái này mà bạn muốn vứt đi sao?", con đường kháng lực ít nhất là phê duyệt nó với vài nhận xét nhỏ.

Đây là mối nguy hiểm thực sự. Không phải là AI tạo ra kiến trúc tồi — nó thường tạo ra những kiến trúc hoàn toàn hợp lý. Mối nguy hiểm là nó làm tắt ngắn cuộc thảo luận. Quá trình lộn xộn, tranh cãi, tốn thời gian nơi ba kỹ sư bất đồng về cách tiếp cận, nơi ai đó nói "nhưng cái này thì sao..." và mọi người rên rỉ nhưng sau đó nhận ra đó là một ý hay, nơi thiết kế cuối cùng tốt hơn bất cứ thứ gì một người tạo ra — quá trình đó bị thay thế bằng "Claude nói thế".

Khoảng trống trách nhiệm

Đây là câu hỏi không ai đặt ra: khi mọi thứ sai, ai chịu trách nhiệm?

Không phải Claude. Claude không có túi đựng đồ. Claude không bị gọi trang lúc 3 giờ sáng. Claude không ngồi trong cuộc họp rút kinh nghiệm sau sự cố giải thích tại sao kiến trúc không chịu được tải. Claude không phải nói với CTO rằng nền tảng cần được viết lại vì các giả định thiết kế ban đầu sai.

Kỹ sư của bạn thì có. Những kỹ sư đã không thiết kế nó. Những kỹ sư đang triển khai các thẻ được viết bởi một thực thể chưa bao giờ vận hành hệ thống trong môi trường production. Họ là những người phải làm thêm giờ, gỡ lỗi một kiến trúc họ không chọn, trong một codebase được dựng nhanh hơn mức bất kỳ ai có thể hiểu được.

Đó không công bằng. Và không thông minh.

Thay vào đó nên làm gì

Tôi không nói là đừng dùng tác nhân AI. Tôi dùng Claude Code mỗi ngày. Nó đã thay đổi năng suất của tôi. Nhưng tôi dùng nó theo cách bạn dùng bất kỳ công cụ mạnh nào — tôi bảo nó làm gì, không phải ngược lại.

Kỹ sư thiết kế. Tác nhân thực thi. Kiến trúc đến từ những người hiểu bối cảnh — team, các ràng buộc, môi trường production, chính trị tổ chức. AI giúp họ xây dựng nhanh hơn. Đó là sự phân chia lao động đúng đắn.

Thách thức sự tán dương. Khi AI đề xuất cách tiếp cận, hãy đối xử với nó bằng sự hoài nghi giống như bạn áp dụng cho một kỹ sư junior tự tin quá mức. Nó có thể đúng. Nó cũng có thể đang khớp mẫu với một thứ không áp dụng cho trường hợp của bạn. Hãy hỏi "tại sao không chọn phương án đơn giản hơn?" và xem điều gì xảy ra.

Bảo vệ cuộc tranh luận. Sự bất đồng lộn xộn giữa các kỹ sư là nơi kiến trúc tốt xuất hiện. Nếu AI đang làm tắt ngắn quá trình này — nếu mọi người đang nhường chỗ cho Claude thay vì tranh luận với nhau — bạn đã mất thứ gì đó quý giá hơn nhiều tốc độ phát triển.

Giữ cho con người chịu trách nhiệm. Nếu tên của một con người không nằm trong quyết định kiến trúc, không ai sở hữu nó. Và nếu không ai sở hữu nó, không ai sẽ chiến đấu cho nó khi cần thiết. "Claude thiết kế nó" không phải là một bản ghi quyết định kiến trúc. Đó là sự từ bỏ trách nhiệm.

Nghề vẫn quan trọng

Ba mươi năm trước, khi tôi bắt đầu trong ngành này, công cụ là bảng trắng và một ý kiến mạnh mẽ. Ngày nay công cụ là tác nhân AI có thể tạo ra trong vài phút thứ từng mất vài ngày. Tốc độ thực sự đáng kinh ngạc.

Nhưng bản chất của nghề chưa thay đổi. Hiểu vấn đề. Biết các ràng buộc. Đưa ra sự đánh đổi. Bảo vệ giải pháp đơn giản trước giải pháp hào nhoáng. Nói "không" với ý tưởng nghe hay nhưng không phù hợp.

Đó là kiến trúc. Không tác nhân nào làm được điều đó. Nếu bạn đã để Claude cầm lái, hãy lấy lại.

Các kỹ sư của bạn đã dành nhiều năm để xây dựng sự phán xét để đưa ra những quyết định này. Hãy để họ đưa ra quyết định. Dùng AI để xây dựng nhanh hơn. Nhưng hãy xây dựng những gì con người thiết kế — không phải thứ máy móc gợi ý.

Bởi vì khi tháp Jenga rung lắc — và nó sẽ rung lắc — Claude sẽ không ở đó để đỡ nó.