Bài viết này được lấy cảm hứng từ tác phẩm của Hoang Nguyen.
Ảo tưởng về tốc độ trong kỷ nguyên Prompt
Trong hai năm qua, ngành công nghiệp phần mềm đã bị ám ảnh bởi khái niệm "Prompt." Chúng ta được bảo rằng nếu tìm ra đúng câu lệnh, đúng trình tự token, AI sẽ làm tất cả mọi thứ. Vì vậy chúng ta dành thời gian để crafting prompt, xây dựng thư viện, phân loại chúng. Chúng ta trở nên nhanh hơn khi yêu cầu AI làm mọi thứ. Và nó có tác dụng. Một thời gian.
Thực tế là prompt chỉ giải quyết vấn đề bề mặt. Chúng làm cho một tương tác AI đơn lẻ nhanh hơn. Chúng không làm cho workflow nhanh hơn. Chúng không làm cho nó đáng tin cậy hơn. Và chắc chắn chúng không ngăn AI bị drift, bỏ qua các bước xác minh, hoặc lặng lẽ bỏ qua các quyết định kiến trúc bạn đã đưa ra ba phiên trước.
Những kỹ sư thực sự đang ship nhanh hơn với AI ngày nay không phải vì họ giỏi prompt hơn. Họ đã xây dựng các hệ thống nơi AI không chỉ là bộ tạo code — mà là một thành viên tham gia trong một workflow có cấu trúc, tự củng cố. Đó là một vấn đề hoàn toàn khác cần giải quyết.
Nút thắt cổ chai chưa bao giờ là Model
Đây là một pattern mà nhiều kỹ sư sử dụng AI hàng ngày sẽ nhận ra. Bạn mở agent, mô tả một feature, và AI bắt đầu generate code. Trông có vẻ ổn. Bạn review. Bạn yêu cầu thêm thứ khác. Bạn copy context từ message trước, giải thích lại các ràng buộc, yêu cầu nó xác minh output của chính mình, và sau đó nhận ra nó đã chuyển sang implementation mà không thực sự review design. Bạn kéo nó lại. Bạn nhắc nó về edge case. Bạn đẩy nó viết tests. Bạn nhận ra nó viết tests cho implementation, không phải cho requirements.
Bạn đang làm rất nhiều công việc. Nhưng bạn không đang viết code.
Đây là nút thắt cổ chai thực sự: không phải khả năng của model, mà là overhead nhận thức của kỹ sư trong việc điều phối hành vi AI trong một workflow nhiều bước. Ngay khi bạn rời đi, hoặc context quá dài, hoặc bạn di chuyển quá nhanh, chất lượng suy giảm một cách lặng lẽ.
Điều đã thay đổi: Từ Commands đến Workflow Infrastructure
Sự thay đổi tinh tế nhưng quan trọng. Sáu tháng trước, một setup AI tinh vi có thể trông như thế này: một bộ reusable prompt templates, một số custom commands trong editor, một system prompt decent. Bạn có thể khởi động việc viết requirement nhanh hơn, cấu trúc planning tốt hơn, tránh một số sự lặp lại. Đây là setup của một power-user.
Nhưng các commands vẫn được invoke thủ công. Các templates vẫn phụ thuộc vào kỹ sư để kết nối requirement → design → implementation → review. Workflow chỉ nhất quán bằng với kỷ luật của kỹ sư vào một ngày nhất định.
Level tiếp theo — cái thực sự thay đổi trải nghiệm hàng ngày — là xây dựng workflow infrastructure: skills, memory, auto-triggered verification, và structured phase transitions. Các công cụ như AI DevKit vận hành sự thay đổi này. Sự khác biệt trong thực tế:
| Khía cạnh | ❌ Cũ (Commands + Templates) | ✅ Mới (Workflow System) |
|---|---|---|
| Context giữa các phiên | Mất. Phải giải thích lại mỗi lần. | Được lưu trong memory. Tự gợi nhớ. |
| Tiến trình workflow | Kỹ sư trigger thủ công từng bước. | Skill system tự advance phases. |
| Xác minh | Bỏ qua khi di chuyển nhanh. | Auto-triggered. Khó bỏ qua. |
| Phạm vi test | Tests viết cho implementation. | Tests viết cho requirements. |
| Engineering rules | Phụ thuộc trí nhớ kỹ sư. | Lưu trong memory, tự surface. |
| Vai trò kỹ sư | Orchestrator + developer + reviewer. | Product decision-maker + final reviewer. |
Ví dụ cụ thể: Từ một câu đến PR trong dưới 30 phút
Đây là workflow infrastructure trông như thế nào trong thực tế, từ một feature implementation thực sự.
Feature: khi người dùng chạy ai-devkit skill add <registry> mà không chỉ định tên skill, hiển thị danh sách multi-select tương tác để họ chọn cái cần cài đặt. Nhỏ, nhưng thực tế. Một câu lệnh cho Codex.
Điều xảy ra tiếp theo không phải là code generation. Đó là một workflow:
- Requirement phase: System scaffolded một requirement document có cấu trúc — không chỉ paraphrase prompt, mà mở rộng với edge cases và constraints.
- Memory recall: Không cần nhắc, system surfaced một rule đã lưu trước đó: CLI commands cần non-interactive fallback cho môi trường CI. Đây là quyết định được đưa ra trong một phiên khác. Kỹ sư không cần phải nhớ nó.
- Design review: System review requirement, sau đó review design đề xuất so với requirement. Hai passes riêng biệt.
- Implementation với progress tracking: Khi tasks hoàn thành, planning document tự động cập nhật.
- Verification: Implementation được kiểm tra so với cả requirement document và design. Không phải kiểm tra theo cảm tính. Structured verification.
- Test generation: Tests được viết so với requirement, không phải implementation. Đây là sự phân biệt quan trọng — nó phát hiện drift.
- Code review: Một lần review cuối trước khi tạo PR.
Tổng thời gian từ ý tưởng đến PR: dưới 30 phút. Tổng output: requirement doc, design doc, planning doc, implementation, tests, review artifacts. Và đóng góp của kỹ sư là: đặt intent, một quyết định product (giữ v1 đơn giản, flat list là đủ), và review cuối.
Điều vẫn cần bạn
Rất dễ để phóng đại ở đây. Một workflow system không thay thế engineering judgment. Nó cụ thể không nên cố thay thế.
Các quyết định cần con người vẫn giữ nguyên: cần build gì, trade-off nào chấp nhận, khi nào "đủ tốt" là thực sự đủ tốt, cái gì cần deprioritize cho v1. Đây là những quyết định product engineering phụ thuộc vào context mà AI không có — business constraints, team dynamics, user feedback, architectural vision.
Điều thay đổi là surface area nơi human judgment thực sự cần thiết. Khi workflow system xử lý context persistence, phase transitions, và verification, kỹ sư được dành năng lượng nhận thức cho những thứ thực sự cần nó.
Insight kỹ thuật cốt lõi
Insight thực sự từ việc quan sát pattern này tiến hóa là giá trị của AI trong engineering không chủ yếu là về tốc độ code generation. Đó là về việc làm workflow discipline bền vững ở tốc độ cao.
Không có AI, workflow discipline tốt (requirement review, design review, test-first, verification) rất tốn kém. Các team bỏ qua nó khi bị áp lực. Nó đòi hỏi kỷ luật cá nhân để duy trì nhất quán. Nó không scale.
Với một AI workflow system được thiết kế tốt, discipline trở nên có cấu trúc. Verification xảy ra vì system làm cho nó xảy ra, không phải vì kỹ sư nhớ yêu cầu nó. Memory persist vì nó được lưu trữ, không phải vì kỹ sư giải thích lại. Phase transitions xảy ra vì skill trigger chúng, không phải vì ai đó check checklist.
Đó là unlock thực sự. Không phải "AI viết code cho tôi." Mà là "AI làm cho engineering practices của team tôi nhất quán ở tốc độ mà trước đây không thể."
Nếu setup AI hiện tại của bạn chủ yếu giúp bạn viết code nhanh hơn nhưng vẫn khiến bạn phải carry workflow trong đầu — kiến trúc, các bước verification, context giữa các phiên — đó là khoảng cách đáng đóng lại tiếp theo.
Nguồn tham khảo: Bài viết này được lấy cảm hứng từ bài viết gốc của Hoang Nguyen về cách AI workflow của anh ấy tiến hóa từ prompts đến một workflow system hoàn chỉnh, và dự án open-source AI DevKit.