Thực chiến: Hướng dẫn từng bước sử dụng 7 Agent để nâng cấp Vibe Coding thành quy trình phát triển chuyên gia

Tác giả @sairahul1 phân tích cuộc cách mạng quy trình làm việc từ "Vibe Coding" lên "Nhà máy phần mềm": chia nhỏ cuộc trò chuyện AI thành 7 đại lý chuyên trách: nhà nghiên cứu, người viết câu chuyện, người viết đặc tả, người xây dựng backend, người xây dựng frontend, người xác nhận thử nghiệm, người xác thực thực thi, mỗi người chỉ có một nhiệm vụ, có bối cảnh rõ ràng và giới hạn nghiêm ngặt.
（Tiểu sử: MCP kết nối vạn vật cộng với Web3, có thể trở thành làn sóng kể chuyện AI gấp trăm lần tiếp theo?）
（Bổ sung nền: Nhà đầu tư siêu đẳng giúp bạn làm việc! Tập hợp Buffett, Munger, Cathie Wood… 19 AI Agent giúp phân tích thị trường）

Mục lục bài viết

Toggle

• Vấn đề mọi người không đề cập
• Chuyển đổi: Từ Vibe Coding đến nhà máy phần mềm
• Bảy đại lý
  • Đại lý 1: Nhà nghiên cứu mã nguồn (Codebase Researcher)
  • Đại lý 2: Người viết câu chuyện (Story Writer)
  • Đại lý 3: Người viết đặc tả (Spec Writer)
  • Đại lý 4: Người xây dựng backend (Backend Builder)
  • Đại lý 5: Người xây dựng frontend (Frontend Builder)
  • Đại lý 6: Người xác nhận thử nghiệm (Test Verifier)
  • Đại lý 7: Người xác thực thực thi (Implementation Validator)
• Toàn bộ chuỗi hoạt động diễn ra như thế nào
• Cơ bản: Trước khi đại lý hoạt động, bạn cần cái này
  • CLAUDE.md ── Ghi nhớ trong mỗi cuộc trò chuyện
  • Trôi dạt ngữ cảnh ── Kẻ giết người thầm lặng
• Kết quả: Thực sự thay đổi là gì
  • Trước nhà máy:
  • Sau nhà máy:
  • Thay đổi thực sự:
• Cuối tuần này tự làm phiên bản của riêng bạn
  • Danh sách 8 bước thiết lập:
• Bảy đại lý ── Tham khảo nhanh

Tôi cứ nghĩ mình đang dùng AI để lập trình. Thực ra, tôi chỉ gõ nhanh hơn thôi.

Bài viết này nói về sự khác biệt đó — và hệ thống "7 đại lý" hoàn toàn thay đổi mọi thứ.

Hãy lưu lại bài này. Nó sẽ giúp bạn tiết kiệm vài tháng.

Vấn đề mọi người không đề cập

Vòng lặp năng suất tưởng như hiệu quả nhưng thực ra không:

→ Cần Claude giúp tạo một chức năng → Nó sinh ra mã → Có chỗ hỏng → Dán lỗi trở lại → Nó sửa → Lại hỏng chỗ khác → Hỏi lại

Ngày 1: Trông như phép thuật.

Ngày 30: Bạn dành nhiều thời gian giám sát AI hơn là tự viết code trước đây.

Logic tương tự xuất hiện ở ba nơi khác nhau. Claude quên quy ước bạn đã đặt hai tuần trước. Chức năng mới làm hỏng chức năng cũ. Việc kiểm thử thiếu hoặc quá sơ sài.

Một ngày nào đó bạn thức dậy mới nhận ra: Không phải AI thất bại, mà là quy trình làm việc của bạn thất bại.

Bản chất vấn đề là cấu trúc.

Khi bạn nhập "giúp tôi làm chức năng này" trong Claude Code, thực ra bạn đang yêu cầu một AI trò chuyện đồng thời đóng vai:

→ Nhà phân tích sản phẩm → Kiến trúc sư → Kỹ sư backend → Kỹ sư frontend → Kỹ sư thử nghiệm → Người xem xét mã

Tất cả cùng lúc. Trong một cuộc trò chuyện hỗn độn.

Giả định sai trong kế hoạch sẽ biến thành mô hình dữ liệu sai. Mô hình dữ liệu sai sẽ thành API sai. API sai sẽ thành UI sai.

Khi bạn nhận ra, lỗi đã lan ra khắp nơi.

