Huỳnh Kim Trí
30/08/2026
Áp Lực Kỷ Nguyên AI: Khi AI Giúp Viết Code Nhanh Hơn 5 Lần, Tại Sao Dev Lại Mệt Hơn 10 Lần?
Áp Lực Kỷ Nguyên AI: Khi Viết Code Nhanh Gấp 5 Lần Lại Khiến Dev Mệt Hơn Gấp 10Buổi họp Retrospective chiều thứ sáu của Project diễn ra trong một sự tĩnh lặng đáng sợ, không Leader nào lên tiếng, cả buổi chỉ là những câu hỏi tại sao của Director. Trên màn hình Dashboard tracking, biểu đồ burndown chart đi ngang một cách rệu rã, có line còn đi xuống như cổ phiếu. Cạnh bên là báo cáo chi phí: hệ thống AI Agent của dự án vừa đốt hàng chục ngàn USD tuần qua. Tiến độ thì vẫn trễ thảm hại, một loại follow-up tasks được define với deadline sát nút để giải cứu. Đứng ở góc độ tư duy Project Management khi nhìn vào quy trình vận hành, tôi nhận ra team mình vừa ăn một "cú lừa" kinh điển của SDLC 2.0: Đặt cược tất cả vào sự "quy củ" của AI, để rồi bị chính nó vắt kiệt sức.Bi kịch bắt đầu ngay từ khâu design. Dự án của chúng tôi vận hành với một tư duy thoạt nghe rất bài bản: Tuyệt đối không dùng AI tự phát. Mọi tác vụ từ generate tài liệu design đến gen code đều bắt buộc sử dụng các bộ prompt do dự án define sẵn, với đầy đủ context knowledge, đầy đủ skills. Kỳ vọng của cấp quản lý là gom toàn bộ sức mạnh của AI về một mối (centralize), đảm bảo tính nhất quán (consistency) và đưa AI vào một process chuẩn mực, tương lai xa hơn có thể apply cho toàn bộ project còn lại.Và, tuân thủ tuyệt đối quy trình, bạn Junior dùng bộ prompt đã được "chuẩn hóa" ném file requirement của BA cung cấp vào con Agent. Một bản design document trông cực kỳ nguy hiểm, trình bày rất đỉnh, ngập tràn technical keyword, với cách trình bày nặc mùi "AI" lập tức ra lò. Ông anh Senior bận rộn cũng làm đúng process, lấy bộ prompt dành riêng cho reviewer để AI tự động peer-review/upper-review. Kết quả review thật tốt, agent xuất ra một bản checklist trông cũng không khác gì các chuyên gia, với đầy đủ note, item, reference đủ cả, và câu chốt verdict bên dưới PASSED. Tuyệt vời không còn gì bằng, cả hai gật gù chốt phương án vì cỗ máy "chính ngạch" của dự án phán rằng mọi thứ hoàn hảo. MR được tạo, các ticket JIRA được resolve một cách nhanh chóng với đầy đủ evidence được capture một cách chuẩn chỉnh, nice!Cho đến khi release lên môi trường QA, luồng data ghi xuống database lỗi một cách ngớ ngẫn, exception throw ra với msg chả hiểu là gì. Lập tức lôi requirement gốc ra audit, chúng tôi mới tá hỏa: dù chạy bằng prompt chuẩn, con AI viết design vẫn tự động "lược dịch" mất hai business rule quan trọng nhất, và con AI làm nhiệm vụ review cũng ngoan ngoãn bỏ qua luôn. Hoảng loạn, team Solution nhảy vào cứu net. Nhưng thay vì rà soát source code bằng mắt, họ lại bị cuốn vào guồng quay cũ: dùng một loạt prompt "siêu cấp vip pro" khác được gắn mác bởi các SA hàng đầu để AI tự đi audit lại đống code và tài liệu kia. Một vòng lặp "máy chấm điểm máy" vô tận, còn con người thì đứng ngoài rìa, mù tịt về chính kiến trúc sản phẩm của mình.Chuỗi ngày đau khổ nhất rơi vào đội QA. Các bạn dev dùng prompt dự án sinh ra test matrix, gen JUnit test script ầm ầm. Code xanh lè, report coverage luôn đạt ngưỡng 99%~100% nhưng case thì rỗng tuếch, toàn happy case, summary data nhưng lại không có testcase fan-out. Đội function tester thì khốn khổ với con AI Agent trung tâm. Mỗi ngày, Agent này đốt hàng trăm USD tiền token, output luôn tuân thủ đúng định dạng Markdown như đã được define. Nhưng bất kì ai làm testing đều biết, quản lý hàng ngàn testcase bằng Markdown thay vì Excel thuần túy là một cực hình "vô nhân đạo". Không thể filter, không thể tracking, sai context, format gãy vụn, muốn xem tổng quát cũng chả xem được mà phải scroll lên, scroll xuống.Tester phải hì hục đi copy-paste và sửa tay từng dòng. Hệ lụy kéo theo là sự đứt gãy về KPI. Không tìm ra bug vì testcase chuẩn AI đẻ ra quá hời hợt, không đạt chỉ tiêu số bug trên KLOC. Cuối tháng, team phải vò đầu bứt tai viết giải trình: Tại sao team không dùng con Agent đắt đỏ của dự án mà lén lút tự viết cả trăm cái prompt nhỏ lẻ bên ngoài để vá víu output? Project được AI estimate effort rất đẹp, timeline cực kỳ tối ưu, nhưng công sức đi dọn dẹp "bãi rác" output do AI xả ra đã khiến effort thực tế đội lên gấp 10 lần.Từ câu chuyện đẫm máu trên, câu hỏi đặt ra là: Tại sao có process chuẩn, có AI mạnh nhiều tiền, chúng ta lại càng ngày càng kiệt sức hơn?Sự Sụp Đổ Của "Niềm Tin Quy Trình"Việc centralize các prompt và chuẩn hóa AI Agent là bước đi đúng về mặt quản trị. Nhưng sai lầm chí mạng là chúng ta lầm tưởng rằng: Prompt chuẩn sẽ cho ra kết quả đúng tuyệt đối. Sự thật là, tính consistency của máy móc đôi khi chỉ là sự lặp lại một cách kiên định những sai lầm ngớ ngẩn. Giao phó toàn bộ niềm tin vào một "AI process" khiến con người đánh mất đi khả năng hoài nghi và phản biện.Nghịch Lý Năng Suất Và "Bẫy" Kỳ VọngTrong kinh tế học có một khái niệm gọi là Nghịch lý Jevons, hình dung khi bóng đèn trở nên tiết kiệm điện hơn, con người không tắt bớt đi mà thay vào đó thắp sáng nhiều khu vực hơn và bật đèn lâu hơn. Áp dụng vào ngành Software Engineering: Công nghệ càng giúp tiết kiệm tài nguyên, nhu cầu sử dụng tài nguyên đó càng bùng nổ. Khi AI giúp hoàn thành một tính năng trong 1 ngày thay vì 5 ngày, Product Owner sẽ ném thêm 4 tính năng mới vào Sprint với thời hạn ngắn hơn. Thời gian tiết kiệm được không biến thành thời gian rảnh, nó bị lấp đầy bởi những áp lực mới.Sự Dịch Chuyển Sang "Năng Lượng Thẩm Định"Viết code truyền thống tốn sức lực cho việc tư duy logic và gõ phím. Nhưng làm việc với AI, và cho dù ngay cả với một AI đã cấu hình "chuẩn", lại bào mòn Năng lượng thẩm định (Appraisal Energy) của bạn để đánh giá, chọn lọc và ra quyết định. Việc liên tục soi lỗi các security leaks, performance, các vi phạm tiêu chuẩn dự án, đọc hiểu logic do AI sinh ra, rà soát các "hallucinations" ẩn sâu trong context khổng lồ thực chất gây căng thẳng thần kinh hơn nhiều so với tự tay viết. AI không làm bạn rảnh hơn, nó ép bạn từ vai trò "Người xây dựng" sang vai trò "Người dọn rác và kiểm duyệt".Chính quá trình thẩm định liên tục này tạo ra một phản ứng ngược, khiến não bị quá tải nhận thức rất nhanh, đó lý do vì sao dùng AI tạo code đôi khi còn mệt hơn tự viết. Khủng Hoảng "Quá Tải Quyết Định" (Decision Fatigue)Khi tốc độ generate code và tài liệu tăng lên một cách ào ào như thác đổ, mật độ decision points chạm ngưỡng báo động. Sửa đoạn code này hay bắt AI viết lại? Logic này chạy đúng trên môi trường UAT nhưng tạch trên Staging thì sao? File Markdown này copy ra Excel thủ công hay viết script convert? Package này AI suggest có bị deprecated hay dính lỗ hổng bảo mật không?... Chỉ trong một khoảng thời gian ngắn, mật độ ra quyết định quá dày đặc khiến não bộ kiệt quệ ngay từ giữa ngày làm việc dù bề ngoài trông bạn "chỉ ngồi prompt và copy-paste" chứ có làm gì nặng nhọc đâu. Rất dễ bắt gặp cảnh mặc dù sáng ra đã làm một ly coffee đậm đà đầy năng lượng, nhưng tới giờ cơm trưa lại chả buồn ăn.Tốc Độ Mới Trở Thành "Baseline" MớiKhoảng 2 năm trước thôi, việc fix một bug phức tạp tốn cả ngày làm việc (7h-8h đồng hồ) là điều hoàn toàn chấp nhận được. Ngày hôm nay, nếu bạn mất cả ngày cho bug đó, câu hỏi đầu tiên bạn nhận được sẽ là: "Cái này có hỏi AI chưa? Đã quăng log cho AI phân tích chưa mà lâu thế?"AI thật sự đã nâng mức kỳ vọng tối thiểu (Baseline) của toàn bộ ngành công nghiệp lên một tầm cao mới. Cái tốc độ mà trước đây chúng ta được cho là "xuất sắc" thì nay chỉ còn là "mức trung bình đạt chuẩn". Hệ quả dễ dàng nhìn thấy nhất trong những buổi review performance, ông Dev sẽ không còn được thưởng vì làm nhanh, mà bị sẽ đánh giá không tốt nếu làm chậm. Do đó, bạn không thể đi chậm lại, vì cả hệ sinh thái xung quanh đều đang tăng tốc một cách đáng sợ.Sống Sót Thế Nào Trong Kỷ Nguyên SDLC 2.0?Để không bị đống "code siêu tốc" đè bẹp, quy trình thôi là chưa đủ. Chúng ta buộc phải thay đổi vị thế:Tập trung vào Domain Knowledge & Architecture: AI rất giỏi syntax nhưng cực kỳ ngây thơ về business rule. Năng lực sống còn bây giờ là System Thinking, phải hiểu sâu bức tranh tổng thể để biết AI đang lược bỏ sai logic ở điểm nào.Quy trình chuẩn hóa phải đi kèm Verification độc lập: Centralize prompt là tốt, nhưng đừng dùng mắt người để audit hàng triệu dòng code do AI sinh ra. Hãy nên xây dựng một luồng Integration Test độc lập để kiểm soát output của cỗ máy generate kia, tạo ra hàng rào tự động hóa trước khi con người nhúng tay vào rà soát bước cuối.Đo lường bằng Cycle Time, không phải Code Gen Time: Hãy quản trị lại Kỳ vọng (Expectation Management), đừng bao giờ cam kết deadline dựa trên "tốc độ AI generate code". Chục ngàn dòng code sinh ra trong 5 phút theo đúng chuẩn dự án là vô nghĩa nếu mất 1 tuần để tester sửa format và 3 ngày để debug. Hãy cam kết dựa trên Cycle Time ngay từ lúc chốt requirement đến khi test và deploy một cách an toàn.Đơn giản là AI giúp chúng ta đi nhanh hơn, nhưng tuyệt đối không thể nghĩ thay chúng ta. Giao phó toàn bộ tư duy cho các bộ prompt, dù chúng có được thiết kế hoàn hảo và quy củ đến đâu, đó chính là cách nhanh nhất để đánh sập một hệ thống từ sâu bên trong.Và tôi cũng biết rằng ngoài kia, đang có rất nhiều khóa học, nhiều video, nhiều buổi sharing hô hào "Dùng AI để làm việc thay bạn", nhưng thực tế cuộc chơi khốc liệt hơn nhiều. Nếu bạn là một Junior Dev hay một Tester vẫn còn đang bối rối, chưa biết phải định vị mình ở đâu khi AI đang xâm chiếm mọi ngóc ngách của dự án, thì đây là lời khuyên chân thành từ những "vết thương" dự án thực tế:Với anh em Developer: Tốc độ gõ phím không còn là lợi thế cạnh tranh. Đừng cố chạy đua việc sinh ra hàng ngàn dòng code với máy móc. Thay vào đó, hãy đầu tư vào thứ mà AI chưa thể nắm bắt trọn vẹn: Context và System Design. Hãy hiểu sâu Business Logic, luồng dữ liệu, và cách các component tương tác với nhau. Khi bạn nắm vững kiến trúc, AI sẽ là một anh thợ xây siêu tốc dưới quyền bạn. Còn nếu bạn chỉ mãi tập trung vào bề nổi, cưỡi ngựa xem hoa, bạn sẽ sớm trở thành người đi dọn rác cho chính anh thợ xây đó.Với anh em Tester/QA: Sự bùng nổ của AI không phải là dấu chấm hết cho nghề Tester, trái lại, phải nói rằng thời thế của các bạn đang tới, thật đấy. Khi code được đẻ ra ào ào với "tốc độ ánh sáng", số lượng bug tiềm ẩn và những "ảo giác logic" sẽ tăng lên theo cấp số nhân (tất nhiên rồi vì muốn không có bug nào thì chỉ có cách là đừng code dòng nào cả). Từ đây vai trò "người chốt chặn" của QA chưa bao giờ quan trọng đến thế. Đừng tự biến mình thành "thợ sửa format" cho những file testcase vô hồn của AI. Hãy nâng cấp năng lực của mình thành Quality Engineer, hãy dùng tư duy phản biện để bẻ gãy những logic hoàn hảo giả tạo, nịnh bợ của máy móc, đào sâu vào các edge cases, và bắt hệ thống (cũng như mấy con AI) phải chứng minh tính đúng đắn của nó cho mình.Có thể nghĩ về bản chất rằng, AI nó là một chiếc loa phóng thanh. Nó khuếch đại năng lực của bạn từ Junior lên Middle, từ Middle lên Senior, nhưng đồng thời cũng khuếch đại cả những sai lầm và sự hời hợt trong quy trình làm việc. Đừng sợ AI cướp task của bạn, hãy sợ việc chính bản thân mình đánh mất đi năng lực cốt lõi nhất của một SWE: Khả năng hoài nghi và tư duy giải quyết vấn đề độc lập. Hãy làm chủ AI, đừng để AI "chơi" và vắt kiệt mình!Anh em đang gặp khó khăn gì nhất khi làm việc cùng AI? Chia sẻ dưới comment để chúng ta cùng tìm hướng giải quyết nhé.
