Các quy tắc lãnh đạo kỹ thuật đã được sửa đổi

• Tổng hợp 5 quy tắc lãnh đạo kỹ thuật đã được kiểm chứng và tái định hình trong 1 năm qua trong bối cảnh chuyển sang công cụ AI và tăng trưởng siêu tốc (hypergrowth), cùng với các ví dụ dự án thực tế làm nền tảng cho các quy tắc đó
• Migration giờ đây không còn do cả nhóm mà có thể được cá nhân dẫn dắt tới 95%, hoàn thành chỉ trong 10% thời gian trước đây; chi phí khởi đầu càng thấp thì ảnh hưởng của phán đoán cá nhân càng lớn
• Bản nháp mã đầu tiên gần như miễn phí, nhưng chi phí để có mã chạy tốt lại phụ thuộc vào development harness như test, CI/CD, v.v., nên không hề miễn phí
• Trường hợp cơ bản của hầu hết quy trình có thể được tự động hóa hoàn toàn bằng agent, và lượt đầu của code review cũng nhanh hơn, hiệu quả hơn con người nếu có harness tốt
• Để thực sự hưởng lợi từ AI thì điều kiện tiên quyết là đội ngũ bền vững có domain context và ra quyết định nhanh, vững chắc

---

Bối cảnh

• Tác giả làm việc trong môi trường hypergrowth từ đầu 2014 đến cuối 2020; giá trị lớn nhất của hypergrowth là sai lầm lộ ra vào tháng sau chứ không phải năm sau (di chuyển quá nhanh thì vấn đề sẽ bùng phát lớn)
• Gần đây nhớ lại hypergrowth vì tăng trưởng kinh doanh nhanh của Imprint, đợt tuyển dụng lớn năm ngoái, và việc chuyển sang công cụ AI đã làm thay đổi tốc độ có thể hoàn thành công việc
• Bài viết này tổng hợp cả các quy tắc lãnh đạo đã được tái định hình lẫn những dự án cụ thể trong 1 năm qua đã tạo nên các niềm tin đó

Các quy tắc đã sửa đổi

1. Migration có thể do cá nhân thực hiện, không cần cả nhóm

• Ngay cả thay đổi lớn và phức tạp cũng có thể được một cá nhân hoặc một nhóm sở hữu 95%, và hoàn thành chỉ trong 10% thời gian so với trước đây
• Chi phí khởi đầu càng thấp thì thưởng/phạt theo chất lượng của từng migration càng lớn
  • Chỉ một lỗi nhỏ cũng có thể làm sụp đổ mental model phần mềm của đồng nghiệp cùng bảo trì hệ thống đó
• Ảnh hưởng của phán đoán cá nhân lên công ty hiện lớn hơn bao giờ hết

2. Bản nháp mã đầu tiên gần như miễn phí, nhưng chi phí của mã chạy được phụ thuộc vào development harness

• Đây là thời đại mà ai cũng nên viết code, nhưng việc viết mã chạy tốt mà không né tránh các edge case lộn xộn vẫn rất khó
• Độ khó đó được quyết định bởi development harness như test, CI/CD, môi trường xác minh, preview thay đổi, v.v.
• Ngay cả ở công ty nơi “ai cũng code”, điều cốt lõi không phải là đội marketing đi tinh chỉnh việc cấp phát server, mà là có tồn tại ranh giới để họ tham gia một cách an toàn hay không (tương tự các sản phẩm SaaS cho phép tùy biến bằng cách viết phần mềm)
• Những thứ giá trị nhất để tăng tốc độ kỹ thuật cách đây 2 năm đến nay vẫn là những thứ giá trị nhất

3. Tối ưu trường hợp cơ bản của quy trình cho agent

• Nếu có harness, kiểm soát, domain context phù hợp và phán đoán tốt từ người thiết kế, thì trường hợp cơ bản của hầu hết quy trình có thể được tự động hóa hoàn toàn
• Trường hợp cơ bản của code review do con người thực hiện chậm hơn và kém hiệu quả hơn code review bằng harness tốt
  • Harness có thể bỏ sót, nhưng con người cũng vậy; và trong đa số khu vực, thay đổi là tương đối an toàn
  • Tuy vậy vẫn có ngoại lệ ở một số khu vực rủi ro cao; nếu nắm đúng ranh giới này thì có thể tăng tốc mà không tăng rủi ro, còn nếu thất bại thì sẽ phát sinh vô số vấn đề
