#1percentbetter

AI viết code nhanh, AI viết tests cũng nhanh – nhưng khi cả hai cùng đến từ một nguồn, coverage 100% vẫn có thể che giấu bug production. Đây không phải lỗi của AI. Đây là structural problem của vibe coding workflow: không có adversarial thinking, không có người hỏi "nhưng nếu... thì sao?" Vai trò QA không bị AI xóa bỏ – nó đang trở nên quan trọng hơn bao giờ hết. Tuần trước, tôi review một đợt regression sau khi team deploy feature mới. CI green. Test coverage 94%. Zero failing tests. Mọi thứ sạch đẹp trên dashboard. Hai giờ sau khi lên production – một user nhắn tin vào support: "Giỏ hàng của tôi bị mất khi tôi quay lại từ trang thanh toán." Tôi kéo code ra. Dev gen bằng Cursor, tests cũng gen bằng Cursor. Coverage report trông rất đẹp – unit tests cover từng function, integration tests cover các happy path chính. Chỉ có một thứ tests không cover: cái user journey cụ thể đó – tab back sau khi redirect sang payment gateway của bên thứ ba, state của cart bị reset vì AI không biết rằng cái flow đó tồn tại. AI không biết business context của bạn. AI không có ký ức về lần trước user complain gì. AI không đặt câu hỏi theo kiểu của một tester: "Nhưng nếu user làm cái này trước thì sao?" Và đó chính là vấn đề cốt lõi.

Vibe coding đang trở thành chuẩn mới. Nhưng khi AI viết code cho tất cả mọi người, thứ duy nhất còn phân biệt developer giỏi và developer bình thường chính là nền tảng kỹ thuật. Căn bản không lỗi thời – nó càng quý hơn khi công cụ làm thay tất cả phần ngọn. Năm đầu tiên đi làm, tôi không biết mình là frontend developer hay backend developer. Không phải vì tôi không được hỏi. Mà vì không ai hỏi. Không có job description kiểu đó. Không có team frontend riêng, backend riêng, QA riêng. Chỉ có tôi, một cái máy tính Dell cũ, và một danh sách công việc dài hơn cả ngày làm việc. Hôm nay code module đăng ký sinh viên. Ngày mai lao đến trường Cao đẳng – khách hàng của chúng tôi – để ngồi cùng phòng Đào tạo, hỏi họ muốn in bảng điểm theo định dạng nào. Tuần sau bê máy tính qua từng phòng ban để cài đặt, hướng dẫn trực tiếp. Rồi lại về, mở IDE, fix bug mà thầy Hiệu phó vừa báo sáng nay. Không phân role. Không có "đó là việc của team khác". Không có ticket system để tạo ticket rồi chờ. Chỉ có bài toán và người giải nó – là tôi. Hơn hai mươi năm sau, tôi đọc bài viết về vibe coding và thấy buồn cười. Buồn cười theo kiểu: "Ủa, vòng này không quen à?" Vibe coding – từ được Collins English Dictionary chọn là "Word of the Year 2025" – ngắn gọn là: dùng AI để generate code bằng cách mô tả yêu cầu bằng ngôn ngữ tự nhiên. Bạn viết prompt, AI viết code, bạn chạy thử và tinh chỉnh. Không cần nhớ cú pháp. Không cần tra Stack Overflow từng function. Nhanh hơn, gọn hơn, sexy hơn. Và đi kèm với đó, developer ngày nay đang trở thành người làm tất cả – một lần nữa. Không còn ranh giới rõ ràng giữa frontend dev và backend dev. Một người với AI trong tay có thể build cả một product từ đầu đến cuối. Tự viết code, tự test, tự review, tự phân tích yêu cầu, đôi khi còn kiêm luôn PM. Giống y chang ngày tôi mới ra trường. Chỉ khác là ngày đó không có AI – tôi phải tự học tất cả bằng cách làm thật, sai thật, sửa thật.

Developer ngày nay – đặc biệt trong kỷ nguyên vibe coding – phải kiêm BA. Không phải vì được thăng chức. Mà vì nếu không biết phân tích yêu cầu, viết user story, xác định acceptance criteria, bạn sẽ build nhanh nhưng build sai. Kỹ năng BA không phải của BA nữa – nó là kỹ năng sống còn của developer hiện đại. Hãy để tôi kể bạn nghe sprint đó. Ông dev của tôi – một anh senior rất giỏi, code sạch, tốc độ nhanh – sprint 3 tuần làm xong cái feature mà anh ấy gọi là "hoàn hảo". Đúng spec. Đúng deadline. Test pass 100%. Anh ấy demo với vẻ mặt rất tự hào. Khách hàng ngồi im lặng một lúc. Rồi nói: "Cảm ơn anh, nhưng... đây không phải thứ chúng tôi cần." Không phải lỗi của anh. Không phải khách hàng thay đổi ý kiến giữa chừng. Mà ngay từ đầu, cái yêu cầu ban đầu – "tôi muốn xem báo cáo doanh thu theo ngày" – đã bị hiểu sai hoàn toàn. Khách hàng muốn xem doanh thu thực thu, sau khi đã trừ refund và discount. Dev của tôi build báo cáo doanh thu gộp. Ba tuần. Sai ngay từ từ đầu. Tôi ngồi trong buổi retrospective hôm đó và tự hỏi: lỗi này từ đâu ra? Ticket viết "báo cáo doanh thu theo ngày". Anh dev đọc ticket, code đúng theo ticket. Ticket sai thì sao anh biết được? Đúng. Ticket sai. Nhưng ai viết ticket? Cậu BA của team – người lúc đó đang bận sprint review của team khác và "copy spec từ email khách hàng vào Jira cho nhanh". Email của khách hàng cũng mơ hồ. Không ai hỏi thêm. Không ai clarify. Tất cả cứ chạy về phía trước và nghĩ người kia đã hiểu. Tôi đã thấy kiểu tình huống này lặp lại trong 20 năm làm PM/BA. Tên gọi khác nhau. Ngôn ngữ lập trình khác nhau. Nhưng root cause giống nhau hoàn toàn: vấn đề không bao giờ là code – mà là khoảng trống trong giao tiếp yêu cầu.

