Hệ thống của bạn đã có những điểm mù. AI chỉ làm chúng tồi tệ hơn.

Vào năm 2022, trước khi các công cụ mã sinh tạo trở thành một phần trong công việc kỹ thuật hằng ngày của chúng tôi, tôi đã viết về triết lý của tôi về việc lựa chọn công cụ. Nó đã bền vững hơn so với mong đợi của tôi. Khi đó, tôi lập luận rằng nên bắt đầu với những vấn đề bạn thực sự đang giải quyết, hiểu rõ điểm yếu của mình, và ưu tiên cách bạn sử dụng các công cụ thay vì chỉ lao vào bất kỳ công cụ nào nghe có vẻ tốt nhất và hy vọng nó sẽ hoạt động. Hãy hiểu bản thân, và mục tiêu của mình, để bạn có thể đặt kỳ vọng phù hợp cho các công cụ của mình.

Lúc đó, tôi đang suy nghĩ về sự lan rộng của SaaS, không phải mã do AI tạo ra. Nhưng hôm nay, triết lý của tôi còn cấp bách hơn, và quan trọng hơn để kiên trì.

Nhiều người trong chúng tôi đã đọc báo cáo DORA 2025, trong đó phát hiện rằng, không giống năm trước, việc áp dụng AI hiện nay có mối tương quan tích cực với năng suất giao hàng. Phát hiện bên dưới là sự không ổn định trong giao hàng vẫn tiếp tục tăng, và họ đã kiểm tra xem lợi nhuận tốc độ có bù đắp được không. Họ không. Điều đó phù hợp với kinh nghiệm của chúng tôi. Nhóm của chúng tôi đã áp dụng phát triển phần mềm có tính năng tự động và thấy tăng 48% năng suất trong hai quý, tiếp theo là tăng 16% các vấn đề về ổn định. Mười người là một mẫu nhỏ, nhưng cũng là mẫu cho phép tôi nhìn thấy toàn cảnh, và xu hướng vẫn giữ nguyên. 

Việc áp dụng AI không còn là một câu hỏi nữa. Bạn hoặc là mới bắt đầu hoặc đã sâu vào trong. Điều khác biệt bây giờ là các lãnh đạo kỹ thuật được kỳ vọng sẽ áp dụng AI và đồng thời chứng minh rằng nó đang mang lại lợi ích. CEO, ban giám đốc và bộ tài chính đều muốn biết cách tối ưu hóa khoản đầu tư AI của họ. Họ đang hỏi liệu các công cụ bạn chọn có giải quyết vấn đề thực sự một cách hiệu quả hay không. 

Khoảng cách luôn tồn tại. AI chỉ làm nó rộng hơn.

Là một CTO, tôi dành một phần đáng kể thời gian để nói chuyện với các lãnh đạo kỹ thuật khác, bao gồm khách hàng, tiềm năng và đồng nghiệp của tôi, để so sánh thành tựu và phàn nàn về những gì chúng tôi đang trải nghiệm với AI. Sau một số lượng đủ các cuộc trò chuyện này, tôi bắt đầu nhận thấy các mô hình trong việc áp dụng AI và kết quả.

Quan sát chính không phải của tôi. DORA đã dẫn đầu với quan điểm này trong hai năm qua: AI khuếch đại bất kỳ điều gì đang diễn ra trong tổ chức, cả điểm mạnh và điểm yếu. Một đội có kiến trúc sạch sẽ và thói quen kiểm tra lành mạnh sẽ nhanh hơn. Một đội đã kiểm soát một đống nợ kỹ thuật rối rắm đủ để triển khai mã bây giờ nhận thấy nợ kỹ thuật đang trở thành một rào cản lớn. Tuy nhiên, cách diễn đạt này bỏ qua lý do tại sao điều này khiến nhiều đội bất ngờ. AI không che giấu những điểm yếu này; các hệ thống mà chúng ta dựa vào chưa bao giờ làm chúng lộ ra.

Hệ thống ticket và báo cáo mà hầu hết các tổ chức kỹ thuật sử dụng được xây dựng để trả lời các câu hỏi mà con người đặt ra, với tốc độ con người, bởi những người hiểu sơ qua ý nghĩa của “hoàn thành” cho một công việc cụ thể. Nó không bao giờ là một bản ghi hoàn hảo. Nó luôn là một ước lượng, được lấp đầy bởi người tóm tắt những thứ phức tạp hơn bên dưới. Bây giờ, AI tăng khối lượng, và thêm các đầu vào mới tạo ra hoạt động mới. Không có hệ thống (hoặc công cụ) nào được sử dụng cho các phương pháp phát triển truyền thống, không AI, được xây dựng cho mục đích đó. 

