AI phân bug — phần khó không nằm ở model

Case study từ Miro: 100 team, 42 năm năng suất mất mỗi năm vì bug gửi nhầm. Phần quyết định không phải model, mà là dữ liệu xung quanh nó.

Con số khiến CTO phải dừng lại

42 năm. Không phải thời gian tồn tại của công ty, mà là lượng năng suất mà Miro — nền tảng cộng tác trực tuyến phục vụ hơn 95 triệu người dùng — ước tính mất mỗi năm chỉ vì bug bị gửi nhầm team.

Với gần 100 team engineering, mỗi bug report đến đều đặt ra một câu hỏi phân loại: đây là việc của ai? Câu trả lời sai không chỉ làm chậm fix, nó tạo ra một chuỗi reassignment (chuyển ticket qua lại giữa các team) kéo dài vài ngày, đôi khi cả tuần. Developer nhận bug không phải của mình phải đọc, phân tích, rồi đẩy sang team khác — mỗi vòng lặp đó là context-switching (chuyển ngữ cảnh công việc) mà không ai tính vào sprint velocity.

Đây không phải bài toán hiếm. Bất kỳ tổ chức nào có hơn 5 team engineering đều gặp phiên bản thu nhỏ của vấn đề này.

Quyết định: không đặt cược vào model, đặt cược vào ngữ cảnh

Phản xạ đầu tiên của nhiều team khi nghe "dùng AI phân loại bug" là chọn model nào đủ thông minh. GPT-4? Claude? Cái mới nhất trên bảng xếp hạng?

Miro đi hướng khác. Họ hợp tác với AWS để xây BugManager — một pipeline tự động phân loại bug bằng Amazon Bedrock (dịch vụ managed AI của AWS, cho phép gọi nhiều foundation model qua API mà không cần tự host). Nhưng điểm quyết định không phải ở việc chọn model, mà ở việc bổ sung ngữ cảnh sản phẩm trước khi model nhìn thấy bug.

Hiểu nôm na: bug report thô giống như gửi một lá thư không có địa chỉ. Có nội dung, nhưng không đủ để bưu tá biết đưa cho ai. Việc Miro làm là gắn thêm thông tin sở hữu code, lịch sử team nào từng xử lý module liên quan, và metadata từ stack trace — biến lá thư thành bưu phẩm có mã bưu chính đầy đủ.

Đây là chỗ mà mình thấy nhiều team Việt Nam bỏ qua: phần móng của hệ thống phân loại là dữ liệu ngữ cảnh, không phải model. Bạn có thể thay model bất kỳ lúc nào, nhưng nếu không có lớp dữ liệu sở hữu code — ai own module nào, team nào phụ trách feature gì — thì model xịn đến mấy cũng phân sai.

Hệ quả — phần được kể và phần không

Con số Miro công bố: giảm 6 lần số lần chuyển ticket giữa các team, thời gian xử lý nhanh hơn 5 lần. Ấn tượng trên giấy.

Nhưng phần thú vị hơn nằm ở điều không được highlight: hệ thống này buộc Miro phải chuẩn hóa ownership map — bản đồ ai sở hữu phần code nào. Trước khi có BugManager, thông tin này nằm rải rác trong đầu tech lead, trong wiki cũ, trong tribal knowledge (kiến thức truyền miệng nội bộ mà không ai viết ra). Để AI phân loại được, họ phải viết ra, cập nhật, và duy trì ownership map như một hệ thống sống.

Giả sử team bạn 20 người, chia 4 squad, dùng Jira. Mỗi tuần có 30–50 bug mới. Nếu 30% bị assign nhầm, mỗi bug mất thêm 1–2 ngày chờ reassign — bạn đang đốt khoảng 2–3 ngày-người mỗi tuần chỉ cho việc "bug đi lạc". Xây một pipeline phân loại đơn giản không chỉ tiết kiệm thời gian, nó ép team phải trả lời câu hỏi mà lâu nay né tránh: ai thật sự own cái gì?

Cái bẫy khi copy kiến trúc của người khổng lồ

Mình từng thấy một team e-commerce ở TP.HCM đọc case study tương tự, rồi dựng ngay một pipeline phân loại bug bằng GPT-4 API. Kết quả tuần đầu: accuracy 40%. Tệ hơn cả assign ngẫu nhiên cho team đông nhất.

Vấn đề? Họ nhảy thẳng vào model mà bỏ qua hai bước nền:

1. Không có ownership map rõ ràng. Khi hỏi "team nào own module thanh toán?", ba người trả lời ba đáp án khác nhau.
2. Bug report quá ngắn. Template Jira cho phép tạo bug chỉ với tiêu đề và mô tả 1 dòng — model không có đủ tín hiệu để phân loại.

Dịch sang tiếng thợ xây: họ đang dựng tường trên nền đất chưa san. Bao nhiêu gạch xếp lên cũng nghiêng.

Sau khi quay lại làm hai việc cơ bản — chuẩn hóa template bug report (bắt buộc có stack trace, module liên quan, bước tái hiện) và tạo ownership matrix cập nhật hàng tháng — accuracy nhảy lên trên 75% mà không cần đổi model.

Áp dụng: 3 bước trong sprint tới

Nếu team bạn đang đau đầu với bug routing, đây là thứ có thể bắt tay vào ngay:

Bước 1 — Kiểm kê ownership. Mở spreadsheet, liệt kê mọi module và service, gán team owner. Chỗ nào không ai nhận — đánh dấu đỏ. Đó chính là vùng bug hay bị đẩy qua đẩy lại nhất.

Bước 2 — Chuẩn hóa input. Sửa template bug report trên Jira, Linear, hay GitHub Issues. Thêm field bắt buộc: affected module, stack trace snippet, severity estimate. Không có dữ liệu đầu vào chất lượng thì đừng mong model cho output tốt.

Bước 3 — Thử phân loại bán tự động. Dùng một LLM — có thể là API từ OpenAI hay Anthropic, hoặc self-host qua Ollama với model mã nguồn mở — để suggest team owner, nhưng giữ một người duyệt trước khi assign chính thức. Sau 2–4 tuần, đo accuracy rồi mới quyết định tự động hóa hoàn toàn hay chưa.

Lưu ý thực tế: với team dưới 5 squad, một script Python đơn giản cộng prompt template là đủ. Không cần dựng kiến trúc multi-layer như Miro với Amazon Bedrock trừ khi bạn có hàng chục team và hàng trăm bug mỗi tuần.

Điều thật sự đáng mang về

Case study từ Miro xác nhận một pattern mà mình thấy lặp đi lặp lại ở nhiều team: phần khó nhất của AI trong vận hành không phải chọn model — mà là ép tổ chức viết ra những thứ đang nằm trong đầu mọi người. Ownership map, taxonomy phân loại, template dữ liệu đầu vào — đây là phần giàn giáo mà không công nghệ nào thay thế được. Dựng giàn giáo chắc rồi, gắn model nào lên cũng chạy.

---

Bụi Wire — nghiện đọc release notes lúc 2 giờ sáng