Đây chính là cái gọi là vibe coding (viết code theo cảm giác).

Nó có một giới hạn rất cứng.

Chuyển đổi: Từ Vibe Coding đến nhà máy phần mềm

Chìa khóa thực sự thay đổi mọi thứ:

Đội ngũ kỹ thuật thực sự sẽ không làm việc trong một cuộc trò chuyện lớn.

Mỗi người có công việc riêng:

→ Có người làm rõ vấn đề người dùng → Có người nghĩ về kiến trúc → Có người viết API → Có người viết UI → Có người nghĩ về giới hạn, ngoại lệ → Có người xem xét

Khi bạn gom tất cả vào một cuộc trò chuyện AI, lỗi sẽ âm thầm tích tụ.

Cách sửa là phân chia công việc cho các đại lý chuyên môn.

Mỗi đại lý sẽ nhận:

→ Một nhiệm vụ tập trung → Bối cảnh sạch sẽ của riêng nó → Chỉ có công cụ cần thiết cho nó → Quy tắc nghiêm ngặt về phạm vi "không được chạm" của nó

Kết quả:** Một nhà máy phần mềm.**

Một nhà phát triển + bảy đại lý tập trung = Một đội phối hợp.

Dưới đây là bảy đại lý giúp hệ thống hoạt động.

Bảy đại lý

Đại lý 1: Nhà nghiên cứu mã nguồn (Codebase Researcher)

Sai lầm lớn nhất của nhà phát triển khi dùng AI là gì?

Đặt "yêu cầu mã nguồn" là bước đầu tiên.

AI nhận prompt, đoán mò điền vào chỗ trống, rồi bắt đầu sinh ra. Thiết kế tồi là lúc này nó lén lút xâm nhập.

Nhà nghiên cứu sửa chuyện này.

Nhiệm vụ duy nhất của nó:Xem xét kho mã nguồn và giải thích trạng thái hiện tại — trước khi một dòng mã được viết ra.

Nó làm gì:

• Đánh dấu các tệp liên quan và vai trò của chúng
• Ghi lại các mẫu đã có cần tuân thủ
• Tìm các chức năng tương tự đã xây
• Đánh dấu rủi ro (múi giờ, đa thuê, logic thử lại)
• Liệt kê các thử nghiệm cần cập nhật

Nó không thể làm gì:

• Chỉnh sửa tệp (chỉ đọc)
• Thực thi lệnh thay đổi trạng thái
• Đưa ra giả định — nên hỏi lại

Công cụ: Read, Grep, Glob, chỉ thế thôi.

Quy tắc: Trước khi bắt đầu, luôn khám phá.

Nhà nghiên cứu luôn chạy trước.

Đại lý 2: Người viết câu chuyện (Story Writer)

Phần lớn thất bại của chức năng không phải do mã sai.

Mà vì vấn đề chưa bao giờ được định nghĩa rõ ràng.

Người viết câu chuyện biến ý tưởng sơ bộ thành một câu chuyện người dùng thực sự — trước khi các quyết định kỹ thuật được đưa ra.

Đầu vào:

• Mô tả chức năng sơ bộ của bạn
• Kết quả khảo sát của nhà nghiên cứu

Đầu ra:

• Một câu chuyện người dùng: "Là [vai trò], tôi muốn [hành động], để [kết quả]."
• Tiêu chuẩn chấp nhận: Các mô tả có thể kiểm thử trực tiếp. Happy path, các đường thất bại, quy tắc kinh doanh.
• Ngoại lệ: Các giới hạn, thử lại, cân nhắc đa thuê.
• Không trong phạm vi: Những gì rõ ràng là "không làm".
• Vấn đề chưa rõ: Những thứ nó thực sự không biết — tuyệt đối không đoán mò.

Nó không thể làm gì:

• Bịa ra quy tắc kinh doanh
• Viết mã hoặc thiết kế kỹ thuật
• Tiếp tục khi có phần chưa rõ

Công cụ: Read, chỉ thế thôi.

Quy tắc: Bạn phải đọc và phê duyệt câu chuyện này, mới tiếp tục.

Đây là chìa khóa để mọi thứ phía sau không sai sót — Điểm phê duyệt 1 của con người.

Đại lý 3: Người viết đặc tả (Spec Writer)

Sau khi câu chuyện được phê duyệt, người viết đặc tả biến nó thành một bản trình bày kỹ thuật.

