Tình huống: dự án production, không phải demo
Tháng trước, team chúng tôi nhận một yêu cầu khá phổ biến: thêm tính năng AI Summarize và AI Gateway vào một JavaScript SDK đang chạy production cho hơn 200 doanh nghiệp. Công việc bao gồm tích hợp API, viết SDK adapter, viết test, viết example.
Nghe có vẻ đơn giản, nhưng đây là codebase 4 năm tuổi, có 6 nhánh song song từ 2021 đến giờ, mỗi nhánh lại có chút khác biệt. Đây cũng là loại dự án mà team BKGlobal đụng hàng ngày - codebase lâu năm, có người viết, có người review, có người maintain vài năm sau khi người viết đã chuyển team.
Trong dự án này, team đã chạy thử nghiệm với 3 mức độ khác nhau của AI coding tools, đo thời gian thực tế (không phải cảm tính), và so sánh với cách làm cũ. Bài viết này là phần tổng hợp chúng tôi muốn chia sẻ với cộng đồng.
Câu chuyện "10x" đến từ đâu
Nếu bạn đọc Twitter hay LinkedIn năm 2024-2025, hẳn đã thấy những dòng tweet kiểu này (chúng tôi dịch lại cho dễ đọc):
- Cursor giúp tôi ship feature trong 2 giờ thay vì 2 ngày.
- Copilot giúp tôi viết 80% code, tôi chỉ ngồi review.
- AI sẽ thay thế lập trình viên trong 5 năm tới.
Vấn đề là những con số đó đến từ hai nguồn:
- Demo project - mới từ đầu, một file, một feature, đo thời gian "từ 0 đến chạy được". Loại này AI làm rất tốt.
- Cảm tính người dùng - "tôi cảm thấy nhanh hơn", không đo thời gian thực, không tính thời gian review, debug, refactor sau đó.
Chúng tôi tò mò: trong một codebase production thực, có những nhánh merge phức tạp, có PR review, có test phải chạy lại nhiều lần, thì con số thật là bao nhiêu?
Thử nghiệm của team BKGlobal
Setup
Team JavaScript của chúng tôi có 5 người, làm việc với các mô hình AI sau thông qua IDE plugin:
- GitHub Copilot Chat trong WebStorm (cách dùng phổ biến nhất 2025-2026)
- Cursor IDE (môi trường AI toàn project)
Các mô hình: GPT Codex, GPT-5.2, Opus 4.5, Gemini 3.5. Công cụ được team tự chọn theo preference, không ép buộc.
Chúng tôi chạy 3 thử nghiệm trên codebase đang chạy:
Thử nghiệm 1: Mở rộng SDK production
Công việc: thêm AI Summarize (tóm tắt từ ~1000 chat messages) và AI Gateway (nhận diện text trong ảnh và sinh mô tả). Bao gồm API integration, SDK adaptation, viết test, viết example.
Dùng: GitHub Copilot Chat trong WebStorm.
Trong quá trình làm, team nhận ra một điều quan trọng: AI plugin truyền thống (Copilot Chat kiểu cũ) không thấy toàn bộ project. Developer vẫn phải tự chọn file, paste snippet vào prompt, giải thích các module tương tác ra sao, rồi mới nhận được code trả về.
Kết quả:
- Có AI: ~18 giờ
- Không có AI: ~24 giờ trở lên
- Tăng năng suất: 30-35%
Nhưng khoan, đây mới chỉ là phần "viết code". Chưa tính review, test lại, sửa edge case.
Thử nghiệm 2: Merge các nhánh cũ từ 2021
Đây là công việc nhức đầu nhất: 6 nhánh code chạy song song từ 2021 đến nay, mỗi nhánh có implementation hơi khác nhau cho cùng một logic, có những chỗ trùng, có những chỗ phân kỳ tinh tế.
Bình thường, merge loại này mất cả tuần, chủ yếu vì phải đọc rất nhiều code lạ và so sánh cách tiếp cận.
Dùng Copilot Chat, team feed từng đoạn code từ các nhánh vào, hỏi: "đoạn này với đoạn kia khác nhau chỗ nào, tại sao lại có sự khác biệt này, hãy giải thích logic của đoạn code lạ này".
Kết quả:
- Có AI: ~1.5 ngày
- Không có AI: ~1 tuần
- Tăng năng suất: nhiều lần, nhưng chỉ trong tác vụ đọc hiểu và so sánh code
Điểm mấu chốt: phần lớn thời gian tiết kiệm không phải vì AI viết code nhanh hơn, mà vì AI giúp đọc và hiểu lượng code lớn nhanh hơn. Đây là tác vụ mà con người làm rất chậm và mệt mỏi, AI xử lý nhanh và đỡ mệt hơn nhiều.
Thử nghiệm 3: Tích hợp SDK vào product (với Cursor)
Hai developer làm song song, mỗi người dùng một model AI khác nhau (GPT-5.2 Codex và Opus 4.5). Tạo một môi trường Redux hoàn chỉnh, kết nối Figma, generate layout, tích hợp business logic.
Kết quả ban đầu:
- Có Cursor: ~20 giờ
- Không có Cursor: ~40 giờ
- Tăng năng suất: 2x
Nghe rất ấn tượng. Nhưng thử nghiệm này cũng phơi bày một vấn đề mà hai thử nghiệm trước không lộ ra.
Vấn đề ẩn: code chạy được, nhưng không ai muốn sửa
Trong quá trình review code từ Thử nghiệm 3, một senior dev trong team phát hiện một điểm kỳ lạ.
Một image identifier đã tồn tại sẵn trong object được truyền qua hệ thống. Về mặt logic, code chỉ cần dùng lại ID đó là xong. Nhưng code AI generate lại đi đường vòng: fetch ID, download blob liên quan, tạo file mới từ blob đó, upload file mới lên server, rồi trả về ID mới.
Từ bên ngoài nhìn vào, mọi thứ chạy đúng. Nhưng bên trong, hệ thống đang làm gấp nhiều lần công việc cần thiết. Mỗi lần logic chạy, dữ liệu bị nhân đôi, thêm network call, tăng tải server lặng lẽ.
Chúng tôi chỉ phát hiện vì có người mở code ra đọc kỹ.
Và đây không phải trường hợp cá biệt. Sau đó team bắt đầu để ý, và nhận ra đây là pattern khá phổ biến với code AI generate: code chạy được, nhưng logic đằng sau không khớp với kiến trúc của hệ thống mà nó đang được thêm vào. Trong các shared component như SDK, những kém hiệu quả này có thể lan ra mọi product phụ thuộc vào nó.
Nghiên cứu độc lập nói gì
Trong khi team chạy thử nghiệm nội bộ, chúng tôi cũng xem lại các nghiên cứu độc lập để đối chiếu:
Năng suất và chất lượng code
GitClear (2025): AI tools tăng tốc độ phát triển 20-55%, nhưng lượng "sustainable code" (code ở lại codebase mà không bị sửa lại) chỉ tăng khoảng 10%. Developer viết code nhanh hơn, nhưng một phần đáng kể vẫn phải revise hoặc refactor sau đó.
METR (tháng 7 năm 2025) - một nghiên cứu ngẫu nhiên có đối chứng: developer có kinh nghiệm làm việc trên project riêng của họ thực ra tốn thêm 19% thời gian khi dùng AI tools, dù họ chủ quan cảm thấy nhanh hơn 20%. Đây là phát hiện rất đáng suy ngẫm: cảm giác nhanh và thực tế nhanh là hai thứ khác nhau.
Chi phí review code AI
Sonar State of AI in Code (tháng 1 năm 2026): 95% developer dành thời gian đáng kể để kiểm tra code AI generate. 38% trong số họ cho rằng code AI khó review hơn code người viết. Developer đọc và verify code chậm hơn nhiều so với tốc độ AI generate, tạo ra một trần năng suất tự nhiên.
Giới hạn kiến trúc của code AI
Ox Security "Army of Juniors" (tháng 10 năm 2025) mô tả code AI generate là "chạy chức năng tốt nhưng thiếu tư duy kiến trúc một cách có hệ thống" - tức là code chạy được, test pass, nhưng thiết kế bên trong không tối ưu. Điều này giải thích vì sao code chạy được nhưng tích lũy vấn đề ẩn, đặc biệt trong các shared component.
Technical debt
HFS Research + Unqork (tháng 11 năm 2025) khảo sát 123 tổ chức Global 2000: 84% kỳ vọng AI giảm chi phí, nhưng 43% thừa nhận AI tạo technical debt mới. Quan điểm về tác động dài hạn chia gần đều: 55% kỳ vọng giảm debt, 45% kỳ vọng tăng.
Forrester dự đoán đến 2026, 75% tech leader sẽ đối mặt với technical debt ở mức trung bình đến nghiêm trọng, với AI code generation thiếu kỷ luật engineering là yếu tố chính.
Tác động đến delivery stability
Google DORA Report 2024 tìm ra một tương quan quan trọng: tăng 25% mức sử dụng AI dẫn đến giảm 7.2% delivery stability. Có tăng 2.1% năng suất và 2.6% job satisfaction, nhưng cái giá là giảm 1.5% throughput và 7.2% stability. Báo cáo DORA 2025 xác nhận các phát hiện này.
Vì sao con số thật là 25-40%
Nhìn lại cả thử nghiệm nội bộ và nghiên cứu độc lập, chúng tôi thấy cùng một pattern:
AI tools rõ ràng tăng tốc một số phần của development: giảm boilerplate, điều hướng trong codebase lớn, scaffolding cho tính năng mới, tăng tốc đường đi đến một implementation chạy được.
Nhưng những lợi ích đó đi kèm với một quán tính ngược chiều. Code vẫn cần được hiểu, review, tích hợp vào hệ thống sẵn có. Developer suy luận về code chậm hơn nhiều so với tốc độ AI generate.
Không có review đúng mức, team tích lũy thứ chúng tôi gọi là "AI legacy code" - code chạy được nhưng không ai trong team thực sự hiểu. Theo thời gian, việc sửa lại code đó trở nên khó hơn việc generate lại từ đầu. Nhưng generate lại từ đầu nghĩa là lãng phí thời gian và tài nguyên cho những vấn đề đã từng được giải quyết. Trong môi trường high-debt, tổn thất có thể chiếm 30-40% change budget và 10-20% chi phí vận hành hệ thống.
Tình trạng này có thể phát triển chỉ trong vài tháng sau khi áp dụng AI code mà không có sự tham gia đầy đủ của developer.
Đó là lý do vì sao những tuyên bố "10x productivity" hiếm khi giữ được trong môi trường engineering thực. Trong thực tế, mức tăng ổn định trong khoảng 25-40% - đủ ý nghĩa để quan trọng, nhưng không lớn đến mức engineering judgment trở nên thừa thãi.
Cách team BKGlobal đã điều chỉnh
Từ những phát hiện trên, team chúng tôi đã thay đổi một vài thứ trong quy trình. Trước tiên là một script C# nhỏ mà team dùng để đo lead time thật của mỗi task có chứa code AI:
// AICodeMetricsCollector - chạy trong CI pipeline sau mỗi PR merge
// Đo: tổng thời gian task, số vòng review, có dùng AI hay không
public sealed record PullRequestMetric(
string PrId,
DateTimeOffset CreatedAt,
DateTimeOffset MergedAt,
int ReviewRounds,
bool HasAiAssistedCode,
int FilesChanged,
int SustainableLinesAfter30Days
);
public sealed record TeamInsight(
string Label,
double Value,
string Unit
);
public static class AiProductivityAnalyzer
{
// Tính lead time (giờ) và correlation với sustainable code ratio
public static IReadOnlyList<TeamInsight> Analyze(
IEnumerable<PullRequestMetric> metrics,
TimeSpan reviewWindow)
{
var aiTasks = metrics.Where(m => m.HasAiAssistedCode).ToList();
var manualTasks = metrics.Where(m => !m.HasAiAssistedCode).ToList();
if (!aiTasks.Any() || !manualTasks.Any())
return Array.Empty<TeamInsight>();
var aiAvg = aiTasks
.Select(m => (m.MergedAt - m.CreatedAt).TotalHours)
.Average();
var manualAvg = manualTasks
.Select(m => (m.MergedAt - m.CreatedAt).TotalHours)
.Average();
var sustainableRatio = aiTasks
.Average(m => m.SustainableLinesAfter30Days / (double)Math.Max(1, m.FilesChanged));
return new[]
{
new TeamInsight(
Label: "LeadTimeReduction",
Value: (manualAvg - aiAvg) / manualAvg,
Unit: "percent"),
new TeamInsight(
Label: "AiSustainableCodeRatio",
Value: sustainableRatio,
Unit: "ratio")
};
}
}
// Một insight team rút ra: nếu AiSustainableCodeRatio < 0.4
// thì AI đang được dùng quá tay cho các task phức tạp.Script trên chỉ là một phần của quy trình. Áp dụng nó, team đã rút ra 5 điều chỉnh sau:
1. AI làm việc khám phá và viết nháp, người quyết định kiến trúc
AI rất giỏi ở giai đoạn "viết code lần đầu để xem nó trông như thế nào". Nhưng quyết định về kiến trúc, abstraction, cách một tính năng mới tích hợp vào codebase hiện tại - những thứ đó vẫn phải do người nắm codebase quyết.
Trong quy trình review, team chúng tôi thêm một câu hỏi bắt buộc cho mỗi PR có code AI: "Code này tận dụng được gì từ codebase sẵn có chưa, hay nó đang đi vòng?". Câu hỏi này phát hiện ra khá nhiều vấn đề giống Thử nghiệm 3.
2. Tách riêng "thời gian viết code" và "thời gian review"
Khi đánh giá năng suất, team không đếm "số dòng code" hay "số commit". Thay vào đó, đếm thời gian từ lúc bắt đầu task đến lúc PR được merge, kèm theo bao nhiêu vòng review. Con số này cho thấy tác động thật của AI lên delivery cycle.
3. Cấm AI generate trong các phần security-sensitive
Những đoạn code liên quan đến authentication, authorization, xử lý dữ liệu nhạy cảm - team chúng tôi viết thủ công và review kỹ. AI có thể gợi ý pattern, nhưng implementation chính phải do người viết để đảm bảo không có edge case bị bỏ sót.
4. Track "sustainable code ratio"
Mỗi tháng, team xem lại bao nhiêu code viết ra được giữ lại nguyên vẹn sau một tháng, bao nhiêu bị sửa hoặc refactor. Nếu tỷ lệ sustainable code giảm mạnh, đó là dấu hiệu AI đang được dùng quá tay.
5. Chia sẻ pattern tốt trong team
Mỗi khi tìm ra một pattern hay khi dùng AI (cách viết prompt hiệu quả, cách setup context đúng, cách review nhanh hơn), team ghi lại vào internal wiki. Đây là cách chúng tôi nhân rộng kinh nghiệm thay vì mỗi người tự khám phá lại.
Kết luận
AI coding tools hữu ích nhất khi được xem như trợ lý, không phải sự thay thế cho engineering judgment.
Chúng xuất sắc ở việc phân tích và so sánh lượng code lớn - tác vụ mà con người tốn nhiều thời gian, AI xử lý rất nhanh. Chúng giảm ma sát trong phát triển hàng ngày và có thể tăng tốc có ý nghĩa thời gian đến lúc có code chạy được.
Đồng thời, các tác vụ đòi hỏi hiểu sâu business logic và tối ưu kiến trúc thường được AI giải theo cách chưa tối ưu. Code kết quả chạy được nhưng dư thừa. Hệ thống vận hành đúng trên bề mặt, nhưng những vấn đề ẩn liên quan đến performance, tài nguyên, và khả năng bảo trì có thể hình thành bên trong.
Quyết định kiến trúc, kiểm soát chất lượng, trách nhiệm với kết quả phải ở lại với team. Với kỷ luật đó, AI tools mang lại một cú hích năng suất thật, có thể đo được, và bền vững.
Nếu bạn đang đánh giá nên áp dụng AI coding tools vào team của mình ở mức độ nào, bài học của chúng tôi là: đừng tin con số 10x, cũng đừng bỏ qua 25-40%. Con số thật nằm ở đó, và quan trọng hơn - nó đi kèm với những rủi ro mà bạn cần quy trình để kiểm soát.
Bạn có kinh nghiệm nào với AI coding tools muốn chia sẻ? Team BKGlobal đang tổng hợp các case study từ cộng đồng developer Việt Nam để viết tiếp phần 2 của bài này. Để lại comment hoặc liên hệ qua trang BKGlobal Tech.
Bài liên quan trên tech.bkglobal.vn:
- Cloudflare Pay-Per-Crawl: thay đổi ảnh hưởng đến AI developer thế nào
- OpenAI giới hạn rollout GPT-5.6: developer cần biết gì
- Roadmap kỹ năng senior khi có AI: vẫn giá trị, nhưng khác đi
Son Do - BKGlobal Tech Team
#BKGlobal #ban-tin-cong-nghe #ai-coding-tools #dotnet #senior-dev
Research document (citation source reference)
(no reference document available)