LLM Wiki là pattern biến codebase thành "living knowledge base" – AI đọc một lần, nhớ mãi, kiến thức tích lũy theo thời gian. Khác với RAG truyền thống, LLM Wiki compound knowledge: mỗi lần hỏi đều thông minh hơn lần trước. Tôi nhớ lần đầu tiên tiếp cận một codebase e-commerce 5 năm tuổi. Hệ thống đang chạy ổn định, team cũ đã nghỉ gần hết, và tôi được giao nhiệm vụ thêm một tính năng tưởng đơn giản: hiển thị trạng thái tồn kho real-time trên trang sản phẩm. Ba ngày sau, tôi vẫn còn ngồi đọc code. Không phải vì code xấu. Mà vì không ai – kể cả những dev còn lại trong team – có thể giải thích được tại sao InventoryService lại gọi thẳng vào một endpoint của OrderService thay vì dùng shared database. Confluence có một trang wiki viết năm 2021 với nội dung "TODO: update this section." File README chỉ có hướng dẫn setup môi trường local. Đó là lần đầu tôi thực sự hiểu cái gọi là tribal knowledge – kiến thức nằm trong đầu người, không phải trong code.

Tháng 3/2026, Nhà Trắng ban hành National AI Policy Framework — văn bản đầu tiên xác lập tầm nhìn liên bang cho AI, kèm theo American AI Exports Program mở cửa từ tháng 4/2026. Với doanh nghiệp Việt muốn bán phần mềm sang US market, đây không phải chuyện của policy team — đây là chuyện của CTO và tech lead: data residency phải rõ, AI model outputs cần compliance review, và nếu sản phẩm chạm vào advanced computing thì EAR/ITAR là rủi ro thật.

Năm 2026, AI agents đang bùng nổ và nhiều người vội vã tuyên bố "prompt engineering đã chết". Sai hoàn toàn. Chain of Thought, flipping roles — những kỹ thuật cơ bản đó vẫn còn sống, chỉ là giờ chúng ta không chạy 1 luồng nữa, mà chạy song song 40 luồng cùng lúc. Bài này là câu chuyện về sự tiến hóa đó. Hôm rồi tôi ngồi cà phê với một ông bạn — tôi gọi anh là Khoa cho tiện — senior developer 6 năm, đang chuyển sang làm AI engineer ở một startup khá hot trong nước. Anh mở màn bằng một câu khiến tôi suýt đổ cà phê: "Anh ơi, prompt engineering giờ chết rồi. Giờ phải học AI agents mới là đúng hướng." Tôi nhìn anh, hỏi: "Chết theo nghĩa nào?" Anh giải thích: "Thì giờ người ta build hệ thống multi-agent rồi, AI tự lo với nhau, mình chỉ cần thiết kế workflow là xong. Ai còn ngồi viết prompt thủ công nữa?" Tôi im lặng một lúc, rồi hỏi ngược: "Thế mấy cái agent đó nó tự nhiên biết làm việc không? Hay vẫn cần ai đó chỉ cho nó cách nghĩ?" Anh Khoa dừng lại. Ừ nhỉ.

AI không giải phóng thời gian - nó mở rộng kỳ vọng. Bạn làm nhanh hơn, nhưng sẽ phải làm nhiều hơn, kiểm tra nhiều hơn, và học thêm liên tục để không bị bỏ lại. Nhưng cũng có cách để không bị AI "ăn thịt" mà vẫn tận dụng được nó. Ông bạn tôi - một PM khá giỏi, 8 năm kinh nghiệm - nhắn tin lúc 11 giờ đêm thứ Sáu. Nội dung: "Anh ơi, sao em dùng Copilot rồi mà còn bận hơn trước vậy?" Tôi cười, vì câu đó chính xác là điều tôi muốn nghe để viết bài này. Trước đó vài tháng, cả team ông bạn tôi được trang bị GitHub Copilot, Microsoft 365 Copilot, và một đống AI tool khác. Ban đầu ai cũng hào hứng. Code review nhanh hơn. Email draft xong trong 2 phút. Document có AI tóm tắt. Cuộc họp có transcript tự động. Hai tháng sau, ông ấy đang ngồi 11 giờ đêm thứ Sáu hoàn thiện nốt phần requirements mà AI vừa generate ra nhưng sai đủ kiểu cần phải sửa lại từ đầu. Chào mừng đến với "AI productivity paradox" - cái nghịch lý mà hàng triệu người đang trải qua nhưng ít ai nói thẳng ra.