Xây dựng tổ chức kỹ thuật thuần AI: Bài học từ 9 tháng thử nghiệm

Khi các tác nhân AI (AI agent) viết mã ngày càng giỏi, nhiều đội ngũ kỹ thuật rơi vào một cái bẫy quen thuộc: tốc độ viết code tăng vọt nhưng sản phẩm cuối cùng lại chẳng nhanh hơn bao nhiêu. Sashank Gondala, đồng sáng lập kiêm CTO của FurtherAI, đã dành 9 tháng để giải bài toán này và chia sẻ những bài học rất đáng tham khảo cho cộng đồng kỹ thuật Việt Nam.

Sashank Gondala

Khối lượng công việc tăng gấp 5 lần, tỷ lệ lỗi gần như bằng không

Từ tháng 1, số lượng thay đổi mã nguồn mà mỗi kỹ sư hợp nhất mỗi ngày đã tăng khoảng 5 lần, trong khi tỷ lệ hoàn tác (revert) vẫn duy trì dưới 0,5%. Đây là con số đáng mơ ước với bất kỳ đội phát triển nào.

Nhưng Gondala nhấn mạnh: chỉ đưa công cụ lập trình AI cho kỹ sư là không đủ. Mỗi khi tăng tốc một công đoạn, công việc lại ùn ứ ở công đoạn kế tiếp. Vì vậy, FurtherAI bắt đầu rà soát toàn bộ quy trình phát hành phần mềm, từng bước một, để tìm ra chỗ cần tối ưu.

Tái cấu trúc quy trình phát hành phần mềm

Đội ngũ đã cải tiến tuần tự theo từng tháng:

• Viết mã (tháng 3): Các tác nhân AI viết code, kỹ sư điều hướng. Đến nay gần 100% thay đổi đều có dấu bàn tay của AI.
• Kiểm thử (tháng 4): AI viết test song song với code. Tỷ lệ thay đổi có kèm test tăng từ 15% lên 91%.
• Đánh giá (tháng 5): AI rà soát 99% thay đổi trước khi con người xem, tăng từ 60%. Người đánh giá có thể tập trung vào những phần cần phán đoán.
• CI (tháng 6): Song song hóa test và chỉ chạy những test bị ảnh hưởng. CI hiện chạy gấp 20 lần số test trong cùng 17 phút.
• Báo cáo lỗi (tháng 7): Dùng ClaudeTag tự động phân loại lỗi trùng lặp, tạo ticket và giao đúng người. Công cụ này xử lý 60% ticket lỗi.
• Quy tắc (tháng 8): Chuyển kiến thức ngầm của kỹ sư thành các kiểm tra Python nhỏ chạy trên mỗi commit. Từ 0 lên 21 quy tắc, giúp AI tự sửa lỗi của chính nó.
• Hợp nhất (tháng 8): Thay đổi rủi ro thấp đạt chuẩn test và đánh giá AI sẽ tự động hợp nhất. Khoảng một phần ba thay đổi hiện không cần con người can thiệp.
• Kênh mã hóa (tháng 9): Bất kỳ ai cũng có thể mở kênh Slack, mô tả thay đổi cho AI và nhận về một PR. Nhiều người có thể cùng làm việc với một tác nhân trong một kênh.

Quy trình phát triển với AI

Điểm thú vị nhất là khi các tác nhân phối hợp với nhau: Claude Tag phân loại yêu cầu, Devin thực hiện công việc, còn Poirot kéo dữ liệu nội bộ cần thiết. Một hiệu ứng phụ đáng chú ý: những người không phải kỹ sư cũng bắt đầu đóng góp code. Nhà thiết kế của công ty đã hợp nhất khoảng 50 thay đổi từ tháng 8, bao gồm cả những thay đổi xây dựng hệ thống thiết kế.

Cái giá phải trả

Không có gì miễn phí. Suốt mùa hè, phần lớn nỗ lực kỹ thuật đổ vào test và công cụ, còn số thay đổi hướng tới khách hàng mỗi kỹ sư chỉ dao động 17–30 mỗi tháng. Đến tháng 9, con số này nhảy lên 45, và tháng 10 dự kiến đạt 48.