Dù sao, chúng ta vẫn chịu trách nhiệm cho cùng các mục tiêu. Bạn vẫn chịu trách nhiệm về tốc độ, chất lượng, chi phí, và cách đội của bạn thực sự hoạt động. Bạn không còn có thể tin tưởng vào các bảng điều khiển của năm trước nữa. 

Có một phản biện hợp lý ở đây. báo cáo ROI 2026 của DORA mô tả một đường cong J: sự giảm năng suất ngay sau khi áp dụng, do đường cong học tập, chi phí xác minh mã do AI tạo ra, và các quy trình hạ nguồn chưa bắt kịp. Họ gọi đó là “chi phí đào tạo” của quá trình chuyển đổi, và họ cảnh báo các nhà lãnh đạo không nhầm lẫn nó với thất bại. Điều đó hợp lý. Nhưng chi phí đào tạo và một vấn đề thực sự trông giống nhau trên một bảng điều khiển được xây dựng từ các ticket. Nếu bạn không thể phân biệt mình đang ở đâu, bạn không kiên nhẫn. Bạn đang đoán mò.

Chúng ta cần quay lại những nền tảng cơ bản. Hãy hiểu bản thân. Hãy hiểu đội của bạn. Hãy hiểu những vấn đề bạn đang giải quyết. 

Làm thế nào để “Hiểu bản thân” với AI?

Từ các cuộc trò chuyện của tôi, tôi đã xác định được năm lĩnh vực chính mà các hệ thống truyền thống, được xây dựng cho công việc do con người tạo ra và báo cáo, đang mù. Bỏ qua chúng và bạn sẽ có nguy cơ khuếch đại điểm yếu của mình khi tiếp tục áp dụng AI.

Điểm mù 1: Rạp chiếu tốc độ

Nhiều commit và nhiều PR có thể cảm thấy như tiến bộ, và thường là như vậy. AI tự động tăng cả hai số lượng. Một nghiên cứu trường hợp Stanford cho thấy việc áp dụng AI đã tăng số lượng PR lên 14%. Nhưng điều bạn đang bỏ lỡ là bao nhiêu trong số hoạt động đó là công việc tính năng được phát hành so với bảo trì, tái làm, hoặc sự dao động từ một việc tái cấu trúc không bền vững.

Để giải quyết vấn đề này, hãy theo dõi sự phân chia giữa công việc tính năng và bảo trì, và theo dõi tần suất triển khai và thời gian lead so với chuẩn lịch sử của riêng bạn, không phải mức trung bình ngành. Nếu không có sự phân chia này, bạn đang báo cáo tiến độ mà không thể chứng minh thực tế.

Điểm mù 2: Nợ kiểm tra

Khả năng xem xét không tự động tăng tỷ lệ cùng với sản lượng. Thuế xác minh không phải là một giai đoạn bạn chỉ cần vượt qua; nó là một phần của chi phí cố định cho phát triển có tính tự động. Một khảo sát gần đây của các nhà lãnh đạo kỹ thuật đã phát hiện 80% các đội dành ít nhất 10% thời gian của họ cho việc xem xét, và khoảng một trong mười dành hơn 40%. Dưới tải này, các đội dao động giữa việc tồn đọng ngày càng tăng và việc chấp nhận hời hợt, và cả hai đều không phải là giải pháp thực sự.

Ràng buộc trong việc phát hành không còn là tốc độ viết mã nữa. Mà là có thể nhanh chóng và thực sự tự tin rằng một thay đổi là đúng, có thể nhanh và chính xác trong việc phát hiện và giải quyết lỗi. Hãy theo dõi cách tải công việc xem xét thực sự được phân phối trong toàn đội; nếu không, bạn sẽ gây quá tải cho các kỹ sư cấp cao, trì hoãn các bản phát hành, hoặc gây ra các vấn đề nghiêm trọng trong sản xuất.

Điểm mù 3: Công việc ẩn

Việc tái cấu trúc và thay đổi kiến trúc thường có thói quen ẩn mình trong các ticket khác, nếu chúng xuất hiện trong hệ thống ticket chút nào. AI tạo ra nhiều công việc kiểu này hơn, không phải ít hơn. Một tác nhân không ngần ngại chạm vào mười hai tệp để sửa một lỗi, trong khi con người có thể dừng lại và cân nhắc lại. Công việc bỏ qua hệ thống ghi chép cũng bỏ qua việc lập kế hoạch, đồng nghĩa với việc mô hình năng lực của bạn sai, và mọi dự báo dựa trên nó cũng sai.