Bản trình bày này là bản đồ cho các đại lý xây dựng sau này theo dõi.

Đầu vào:

• Câu chuyện người dùng đã phê duyệt
• Kết quả khảo sát của nhà nghiên cứu
• Quy tắc CLAUDE.md của dự án

Đầu ra:

• Thay đổi mô hình dữ liệu (trường, kiểu, di chuyển)
• Quy trình nền / xử lý
• Thay đổi API (đầu cuối, request/response)
• Thay đổi frontend (thành phần, trang, hooks)
• Các thử nghiệm cần thiết (thành công, thất bại, ngoại lệ)
• Rủi ro và vấn đề chưa rõ
• Các tệp sẽ bị thay đổi

Nó không thể làm gì:

• Chỉnh sửa tệp
• Bịa ra hạ tầng mới — phải rõ ràng chỉ ra
• Bỏ qua cân nhắc đa thuê, múi giờ
• Để lại câu hỏi không có câu trả lời

Công cụ: Read, Grep, Glob, chỉ thế thôi.

Quy tắc: Bản trình bày này là Điểm phê duyệt 2 của con người.

Bạn đọc, phê duyệt, mới có thể có các tệp được cập nhật.

Nếu bạn thấy "lưu ID vào bộ nhớ" — đó là cảnh báo đỏ.

Hiện tại, hãy phát hiện ra. Đừng đợi đến khi 10 tệp thay đổi.

Đại lý 4: Người xây dựng backend (Backend Builder)

Bây giờ mới bắt đầu xây dựng.

Người xây dựng backend thực hiện phần "phía server" — chỉ chịu trách nhiệm phần backend.

Đầu vào:

• Bản trình bày kỹ thuật đã phê duyệt
• Kết quả khảo sát của nhà nghiên cứu
• Quy tắc CLAUDE.md của dự án

Nó xây dựng:

• Các route API
• Các dịch vụ và logic kinh doanh
• Truy cập và di chuyển dữ liệu
• Các tác vụ nền
• Các bài kiểm thử đơn vị của mã nó viết

Nó không thể làm gì:

• Chạm vào thành phần React, trang, hooks phía client (đó là công việc của đại lý 5)
• Bịa ra dependency mới khi không có chỉ dẫn
• Chỉnh sửa ngoài phạm vi
• Dừng lại khi chưa chạy typecheck, lint, test

Sau khi xong, nó sẽ gửi lại một bản tóm tắt: các tệp mới hoặc chỉnh sửa, các helper hoặc mẫu đã tái sử dụng, các quan sát "nếu có quy tắc CLAUDE.md sẽ tốt hơn".

Công cụ: Read, Edit, Write, Bash — chỉ trong thư mục backend.

Chìa khóa là tách biệt chính nó.

Người xây dựng backend luôn không thể vô tình làm hỏng frontend.

Đại lý 5: Người xây dựng frontend (Frontend Builder)

Người xây dựng frontend thực hiện phần UI — chỉ phần UI.

Nó sẽ đọc tóm tắt của người xây dựng backend.

Điều này rất quan trọng.

Nó sẽ dùng API theo hình dạng do backend đưa ra. Không tự phát minh endpoint mới.

Nếu API không phù hợp với UI,** nó sẽ báo lỗi — chứ không tự sửa.**

Đầu vào:

• Bản trình bày kỹ thuật đã phê duyệt
• Kết quả khảo sát của nhà nghiên cứu
• Tóm tắt API của backend (hợp đồng API)

Nó xây dựng:

• Các thành phần React, trang
• Hooks và trạng thái phía client
• Trạng thái loading, lỗi
• Các thành phần và kiểm thử đơn vị của mã nó viết

Nó không thể làm gì:

• Chạm vào services, route API, worker hoặc di chuyển (đó là công việc của đại lý 4)
• Bịa ra endpoint hoặc định dạng phản hồi
• Thêm dependency mà không có chỉ dẫn
• Dừng lại khi chưa chạy typecheck, lint, test

Công cụ: Read, Edit, Write, Bash — chỉ trong thư mục frontend.

Hai nhà xây dựng. Hai bối cảnh sạch sẽ. Không có khả năng làm hỏng nhau.

Đại lý 6: Người xác nhận thử nghiệm (Test Verifier)

Cả hai nhà xây dựng đều tự viết kiểm thử đơn vị.

Nhưng chưa đủ.

