Phòng họp hôm đó lạnh hơn bình thường, hoặc có thể do tôi tưởng tượng vậy vì đang chuẩn bị nói một điều mình biết sẽ không ai thích. Trên màn hình là slide tôi vẽ tay đêm hôm trước: một sơ đồ có gần 30 ô vuông, mỗi ô là một "agent" — agent đặt câu hỏi, agent viết PRD, agent review code, agent này agent kia, xoay tròn quanh một cái lõi ở giữa vẫn y nguyên như cũ: con người, làm việc, theo đúng quy trình SDLC đã có từ trước khi ai nghĩ tới AI.
Tôi hỏi ngược lại cả phòng: quy trình cũ đó, liệu còn đúng không?
Câu trả lời tôi nhận được không phải một câu trả lời. Nó là một câu chặn: "Dev không được quyền thay đổi quy trình."
Ba mươi ô vuông, một cái lõi không đổi
Hãy tưởng tượng một công trường xây nhà. Bản vẽ cũ được thiết kế cho một đội thợ hồ làm việc bằng tay — trộn vữa, xây gạch, tô tường, từng bước một, có thứ tự, có người giám sát đứng giữa cầm bản vẽ chỉ tay. Giờ có một cỗ máy mới xuất hiện: nó xây nhanh hơn thợ hồ hàng chục lần, không cần nghỉ trưa, không cần cà phê sáng.
Cách người ta phản ứng, ở công trường tôi từng đứng, là giữ nguyên cái giàn giáo cũ, giữ nguyên người giám sát đứng giữa, rồi thuê thêm 30 ông thợ phụ, mỗi ông chỉ làm đúng một việc tí xíu — một ông chuyên trộn vữa, một ông chuyên đưa gạch, một ông chuyên lau tay cho thợ chính. Nhìn vào thì hoành tráng, đông đúc, có vẻ "hiện đại hóa" ghê lắm. Nhưng bản vẽ thì không đổi. Người giám sát vẫn đứng giữa, vẫn ra lệnh từng bước như thể đang chỉ huy người, chứ không phải máy.
Tôi đề xuất một hướng khác: thay vì thuê thêm thợ phụ, hãy vẽ lại bản vẽ. Cho người giám sát một quyền mới — không còn là người cầm bay tô tường, mà là người đứng cách xa hơn, ra đề bài, kiểm tra outcome, còn việc xây thì để cỗ máy tự vận hành theo logic của nó. Tôi tham khảo BMAD Method, một framework làm đúng tinh thần đó, đang có sẵn ngoài kia. Không ai giải thích được vì sao nó không ổn. Chỉ là không ổn thôi.
Vậy là giữ nguyên giàn giáo cũ. Ba mươi ông thợ phụ ra đời.
Hai loại câu trả lời cho một đề xuất
Có hai cách để bác bỏ một ý kiến. Một là phản biện vào nội dung — chỉ ra logic sai ở đâu, dữ liệu thiếu chỗ nào. Hai là chặn ở tư cách — ai được nói, ai không. "Dev không được quyền thay đổi quy trình" thuộc loại thứ hai. Nó không nói bản vẽ tôi đưa ra sai ở điểm nào, nó chỉ nói tôi không phải người được cầm bút vẽ. Có kiểu brownfield khác tôi từng viết — ở đó vấn đề là chưa chịu hỏi trước khi đập; ở đây, tôi đã hỏi, đã đề xuất đàng hoàng, nhưng vẫn bị chặn không phải vì nội dung.
Sự khác biệt đó quan trọng, vì hai loại câu trả lời dẫn tới hai kết quả khác nhau. Bị phản biện đúng chỗ, mình có thể sửa bản vẽ, làm nó tốt hơn. Bị chặn ở tư cách, bản vẽ không được sửa — nó chỉ đơn giản là bị gác lại, chờ đến khi ai đó có đủ tư cách hơn tự vẽ lại y hệt.
Tôi tiếp tục chia sẻ góc nhìn đó ở những kênh không chính thức, và tự mình thử nghiệm riêng để kiểm chứng. Nhưng ở cấp quyết định, câu trả lời vẫn không đổi. Bản vẽ cũ được giữ, ba mươi ô vuông được build ra thật, và tôi chuyển sang một topic khác.
Một năm sau, đứng ngoài nhìn vào công trường cũ
Gần một năm sau, tôi nghe tin: họ build và release phiên bản 2.0 — dựa trên chính BMAD Method mà năm ngoái không ai giải thích được vì sao không ổn.
Tôi không thấy vui kiểu "tôi đã nói rồi mà". Thành thật thì cũng chẳng có gì để tự hào — tôi không đoán trước tương lai, tôi chỉ đơn giản là người may mắn đi qua khúc đường đó sớm hơn một chút. Ở thời điểm năm ngoái, với bối cảnh tổ chức lúc đó, ngay cả khi họ nghe tôi ngay từ đầu, chưa chắc đã thành. Có những con đường tổ chức bắt buộc phải tự đi qua mới hiểu ra, không ai kể lại mà thấm được. Cái khác biệt duy nhất là tôi có góc nhìn riêng sớm hơn — và khoảng cách giữa tôi với thị trường bên ngoài, dần dần, cũng được lấp đầy.
Nhưng đứng ngoài nhìn vào, tôi thấy một điểm nghẽn mới đang hình thành. Bản vẽ được vẽ lại rồi, cỗ máy được đưa vào rồi — nhưng cái công trường thì vẫn không dám thay đổi tổ chức của chính nó. Quy trình cũ vẫn còn nguyên: vẫn từng ấy cổng phê duyệt, từng ấy bước bàn giao, từng ấy chữ ký. AI-native SDLC, thay vì gỡ bỏ điểm nghẽn, lại trở thành một lớp struggle mới chồng lên lớp cũ — thêm việc, thêm token, chứ chưa chắc đã giải quyết được gì.
Khi Anthropic viết đúng điều tôi vừa nghĩ
Tình cờ, tôi đọc được một bài blog công khai của Anthropic, nói về đúng cái bế tắc này ở quy mô lớn hơn nhiều tổ chức khác. Ý chính là: tốc độ viết code bằng AI đã vọt lên nhanh chưa từng có, nhưng quy trình xung quanh đoạn code đó — các cổng phê duyệt, review, bàn giao — lại gần như đứng yên, kéo chân toàn bộ năng suất mà agentic coding lẽ ra phải mang lại.
Đọc xong, tôi không thấy bất ngờ. Tôi thấy được xác nhận. Cái mình từng nói trong phòng họp năm ngoái — SDLC cũ không thể giữ nguyên khi lõi vận hành đã đổi — hóa ra không phải chuyện riêng của một công trường nào. Nó là chuyện của cả ngành.
Bản vẽ đúng, nhưng công trường thì chưa chịu dỡ giàn giáo
Ba mươi ông thợ phụ, rồi tới BMAD Method, rồi tới điểm nghẽn mới — mỗi lần là một lớp học. Không phải vì tôi đúng ngay từ đầu mà công trường phải nghe theo. Mà vì công trường, giống như bất kỳ công trường nào khác, chỉ chịu dỡ giàn giáo cũ khi chính nó đứng dưới cỗ máy mới và tự thấy giàn giáo không còn chịu nổi sức nặng.
Tôi chỉ là người đứng cạnh, chỉ tay sớm hơn một năm.
