Khoảnh khắc một CTO ngừng đọc code — và vì sao đó không còn là nỗi sợ đúng đắn
Có một câu châm ngôn truyền thống về CTO được lặp lại suốt nhiều thập kỷ:
Khoảnh khắc bạn ngừng đọc code, bạn bắt đầu đưa ra những quyết định công nghệ tồi.
Chính tôi cũng từng nói như vậy.
Tôi đã chứng kiến những kỹ sư tài năng trở thành giám đốc, rồi VP, rồi CTO. Lịch của họ đầy ắp các buổi họp chiến lược, họp hội đồng quản trị, đàm phán nhà cung cấp, tuyển dụng, ngân sách, mua bán sáp nhập và thiết kế tổ chức. Họ viết ít code hơn. Cuối cùng họ hoàn toàn ngừng đọc code.
Sáu tháng sau, họ đưa ra các quyết định nền tảng dựa trên sơ đồ kiến trúc, bản tóm tắt điều hành và bài trình bày của nhà cung cấp.
Đó là cách các quyết định kỹ thuật tồi tệ ra đời. Lời khuyên đó hoàn toàn có lý vì phần mềm luôn trừng phạt sự xa rời thực tế. Nếu bạn không thấy được các kỹ sư thực sự đang xây dựng thứ gì, bạn sẽ đánh mất trực giác của mình. Bạn ngừng nhận ra sự phức tạp ngẫu nhiên.
Bạn đánh giá thấp nợ kỹ thuật.
Bạn phê duyệt những kiến trúc trông thanh lịch trong PowerPoint nhưng sụp đổ dưới lưu lượng vận hành thực tế. Đọc code không chỉ là biết cú pháp. Đó là giữ kết nối với thực tế. Trong phần lớn sự nghiệp của mình, tôi hoàn toàn tin vào điều đó.
Ngày nay, tôi nghĩ điều đó chưa đầy đủ. Không phải vì việc hiểu hệ thống ít quan trọng hơn. Mà vì AI đã thay đổi căn bản cách chúng ta đạt được sự hiểu biết đó.
Đọc code chưa bao giờ là mục tiêu
Hãy thành thật. Không ai trở thành CTO vì thích đọc những class dài 4.000 dòng. Chúng ta đọc code vì đó là cách duy nhất đáng tin cậy để hiểu một hệ thống. Nếu bạn muốn biết xác thực thực sự hoạt động thế nào… bạn sẽ lần theo yêu cầu đó.
Nếu bạn muốn hiểu vì sao hàng tồn kho thỉnh thoảng bị bế tắc… bạn sẽ lần theo luồng thực thi.
Nếu bạn muốn biết một kiến trúc được đề xuất có thực tế hay không… bạn sẽ tự mình đào sâu vào phần triển khai.
Đọc code không phải là mục đích. Hiểu mới là mục đích. Trước đây hai điều đó đơn giản là một. Cho đến bây giờ.
AI đã thay đổi kinh tế học của sự hiểu biết
Các codebase lớn đã trở nên quá phức tạp đối với bất kỳ cá nhân nào. Các doanh nghiệp hiện đại thường xuyên quản lý hàng trăm repository, hàng nghìn microservice, hàng triệu dòng code, nhiều ngôn ngữ lập trình và hàng thập kỷ nợ kỹ thuật tích lũy.
Ngay cả một CTO xuất sắc cũng không thể tự mình hiểu mọi tương tác quan trọng. Vấn đề không phải là trí tuệ. Mà là băng thông.
AI thay đổi phương trình đó. Thay vì đọc hàng nghìn file với hy vọng phát hiện ra các quy luật, tôi có thể đặt những câu hỏi mà trước đây phải mất nhiều ngày để một nhóm trả lời. Không phải vì AI thay thế phán đoán kỹ thuật. Mà vì nó tăng tốc đáng kể việc khám phá kỹ thuật.
Đó là một sự phân biệt quan trọng. AI không đưa ra quyết định kiến trúc. Nó giúp tôi đi đến những quyết định tốt hơn nhanh hơn.
Năm cách tôi dùng AI mỗi tuần
Mọi người thường hỏi tôi điều này trông như thế nào trong thực tế. Đây là những mô hình tôi dựa vào nhiều nhất.
1. Khám phá code bằng tác tử. Thay vì mở hàng chục file, tôi giao cho một tác tử AI một nhiệm vụ điều tra cụ thể — lập bản đồ luồng xác thực trên mọi dịch vụ, làm nổi bật nơi danh tính được truyền đi một cách ngầm định. Vài phút sau, tôi có các đường dẫn thực thi, các phụ thuộc ẩn, các giả định ngầm và các mối lo ngại tiềm ẩn về bảo mật. Điều từng đòi hỏi nhiều kỹ sư và nhiều ngày nay trở thành một cuộc trò chuyện tương tác.
2. Phân tích phụ thuộc kiến trúc. Câu hỏi khó nhất trong phần mềm lại đơn giản đến mức dễ gây hiểu lầm: nếu chúng ta thay đổi điều này, cái gì sẽ hỏng? Ngày nay AI có thể kết hợp phân tích repository, đồ thị phụ thuộc, hợp đồng API, luồng sự kiện, cấu hình hạ tầng và kiểm thử tích hợp thành một đánh giá tác động được sắp xếp theo mức ưu tiên.
3. Phân loại pull request. Tôi không còn giả vờ đọc từng pull request nữa. Mọi thay đổi quan trọng đều đi qua vòng đánh giá của AI — liệu nó có vi phạm các mô hình kiến trúc, gây ra lo ngại về bảo mật, làm rò rỉ logic nghiệp vụ, hay làm tăng sự phụ thuộc? Một tỷ lệ nhỏ thực sự xứng đáng được cấp điều hành chú ý sẽ tự động nổi lên trên cùng.
4. Bản đồ nhiệt nợ kỹ thuật. Nợ kỹ thuật tạo thành các mô hình, và AI có thể xác định những cụm có liên quan đến các sự cố vận hành trong tương lai: chiến lược thử lại không nhất quán, thiếu khả năng quan sát, phụ thuộc vòng tròn, xử lý lỗi mong manh. Thay vì hỏi "chúng ta nên cải thiện ở đâu?", tôi hỏi "sáu tháng nữa, chúng ta có nhiều khả năng gặp đau đớn vận hành ở đâu nhất?"
5. Mô phỏng quyết định kiến trúc. Trước một cuộc di trú lớn, tôi yêu cầu AI mô phỏng các kết quả có khả năng xảy ra — không phải để dự đoán tương lai, mà để phơi bày các giả định, điểm nghẽn, chế độ hỏng hóc và các phụ thuộc tổ chức. Nó không loại bỏ sự bất định. Nó khiến sự bất định trở nên hữu hình.
AI không thay thế khả năng lãnh đạo kỹ thuật
Mỗi khi tôi nói về điều này, cuối cùng sẽ có người nói: "Nhưng AI cũng mắc lỗi." Đúng vậy. Con người cũng thế. Khác biệt là tôi không bao giờ ủy thác việc phán đoán. Tôi ủy thác việc điều tra.
Tôi vẫn thách thức các kết luận. Tôi vẫn xác minh các giả định. Tôi vẫn đặt những câu hỏi khó cho các kỹ sư. Tôi vẫn đòi hỏi bằng chứng. Quyết định kiến trúc cuối cùng vẫn thuộc về tôi. AI chỉ đơn giản đảm bảo tôi bắt đầu với nhiều thông tin hơn mức tôi có thể tự mình thu thập một cách hợp lý. Đó là tăng cường, không phải tự động hóa.
Công việc của CTO đã thay đổi
Tôi không còn tin rằng giá trị cao nhất của một CTO đến từ việc là lập trình viên giỏi nhất. Nó đến từ việc đặt ra những câu hỏi kỹ thuật hay nhất. Rủi ro nằm ở đâu? Cái gì đang bị ràng buộc mà lẽ ra không nên? Những giả định nào đang bị che giấu? Năm tới chúng ta sẽ gặp khó khăn ở đâu?
AI gia tăng đáng kể khả năng của tôi trong việc trả lời những câu hỏi đó. Điều đó không làm cho chuyên môn kỹ thuật kém giá trị đi. Nó khiến đòn bẩy trở nên giá trị hơn.
Lợi thế cạnh tranh thực sự
Mười năm trước, CTO giỏi nhất thường biết nhiều code hơn tất cả mọi người. Ngày mai, CTO giỏi nhất sẽ hiểu nhiều hệ thống hơn tất cả mọi người. Đó không phải là cùng một kỹ năng.
Hiểu hệ thống nghĩa là kết nối công nghệ với vận hành. Nghĩa là nhận ra các mô hình đang hình thành trước khi chúng trở thành sự cố gián đoạn. Nghĩa là nhìn xuyên suốt hàng trăm repository thay vì trở thành chuyên gia về một repository duy nhất. AI khiến mức độ hiển thị đó trở nên khả thi. Phớt lờ nó không bảo toàn được kỷ luật kỹ thuật. Nó chỉ giới hạn khả năng lãnh đạo.
Nỗi sợ mới
Trong nhiều năm, chúng ta lo lắng về CTO ngừng đọc code. Đó là một mối lo chính đáng. Ngày nay tôi lo về một điều khác.
Tôi lo về CTO vẫn tin rằng việc đọc code bằng tay là con đường duy nhất dẫn tới sự hiểu biết.
Lãnh đạo công nghệ luôn xoay quanh việc gia tăng đòn bẩy. Trình biên dịch thay thế hợp ngữ. Framework thay thế code boilerplate. Nền tảng đám mây thay thế phòng máy chủ. AI chỉ đơn giản là bước tiếp theo trong tiến trình đó. Mục tiêu không hề thay đổi: hiểu hệ thống của bạn đủ sâu để đưa ra quyết định tốt hơn. Cách chúng ta đạt được điều đó… đã thay đổi.
CTO đón nhận AI sẽ không hiểu ít hơn về công nghệ của mình. Họ sẽ hiểu nhiều hơn bao giờ hết về nó.
Nghĩ rằng lập luận này phù hợp với sự kiện của bạn? Hãy kể cho tôi về khán phòng — lịch trình có chọn lọc.
Bắt đầu trò chuyện