Người xác nhận thử nghiệm chỉ làm một việc:Chứng minh chức năng này thực sự làm đúng câu chuyện người dùng nói.

Nó viết "kiểm thử chấp nhận" (acceptance tests), không phải unit test.

Kiểm thử chấp nhận kiểm tra chức năng từ bên ngoài — như một người dùng thực sự trải nghiệm.

Đầu vào:

• Câu chuyện người dùng đã phê duyệt (bao gồm tất cả tiêu chuẩn chấp nhận)
• Bản trình bày kỹ thuật đã phê duyệt
• Tóm tắt của hai nhà xây dựng

Kết quả:

• Một tệp kiểm thử chấp nhận bao phủ từng tiêu chuẩn
• Báo cáo: tiêu chuẩn nào qua, tiêu chuẩn nào thất bại, tiêu chuẩn nào không thể kiểm thử rõ ràng

Nó không thể làm gì:

• Chỉnh sửa mã backend hoặc frontend
• Bịa ra cách vượt qua tiêu chuẩn không thể kiểm thử
• Đánh dấu tiêu chuẩn không được kiểm thử là đã qua

Nếu một kiểm thử thất bại: chức năng không đáp ứng câu chuyện.

Nó sẽ báo: "Tiêu chuẩn nào thất bại". Nó không sửa mã.

Việc sửa sẽ gửi lại cho nhà xây dựng đúng.

Công cụ: Read, Edit, Write (chỉ kiểm thử), Bash.

Quy tắc: Trước khi kiểm thử chấp nhận thành công, bạn chưa có chức năng này.**

Đại lý 7: Người xác thực thực thi (Implementation Validator)

Đây là đại lý phát hiện những thứ mọi người bỏ sót.

Nó so sánh thực thi hiện tại với câu chuyện và bản trình bày đã phê duyệt,** báo cáo chênh lệch**.

Nó không bao giờ sửa gì. Nó chỉ nói sự thật.

Mỗi lần chạy kiểm tra:

• Tiêu chuẩn chấp nhận còn chưa thực hiện
• Các đường thất bại chưa có kiểm thử bao phủ
• Vấn đề an toàn: thiếu kiểm tra quyền, lỗ hổng phân tách thuê, key trong log, lỗi lỗ hổng dữ liệu
• Các tệp ngoài phạm vi bị thay đổi
• Mẫu không phù hợp với CLAUDE.md hoặc mã cũ
• Các helper đã tái sử dụng bị viết lặp
• Các cân nhắc múi giờ hoặc đa thuê bị bỏ qua trong bản trình bày

Kết quả luôn phân theo mức độ nghiêm trọng:

• Critical — Phải sửa trước khi hợp nhất
• Important — Nên sửa trước khi hợp nhất
• Minor — Ý kiến cá nhân, do người xem quyết

Mỗi phát hiện kèm theo đường dẫn tệp và dòng số.

Nếu không có vấn đề, nó sẽ nói "Không có vấn đề". Nó không bịa ra vấn đề để trông có vẻ nghiêm túc.

Công cụ: Read, Grep, Glob, chỉ thế thôi.

Đây chính là lý do khiến nhà máy này đáng tin cậy.

Bảng tự đánh giá không có giá trị. Một người xác thực chỉ nhìn "trên đĩa có gì", không xem "viết thế nào" mới là trung thực.

Chuỗi hoạt động toàn bộ diễn ra như thế nào

Toàn bộ quy trình — một prompt kích hoạt mọi thứ:

Bạn mở Claude Code, nhập:

"Giúp tôi làm chức năng 'nhắc nhở hóa đơn chưa thanh toán quá 7 ngày'."

Tiếp theo, bạn không cần gõ gì thêm, nó sẽ tự diễn ra như sau:

Bước 1 → Nhà nghiên cứu quét qua mã liên quan đến hóa đơn, thanh toán, email. Trả về các tệp liên quan, mẫu cũ, rủi ro.

Bước 2 → Người viết câu chuyện tạo ra câu chuyện người dùng và tiêu chuẩn chấp nhận.

⏸ Tạm dừng: Bạn đọc và phê duyệt câu chuyện.

Bước 3 → Người viết đặc tả biến câu chuyện thành bản trình bày kỹ thuật.

⏸ Tạm dừng: Bạn đọc và phê duyệt bản trình bày. (Ở đây phát hiện lỗi "lưu ID vào bộ nhớ".)