Nút thắt mới: không phải code, mà là quyết định

Khi việc viết code nhanh hơn, một vấn đề khác lộ ra. Gondala đưa ra ví dụ: một tính năng từng mất 10 ngày, gồm 3 ngày lập kế hoạch, 6 ngày xây dựng và 1 ngày đánh giá. Nếu AI giúp xây dựng nhanh 3,5 lần nhưng lập kế hoạch và đánh giá giữ nguyên, tổng thời gian chỉ nhanh hơn 1,75 lần.

Lập kế hoạch và đánh giá giờ chiếm 70% thời gian, tăng từ 40%.

Đây chính là lý do nhiều tổ chức ứng dụng AI nhưng không thấy sản phẩm ra nhanh hơn tương xứng. Câu hỏi đặt ra: làm sao tổ chức đội ngũ để kỹ sư có thể xây dựng nhanh hơn mà không tạo ra nút thắt ở khâu quyết định?

Đẩy quyền sở hữu về phía kỹ sư

Câu trả lời của FurtherAI là trao nhiều quyền sở hữu hơn cho kỹ sư thay vì thêm tầng quản lý. Kỹ sư sẽ đảm nhận nhiều hơn việc lập kế hoạch, thực thi và đánh giá.

Cách họ định nghĩa cấp bậc kỹ thuật cũng thay đổi theo hướng "sở hữu đầu-cuối vấn đề":

• Kỹ sư junior: Xây dựng với tác nhân AI và biết khi nào nó sai.
• Kỹ sư senior: Tự lập kế hoạch và đánh giá công việc của mình.
• Kỹ sư staff: Nhận một vấn đề mơ hồ, cân nhắc đánh đổi và chịu trách nhiệm về con số chứng minh kết quả.

Kỹ sư cũng cần gần khách hàng hơn, từ hiểu vấn đề của khách đến phát hành giải pháp và theo dõi lỗi hồi quy trên môi trường production.

Làm việc nhóm với AI

Kỳ vọng mới với quản lý

Vai trò quản lý kỹ thuật cũng đổi thay:

1. Trực tiếp tham gia vào công việc. Quản lý cần hiểu đang xây gì, vì sao và liệu đó có phải giải pháp đúng. Gondala muốn quản lý dùng thử tính năng trên staging như người dùng thật, chứ không chỉ kiểm tra xem code đã được review chưa. Mục tiêu cuối cùng vẫn là đào tạo kỹ sư tự ra quyết định đúng.

2. Am hiểu sản phẩm hơn. Khi viết code rẻ đi, quyết định xây gì càng quan trọng. Quản lý kỹ thuật cần hiểu khách hàng, có quan điểm sản phẩm mạnh và thoải mái đưa ra quyết định không chỉ về kỹ thuật.

Bài học cho đội ngũ tại Việt Nam

Với các công ty công nghệ Việt Nam đang bắt đầu tích hợp AI vào quy trình phát triển, chia sẻ của FurtherAI mang lại vài gợi ý thực tế:

• Tối ưu cả chuỗi, không chỉ một mắt xích. Đầu tư vào test, CI và công cụ tự động quan trọng không kém việc cấp công cụ lập trình AI cho kỹ sư.
• Chuyển kiến thức ngầm thành quy tắc tự động. Những quy tắc nhỏ chạy trên mỗi commit giúp AI tự sửa sai và giảm gánh nặng review cho con người.
• Chuẩn bị cho nút thắt ở khâu quyết định. Khi code nhanh hơn, hãy tính trước cách phân quyền và ra quyết định sản phẩm để tránh ùn tắc.

Gondala thừa nhận đây là bài toán khó hơn nhiều so với việc tự động hóa code, test và review: "Tôi nghi ngờ đây sẽ là bài toán khó hơn cả việc tự động hóa khâu viết mã." Bài học của FurtherAI cho thấy một tổ chức thuần AI không chỉ là tổ chức dùng nhiều công cụ AI, mà là tổ chức được thiết kế lại để con người và tác nhân AI cùng ra quyết định.