Để hiểu được bao nhiêu công việc thực sự đang được thực hiện, bạn cần theo dõi mức độ thay đổi thực tế trong cơ sở mã và lịch sử pull request. Nếu không có điều đó, kế hoạch năng lực của bạn được xây dựng dựa trên những gì mọi người nhớ ghi lại, chứ không phải những gì họ thực sự đã làm.

Điểm mù 4: Sự trôi dạt chất lượng

Khảo sát cùng ấy phát hiện gần một nửa các nhà lãnh đạo kỹ thuật gặp khó khăn trong việc phát hiện các vấn đề bảo mật hàng tuần. Sự phức tạp, trùng lặp và các phụ thuộc không thực sự phù hợp tích lũy qua nhiều thay đổi nhỏ, mỗi thay đổi đều hợp lý riêng biệt. Không có gì trong số chúng trông đáng lo ngại khi xét riêng lẻ. Trong cùng nghiên cứu trường hợp của Stanford, chất lượng mã giảm 9% và độ biến động của nó tăng hơn ba lần. Trong khi mức trung bình chỉ thay đổi chút ít, độ phân tán (phần bạn nhận thấy) lại thay đổi đáng kể. Ở khối lượng AI, chúng tích lũy nhanh hơn so với khả năng của hầu hết các quy trình xem xét để kịp bắt kịp. Sự trôi dạt thường xuất hiện dưới dạng cảnh báo khi trực, được truy nguồn trở lại một phụ thuộc mà không ai nhớ đã xem xét. Khi điều này xảy ra, khả năng khách hàng đã nhận ra trước đó là khá cao.

Hãy theo dõi các đường xu hướng về các phát hiện bảo mật, phụ thuộc, và các sự cố và phục hồi — không phải từng commit riêng lẻ. Sự phức tạp và trùng lặp tích tụ trong vài tuần quan trọng hơn bất kỳ thay đổi nào bị đánh dấu trong quá trình xem xét. Nếu không có điều đó, bạn sẽ bắt được sự trôi dạt theo cách mà hầu hết các đội vẫn làm: sau khi nó đã gây ra một sự cố.

Điểm mù 5: Chi tiêu chưa được chứng minh

Khi việc áp dụng AI không còn là tranh cãi, chi tiêu AI và ROI trở thành câu hỏi mà mọi người tập trung. Bộ tài chính muốn biết gì có thể vốn hoá và gì là chi phí hoạt động. Lãnh đạo muốn biết đầu tư đã mang lại gì. Hầu hết các đội vẫn đang đưa ra quyết định về công cụ, chỗ ngồi và số lượng nhân sự dựa trên trực giác, chứ không phải bằng bằng chứng về mối liên hệ giữa tiền bạc và công việc đã giao.

Hãy theo dõi nơi nỗ lực kỹ thuật thực sự chảy trong chính cơ sở mã, từng quý một — không phải nơi lộ trình nói rằng nó nên chảy. Nếu thiếu liên kết đó, bạn sẽ bảo vệ ngân sách năm tới bằng những giai thoại, và những giai thoại không thể tồn tại trong cuộc trò chuyện nghiêm túc với CFO.

Bắt đầu với những gì bạn không thể thấy

Câu hỏi của tài chính về chi tiêu được vốn hoá và một trang cảnh báo khi trực vào lúc 2 giờ sáng có vẻ không liên quan, nhưng thực tế không phải. Cả hai đều có thể được “ước lượng” dựa trên hoạt động. Tuy nhiên, cả hai thực sự có thể trả lời, với bằng chứng, từ chính mã nguồn.

Câu trả lời của DORA cho tất cả những điều này là hệ thống kỹ thuật tự nó: chất lượng nền tảng, sự rõ ràng trong quy trình làm việc, sự đồng nhất của đội. Đúng vậy, và đó cũng không phải là bước đầu tiên. Bạn không thể cải thiện một hệ thống mà bạn không thể nhìn thấy. Mỗi trong năm khu vực đó là điều bạn phải quan sát được trước khi có thể lập luận để đầu tư vào chúng.

Bước hữu ích đầu tiên không phải là một công cụ mới hay một quy trình mới. Đó là việc hiểu rõ bản thân, một cách trung thực, và xác định những khu vực trong năm này là điểm mù mà bạn thiếu bằng chứng thực tế. Hầu hết các nhà lãnh đạo có thể ngay lập tức nhận ra (và đang chú ý tới) các vấn đề trong một trong những khu vực này. Tuy nhiên, chính những khu vực mà bạn có ít thông tin nhất lại có khả năng xuất hiện và gây rắc rối cho bạn khi bạn tiếp tục áp dụng AI.