Team của bạn đang bắt đầu hoặc đã áp dụng vibe coding. Sau khi những cảm giác ban đầu về việc cải thiện tốc độ làm việc nhanh hơn rất nhiều qua đi, bạn bắt đầu nhận ra những tín hiệu đáng lo ngại: chất lượng sản phẩm đang đi xuống, technical debt đang có dấu hiệu mất kiểm soát, và hơn hết, team của bạn đang có những dấu hiệu kém thống nhất trong cách tiếp cận hoặc ứng dụng AI.
Những dấu hiệu này nói lên điều gì? Đó là đèn vàng cảnh báo rằng team của bạn đang vượt ngưỡng tốc độ áp dụng AI so với ngưỡng chuẩn hóa, hay định hình cách làm việc với AI.
Điều đáng nói là không ai trong team chủ động lựa chọn đánh đổi này. Không có buổi họp nào quyết định rằng “chúng ta sẽ hy sinh chất lượng để lấy tốc độ“. Nó đến từng ngày, qua từng lựa chọn nhỏ tưởng như vô hại: một người tự set permission mode thoải mái hơn để đỡ bị hỏi liên tục, một người tự viết rule riêng cho CLAUDE.md của mình vì chưa ai bàn chung, một PR được approve nhanh vì “AI viết chắc cũng ổn”. Từng lựa chọn đó hợp lý ở quy mô cá nhân. Nhưng khi gộp lại trên quy mô cả team, chúng tạo ra một cái hố mà team bạn đang đào cho chính mình rơi vào: tốc độ sinh code đã vượt xa tốc độ mà team có thể review, chuẩn hóa và chịu trách nhiệm theo kịp.
- Theo dữ liệu telemetry của Faros, ở mức độ dùng AI cao: PR tăng 51%, số bug tính trên mỗi developer tăng 54%, thời gian nằm chờ để được review tăng 156,6%, và 31% PR được merge mà hoàn toàn không qua review.
- Dữ liệu DORA 2025 (Google) cho thấy: mức độ áp dụng AI cao hơn có tương quan với throughput cao hơn, nhưng đồng thời cũng đi kèm với mức độ bất ổn trong phát triển sản phẩm cao hơn. Đây là một nghịch lý đáng chú ý: AI có thể giúp team phát triển sản phẩm nhanh hơn, nhưng cũng có thể làm tăng mức độ bất ổn nếu năng lực kiểm soát và nền tảng delivery không theo kịp.
- Nghiên cứu hành vi của JetBrains (ICSE 2026, theo dõi telemetry thật của 800 dev trong 2 năm): người dùng AI có số lần delete/undo tăng gấp ~13 lần (102 lần/tháng so với 7,6 lần/tháng ở người không dùng AI), tức là phải sửa đi sửa lại nhiều hơn hẳn. Nhưng khoảng một nửa số người được khảo sát báo cáo rằng hành vi làm việc của họ KHÔNG thay đổi, dù dữ liệu log cho thấy hoàn toàn ngược lại.
- Khảo sát SonarSource 2026 (~1.100 dev chuyên nghiệp): 96% nói không hoàn toàn tin vào code do AI viết, nhưng chỉ 48% luôn luôn verify trước khi commit, và 53% đồng ý rằng AI hay tạo ra code “trông đúng nhưng không đáng tin”.
- GitClear (phân tích 623 triệu thay đổi code, 2023–2026): duplication trong cùng 1 commit tăng 41%, code block trùng lặp tăng 81%, refactor giảm khoảng 70%, cấu trúc “che lỗi” (error-masking) tăng 47%. Một nghiên cứu GitClear khác, sớm hơn (211 triệu dòng code, 2020–2024), cũng ghi nhận mức tăng gấp đôi code churn trong giai đoạn đó (từ 3,3% lên 7,1%).
Đây không phải là vấn đề của một cá nhân thiếu cẩn trọng, và cũng không phải vấn đề sẽ tự hết khi mọi người “cẩn thận hơn”. Nó là vấn đề về thiết kế cách làm việc giữa team và AI, và giống như mọi vấn đề về hệ thống, nó không tự sửa bằng ý thức tự giác; nó chỉ sửa được bằng cách thay đổi lại chính khung mà team đang làm việc trong đó.
Có giải pháp nào cho Scrum team đang áp dụng vibe coding không?
Câu trả lời là có, bản thân Scrum được xây dựng trên chủ nghĩa kinh nghiệm, chính là thứ có thể giúp team liên tục điều chỉnh để tối ưu hoá việc áp dụng AI trong công việc, đó là làm Scrum với AI:
- Daily Scrum và AI: ngoài chính những chia sẻ cần thiết của Scrum team là làm sao để đạt được Sprint Goal vào cuối Sprint, thì Developer nên chia sẻ thêm những trải nghiệm, hay vấn đề, bài học mình đã học được khi làm việc với AI và đã update vào log thô (có tên, ngày, và nội dung cụ thể). Log sẽ được chia sẻ trong các session liên quan tại buổi Sprint Retrospective vào cuối mỗi Sprint.
- Sprint Retrospective và AI: Thay vì buổi Sprint Retrospective diễn ra như trước, Scrum team nhìn lại cách làm việc và cải tiến nó trong Sprint sau, thì bây giờ khi làm cùng với AI, các bạn sẽ có thêm một session để cả team cùng nhìn lại trải nghiệm làm việc cùng AI của mình trong Sprint vừa qua, và làm sao để làm cho trải nghiệm đó được tốt hơn. Lúc này các file log thô sẽ được gom lại, và chia sẻ, bàn luận xem rule nào, hay workflow nào nên được update để team và AI sẽ có những tiêu chuẩn làm việc tốt hơn trong Sprint sau, sau đó log thô sẽ được chuẩn hoá thành file rule mà AI tool đọc trước khi bắt đầu làm việc (CLAUDE.md, AGENTS.md, .cursorrules, hay copilot-instructions.md, tuỳ team đang dùng tool nào). Ví dụ: Nếu bạn dùng format “Hot Air Balloon”, lúc này sẽ có thêm cột “AI topic”. Trong AI topic này, team sẽ bàn về những điều đã cải thiện tốt, nên giữ, hoặc những gì nên thay đổi để cải tiến rule và workflow hiện tại khi làm việc cùng AI. Và dĩ nhiên, action item luôn phải được thực hiện bằng việc update ngay rule và workflow mới.
- DoD và AI: Đúng ra thì DoD nên là một phần được Scrum team xem xét và upgrade trong Sprint Retrospective, nhưng tôi sẽ tách nó ra thành một phần riêng. Lý do đơn giản, vì việc bạn chạy quá nhanh, nhưng lại không đủ khả năng để kiểm soát được tốc độ đó thì lúc này bạn phải có những quy tắc chất lượng hoặc quy trình chất lượng chặt chẽ hơn trước. Nếu không, tai nạn thường sẽ lớn hơn rất nhiều. Vậy khi Scrum team làm việc cùng AI, bạn nên quan tâm đến 2 điểm: Thứ nhất là đảm bảo rollback và phải có khả năng tắt/tách biệt những ảnh hưởng của code mới nếu có vấn đề trên production. Thứ 2 là phải xác định được quy trình SDLC rõ ràng, và có những chốt chặn là con người review, lúc này review không phải là task, mà là trách nhiệm mà mỗi developer phải có. Không có DoD nào đảm bảo 100% chất lượng, nhưng một DoD có thể tạo ra một cách làm việc có ý thức, giúp team của bạn tránh những rủi ro không đáng có.
- Sprint Planning và AI: nên bổ sung về những công việc nào có thể được AI thực hiện, những công việc nào phải được làm “cùng” với AI, và với Sprint sắp tới, Junior developer có nên dùng AI trong task của mình không? Và có nên có những tầng review khắt khe hơn không? Thậm chí quan trọng hơn là dành nhiều thời gian hơn trước để kết nối những công việc đã làm với giá trị của sản phẩm. Vì chưa chắc những gì bạn làm ra thực sự mang lại giá trị cho người dùng thực tế, phải không?
Lời khuyên cuối và một chia sẻ nhỏ
Có nhiều người hỏi tôi rằng liệu Scrum còn cần thiết nữa không? AI đã giúp việc phát triển sản phẩm trở nên “nhanh chóng và tiện lợi” hơn bao giờ hết. Tôi sẽ không trả lời thẳng vào câu hỏi này, vì bản thân Scrum và AI không phải là kẻ thù một mất một còn, nên phải chọn một trong hai. Tôi chỉ ra những điều có thể làm tốt hơn khi bạn có cả hai: Scrum và AI. Bản chất Scrum không thay đổi trong thời đại AI đang thay đổi cách bạn và team làm việc, Scrum sẽ không mất đi tầm quan trọng của nó, mà ngược lại Scrum sẽ trở nên cần thiết hơn bao giờ hết. Nhưng nó cũng đòi hỏi sự nghiêm túc hơn, lúc này mỗi sự lơ là của bạn sẽ trả giá đắt hơn, vì chiếc xe của bạn đang đi trên con đường cao tốc, và chỉ một sơ suất nhỏ cũng tạo ra rất nhiều ảnh hưởng.
Đèn vàng ở đầu bài không phải để bạn dừng lại. Cao tốc không có chỗ cho việc dừng giữa đường. Nó chỉ là dấu hiệu để bạn nhìn lại tay lái trước khi tăng thêm tốc độ: Daily Scrum để không bỏ lỡ tín hiệu sớm, Retro để tay lái đó được chỉnh lại đúng lúc, và DoD để nếu có sơ suất, bạn vẫn còn đường thoát trước khi nó trở thành tai nạn thật. Scrum và AI không làm bạn chạy chậm lại, chúng là thứ duy nhất cho phép bạn chạy nhanh mà không lao ra khỏi đường.
References:
- Faros — AI Engineering Report 2026: The Acceleration Whiplash (PDF gốc), hoặc bản tóm tắt Ten Takeaways trên blog Faros.
- DORA 2025 — dora.dev/dora-report-2025 (trang chính thức), hoặc bài tóm tắt của Google: How are developers using AI? Inside Google’s 2025 DORA report.
- JetBrains (ICSE 2026) — bài nghiên cứu “Evolving with AI: A Longitudinal Analysis of Developer Logs”: arxiv.org/html/2601.10258v2 (hoặc bản PDF tại arxiv.org/pdf/2601.10258), và trang ICSE 2026: conf.researchr.org.
- SonarSource — thông cáo báo chí “The Verification Gap”, hoặc báo cáo đầy đủ: State of Code Developer Survey report 2026 (PDF).
- GitClear — báo cáo 623 triệu thay đổi (2023–2026): The Maintainability Gap. Nghiên cứu cũ hơn về code churn (211 triệu dòng, 2020–2024): AI Assistant Code Quality 2025 Research.