Bước 4 → Người xây dựng backend thực hiện service, route API, BullMQ job, kiểm thử đơn vị. Trả về: các tệp thay đổi, mẫu tái sử dụng, tất cả đều thành công.

Bước 5 → Người xây dựng frontend đọc tóm tắt API của backend, tạo UI quản trị và nút nhắc, viết kiểm thử thành phần. Tất cả thành công.

Bước 6 → Người xác nhận thử nghiệm viết kiểm thử chấp nhận cho 6 tiêu chuẩn. Báo cáo: 7 qua, 1 thất bại — do thủ công kiểm tra quyền thuê.

Bước 7 → Người xác thực phát hiện. Báo cáo mức Critical, kèm đường dẫn tệp và dòng.

→ Quay lại người xây dựng backend. Sửa. Tất cả 8 tiêu chuẩn đều qua. Người xác thực chạy lại. Mọi thứ sạch sẽ.

⏸ Tạm dừng: Bạn xem xét và tạo PR.

Ba điểm kiểm tra của con người. Các phần còn lại tự chạy.

Cơ bản: Trước khi đại lý hoạt động, bạn cần cái này

CLAUDE.md ── Ghi nhớ trong mỗi cuộc trò chuyện

Mỗi lần bạn mở Claude Code, nó bắt đầu từ "không nhớ gì".

CLAUDE.md sửa chuyện này.

Nó là file Markdown trong thư mục gốc repo, tự động tải mỗi khi bắt đầu cuộc trò chuyện.

Nó là nơi lưu giữ "sự thật dự án vĩnh viễn":

• Ngăn xếp công nghệ của bạn (Next.js App Router, Node.js, Prisma, BullMQ, Resend)
• Các lệnh của bạn (npm run dev, npm test, npx prisma migrate dev)
• Quy tắc kiến trúc (“Logic kinh doanh để trong services. API giữ mỏng.”)
• Những việc không làm (“Không thêm cron — dùng BullMQ. Không ghi payload thanh toán gốc vào log.”)
• Chỉ số tài liệu chi tiết (docs/billing.md, docs/architecture.md)

Giữ trong khoảng 100–300 dòng.

Mỗi lần AI mắc lỗi khiến bạn ngạc nhiên, hỏi: "Nếu trong CLAUDE.md có quy tắc này, lần này có thể tránh không?"

Thêm quy tắc vào.

Sau vài tuần, CLAUDE.md của bạn sẽ trở thành ghi chép tất cả giả định AI từng sai. Cuộc trò chuyện của bạn rõ ràng hơn nhiều.

Trôi dạt ngữ cảnh — Kẻ giết người thầm lặng

Hầu hết các cuộc trò chuyện Claude Code không thất bại rõ ràng.

Chúng sẽ trôi dạt.

Một giả định sai lầm lọt vào ngữ cảnh. Mô hình cứ thế cộng dồn.

Bạn muốn Claude quản lý "quản lý đăng ký". Nó thiết kế: User → Subscription.

Bạn sau đó mới nhớ: đăng ký thuộc về "công ty", không phải "người dùng".

Nếu bạn chỉ nói "Không đúng, đăng ký thuộc về công ty" — Claude sẽ vá lỗi.

Giờ bạn có cả user.subscriptionId lẫn company.subscriptionId trôi nổi khắp nơi.

Quy tắc:

• Sai chính tả? Sửa trực tiếp.
• Giả định sai về kiến trúc? Bỏ toàn bộ cuộc trò chuyện, bắt đầu lại từ đầu, đưa giả định đúng vào prompt đầu tiên.

Một cuộc trò chuyện sạch sẽ, đúng mô hình tư duy, luôn tốt hơn là vá lỗi qua các patch.

Kết quả: Thực sự thay đổi là gì

Trước nhà máy:

• Vòng lặp vibe coding: prompt → sinh ra → lỗi → vá → lặp lại
• Ngữ cảnh trò chuyện đầy nhiễu
• Giả định sai tích tụ thành chức năng hỏng
• Một kỹ sư chỉ làm được một việc tại một thời điểm
• Mỗi chức năng đều chờ người phù hợp rảnh

Sau nhà máy:

• Chuỗi có cấu trúc: nghiên cứu → câu chuyện → trình bày → xây dựng → xác nhận → kiểm tra
• Mỗi đại lý có bối cảnh sạch, chỉ chứa thứ cần
• Giả định sai bị bắt ngay trong "phê duyệt trình bày" — chứ không phải 10 tệp sau
• Một kỹ sư có thể tạo ra một phần hoàn chỉnh theo chiều dọc: backend, frontend, thử nghiệm, xác nhận
• Kiến thức tốt nhất của nhóm nằm trong các đại lý — không bị mắc kẹt trong "ai đó"

Thay đổi thực sự:

Chuyên gia thanh toán tạo ra một đại lý payments-integration. Từ đó, mọi kỹ sư trong nhóm đều có thể xuất chức năng liên quan thanh toán. Không cần chờ, không cần bàn giao.

Mẫu component của frontend lead, nằm trong đại lý frontend-builder. Kỹ thuật CI của DevOps, nằm trong hook. Quy tắc về giới hạn của QA, nằm trong quy tắc test-verifier.

Kiến thức chuyên môn, được chia sẻ qua đại lý. Không bị mắc kẹt trong "ai rảnh".

Cuối tuần này tự làm phiên bản của riêng bạn

Danh sách 8 bước thiết lập:

2. Cài Claude Code → code.claude.com

3. Tạo cấu trúc thư mục:

   • .claude/agents/
   • .claude/skills/feature-factory/
   • .claude/skills/build-with-tests/
   • .claude/hooks/

4. Viết CLAUDE.md của bạn (100–300 dòng: công nghệ, lệnh, quy tắc, danh sách không làm)

5. Dùng lệnh /agents của Claude Code để tạo 7 đại lý. Mô tả vai trò từng đại lý. Claude tạo file. Bạn xem xét và commit.

6. Tạo skill orchestrator feature-factory. Yêu cầu Claude giúp viết — nó sẽ đọc 7 file agent của bạn và kết nối toàn bộ chuỗi.

7. Tạo skill build-with-tests. Mô tả cách nhóm của bạn xây dựng: phù hợp mẫu, viết test song song, cuối cùng chạy typecheck.

8. Thêm hook pre-commit. Chặn việc commit .env, .key, .pem hoặc secrets.json. 5 phút, tránh thảm họa lớn.

9. Chạy một chức năng thực tế qua toàn bộ chuỗi. Chọn nhỏ nhất. Quan sát chỗ bị kẹt. Thêm quy tắc. Nhà máy sẽ tự điều chỉnh.

Thời gian tổng: 2–3 giờ.

Chạy vài chức năng. Sau 3–4 lần, nhà máy đã hiểu code của bạn.

Bạn sẽ dành ít thời gian giám sát hơn, nhiều thời gian hơn để quyết định "tiếp theo làm gì".

Bảy đại lý — Tham khảo nhanh

• Researcher — Trước khi mọi thứ hình thành, quét qua mã (chỉ đọc)
• Story Writer — Biến ý tưởng thành câu chuyện người dùng và tiêu chuẩn chấp nhận (chỉ đọc)
• Spec Writer — Biến câu chuyện thành bản trình bày kỹ thuật (chỉ đọc)
• Backend Builder — Xây API, dịch vụ, job, kiểm thử đơn vị (chỉ trong thư mục backend)
• Frontend Builder — Xây thành phần, trang, hooks, UI test (chỉ trong thư mục frontend)
• Test Verifier — Viết kiểm thử chấp nhận dựa câu chuyện (chỉ trong tệp kiểm thử)
• Validator — So sánh thực thi với câu chuyện và trình bày, báo cáo chênh lệch (chỉ đọc)

3 điểm kiểm tra của con người:

→ Phê duyệt câu chuyện → Phê duyệt trình bày → Phê duyệt PR

Các phần còn lại tự chạy.

Hầu hết các nhà phát triển dùng Claude Code vẫn còn vibe coding. Prompt → sinh ra → vá lỗi → cầu nguyện.

Không sai. Nhưng có giới hạn.

Nhà máy không đuổi bạn ra khỏi quy trình. Nó giúp bạn thoát khỏi phần "không cần phán đoán".

Bạn sẽ còn lại trong các phần "phán đoán của bạn thực sự quan trọng":

Đây có phải vấn đề đúng không? Đây có phải thiết kế đúng không? Có an toàn để deploy không?

Tất cả phần trung gian, đại lý lo.

Đây chính là sự khác biệt giữa "dùng AI như bàn phím nhanh hơn" và "dùng AI như một đội ngũ phối hợp".

Nguồn: @sairahul1