• Hệ quả là các quy trình lập kế hoạch như sprint hàng tuần hoặc hai tuần một lần đang hoạt động ở mức độ quá thấp, và việc cùng nhau lập kế hoạch của con người cần diễn ra ở tầng cao hơn

4. Đội ngũ bền vững, sở hữu cao và có domain context còn quan trọng hơn

• Bài học từ Uber: đội ngũ bền vững và vững chắc tạo ra kết quả gần như kỳ diệu nhờ tích lũy domain context, xây dựng tình đồng đội và tinh thần sở hữu mạnh
• Ngay cả khi chi phí thực thi đã rẻ hơn, vẫn phải làm đúng việc; điều này chỉ dễ hơn một chút chứ không hề dễ đi nhiều
  • Ví dụ: dữ liệu cần thiết để tối ưu production hoàn toàn không được thu thập, nên lời giải của harness tuy hợp lý nhưng lại sai; cách duy nhất để xử lý là instrument phần thông tin còn thiếu
• Tác giả phản đối quan niệm rằng công ty AI-first có thể vận hành chỉ với một số ít kỹ sư thiên tài; ngay cả cá nhân có phán đoán rất tốt cũng sẽ đụng giới hạn vì thiếu domain context, nên đơn vị nền tảng vẫn là đội ngũ bền vững

5. Ra quyết định nhanh, tốt và vững chắc là điều kiện tiên quyết để hưởng lợi từ AI

• Muốn thay thế việc legal review bằng tự động hóa thì bộ phận Legal phải có khả năng cam kết với thay đổi đó, và điều này phụ thuộc vào thiết kế cẩn trọng cùng ý chí hợp tác của các nhóm
• Lợi ích từ việc tăng tốc độ thực thi chỉ có được khi có thể đưa ra quyết định nhanh, vững chắc và đúng đắn
• Đây là lý do chính khiến vai trò CTO trung bình ngày nay trở nên mang tính kỹ thuật hơn và bớt quan liêu hơn rất nhiều so với 1 năm trước
  • Trong trường hợp các nhóm bất đồng, thường chỉ có một người có thể đưa ra quyết định ràng buộc, nên để giữ tốc độ họ phải liên tục ra quyết định
  • Điều này không có nghĩa lãnh đạo cấp cao là người ra quyết định tốt hơn, mà là miễn họ thống nhất với nhau và tôn trọng quyết định, thì quyết định ràng buộc từ cấp điều hành có sức mạnh vượt trội

Các trường hợp áp dụng thực tế

Migration

• 1 năm trước còn deploy thủ công khoảng 6 lần/tuần → hiện tại 200~400 lần deploy mỗi tuần; số kỹ sư chỉ tăng gấp đôi nhưng tăng trưởng YoY đạt 20~30 lần; toàn bộ cách vận hành deploy và migration được 2 người trong đội hạ tầng thực hiện 90% trong 2 tháng
• Từ 1/1 khoảng 25% dùng Claude Code hoặc Cursor mỗi ngày → đến cuối tháng 2 là 100%; không cần chỉ đạo từ trên xuống, chỉ nhờ chất lượng công cụ tốt hơn và đối thoại với người chưa dùng để loại bỏ ma sát; hiện nay bản nháp đầu tiên của gần như mọi PR đều do harness đảm nhiệm
• Nhiều cách cấu hình khác nhau được hợp nhất thành hai cơ chế cấu hình (một cho các hằng số client/server gần như không đổi, một cho các giá trị thay đổi thường xuyên theo từng sản phẩm), được tiến hành như các dự án độc lập của từng kỹ sư
  • Một người dọn dẹp kiến trúc → người khác triển khai kiến trúc tham chiếu → nhiều người áp dụng sang các khu vực khác; việc trước đây từng là dự án kéo dài nhiều năm giờ hoàn tất trong chưa đầy một quý, bao gồm cả công cụ nội bộ để các nhóm kỹ thuật và phi kỹ thuật quản lý giá trị
• Frontend multi-repo được hợp nhất thành kiến trúc monorepo chỉ trong khoảng 1 tháng, với 95% do 1 kỹ sư frontend dẫn dắt; qua đó có được frontend harness dùng chung và loại bỏ hoàn toàn việc host npm package vốn là nguồn gây ma sát
• Mã frontend vốn phần lớn không có type được chuyển sang static typing đầy đủ, do một kỹ sư thực hiện trong vài tuần với lượng token lớn
• Để có mặc định bảo mật tốt hơn và deploy nhanh hơn, dự án chuyển từ npm sang pnpm được một kỹ sư thực hiện trong vài ngày, mỗi ngày vài tiếng

Chi phí của mã chạy được phụ thuộc vào development harness

• Cách “ném qua tường” design doc hoặc PR cho kỹ sư của nhóm khác không mang lại kết quả; PR hoặc design doc cẩu thả tuy rẻ nhưng thực ra còn có hại
  • Chúng cần được chỉnh lý và sửa lại, và phần context đó còn làm ô nhiễm LLM, dẫn đến kết quả tệ hơn cả việc làm lại từ đầu
• Nếu manager trực tiếp xác minh thay đổi, kiểm tra dashboard sau khi deploy và xử lý vấn đề phát sinh thì đóng góp code của manager là thành công lớn; nếu không thì không tạo ra tác động tích cực

Tối ưu trường hợp cơ bản của quy trình cho agent

• Mọi issue đầu vào của đội vận hành khách hàng được triage bằng harness biết các nhóm, các ticket đang mở và có quyền truy cập hạn chế vào data warehouse để ước tính mức độ ảnh hưởng; nhờ đó xử lý nhanh hơn loại lao động phức tạp, cần kỹ năng cao nhưng không thú vị
  • Edge case vẫn do con người triage; chỉ một số bước được tự động hóa trong cùng flow, không thay đổi workflow của con người
• Lượt đầu của code review được thực hiện bởi chính harness đã tạo ra thay đổi đó nhưng với context viết mã đã được xóa sạch, để con người tập trung vào feedback giá trị cao hơn
• Trong quý vừa qua, Claude Code và Cowork được triển khai toàn công ty; đội fraud đặc biệt tích cực thay thế công việc thủ công bằng tự động hóa ở lượt đầu, tự động thực hiện điều tra ban đầu về các cuộc tấn công tiềm tàng (bao gồm attribution xuất phát từ chính dữ liệu)
• Chuyển từ Jira sang Linear, nhờ MCP mạnh hơn và tích hợp Slack tốt hơn để củng cố hạ tầng workflow ưu tiên agent; việc alpha test harness nội bộ tự động lấy issue từ Linear và tự giải quyết gần như đã hoàn tất

Đội ngũ bền vững, sở hữu cao và có domain context

• Khi mới gia nhập, nhân sự tài năng luân chuyển rất nhanh giữa các khu vực theo từng dự án nên phản ứng rất nhanh; hiện tại ở mọi khu vực quan trọng đều có các nhóm nhỏ chuyên trách để đầu tư liên tục, và chính các nhóm này trực tiếp tận dụng các kỹ thuật AI mới
• Sau khi ra mắt SierraAI, đội ngũ đã liên tục cải thiện để nâng nó lên mức thực sự xuất sắc; đây là thành quả khó có thể đạt được nếu không có một đội ngũ chuyên trách và tập trung

Ra quyết định nhanh, tốt và vững chắc

• Việc thay đổi cách cấu hình gây tranh cãi nên phải lặp đi lặp lại cách tiếp cận; mỗi nhóm chịu ảnh hưởng khác nhau và lợi ích chỉ xuất hiện ở cấp độ hệ sinh thái (một người có thể cấu hình cho toàn bộ nhóm), nên rất khó triển khai theo hướng bottom-up
• Việc làm lại pipeline CI/CD cũng gây tranh cãi vì thay đổi mental model về deploy và release, buộc phải tách deploy và release một cách tường minh bằng feature flag
• Việc hợp nhất web monorepo cũng là quyết định gây chia rẽ ý kiến, nhưng lợi ích của quyết định thống nhất là rất lớn
• Việc áp dụng SierraAI đòi hỏi thảo luận khó khăn giữa các đối thủ cạnh tranh và cả phương án không triển khai, và cần sự phê duyệt của lãnh đạo cấp điều hành để khép lại tranh luận liên chức năng

Kết luận

• Những ví dụ trên chỉ là một phần tiêu biểu, ngoài ra còn rất nhiều việc khác đã được thực hiện; phạm vi những gì có thể làm đang tiếp tục mở rộng qua từng tháng
• Những yếu tố kìm hãm thì không thay đổi nhiều: tổ chức thiếu đồng bộ, thiếu rõ ràng, kiến trúc kỹ thuật yếu kém