Cách xây dựng một startup AI-native

• Trong mô hình vận hành mới, khi AI xử lý các công việc lặp lại vào ban đêm, nhà sáng lập tập trung vào cải thiện sản phẩm; thay đổi thực sự không nằm ở cách dùng thời gian mà ở tốc độ công ty học hỏi, lặp lại và tiến hóa
• Công ty AI-native thay đổi ngay từ mô hình vận hành: ít người hơn, cần ít điều phối hơn, các agent thực thi công việc lặp lại, còn con người tập trung vào định hướng, gu thẩm mỹ, quan hệ, kiểm chứng và trách nhiệm
• Quá trình chuyển đổi diễn ra theo các bước: lập bản đồ công việc, xây dựng hệ thống ngữ cảnh, chọn tự động hóa đơn giản nhất, biến công việc lặp lại thành kỹ năng, viết eval để đánh giá chất lượng, và vận hành vòng lặp cải tiến hằng tuần
• Các mô hình được thay thế và cải thiện mỗi tháng rồi dần trở nên giống nhau, nên tài sản riêng của công ty là hệ thống vận hành như ngữ cảnh và eval
• Trong môi trường mà ai cũng dùng cùng một mô hình, hào lũy thực sự là kỷ luật (discipline) — tức sự nhất quán trong việc mỗi tuần lập bản đồ công việc, tích lũy ngữ cảnh, viết eval và vận hành vòng lặp

---

Sự đối lập giữa hai startup

• So sánh hai công ty được thành lập cùng tháng trong cùng một thị trường vào lúc 9 giờ sáng
  • Ở công ty thứ nhất, người phụ trách vận hành đang xử lý các ticket hỗ trợ bị tồn đọng, nhà phân tích đang làm lại dashboard của tuần trước, còn nhà sáng lập đang họp standup vì một cuộc gọi khách hàng mà không ai giải quyết được — tất cả đều đang dọn dẹp vấn đề của ngày hôm qua nên sản phẩm bị đình trệ
  • Ở công ty thứ hai, agent đã xử lý tất cả những việc đó trong đêm — hoàn tất phân loại ticket, cập nhật dashboard, làm nổi bật rủi ro rời bỏ (churn risk) trong các cuộc gọi; nhà sáng lập thì đã bắt tay sửa vấn đề và cải thiện đội ngũ lẫn sản phẩm
• Khác biệt cốt lõi là tốc độ học hỏi: công ty thứ hai học nhanh hơn mỗi ngày, và đòn bẩy đó tích lũy theo lãi kép qua nhiều tuần, nhiều tháng và nhiều năm

Bước 1 - Lập bản đồ công việc (Map The Work)

• Liệt kê toàn bộ công việc lặp lại trong 2 tuần gần nhất — ghi chú cuộc gọi khách hàng, nghiên cứu lead, bản nháp outbound, phân loại hỗ trợ, QA sản phẩm, onboarding, release note, cập nhật nhà đầu tư, chỉ số hằng tuần, tái hiện bug, sàng lọc tuyển dụng, rà soát hóa đơn, theo dõi đối thủ cạnh tranh, v.v.
  • Nếu lặp lại thì đó là ứng viên để mã hóa, và trong lịch của nhà sáng lập thường có 20–40 đầu việc như vậy
  • Khi đội ngũ giai đoạn đầu liệt kê một cách trung thực, họ thường phát hiện ra 10–15 việc vốn đã là routine

• Phân loại theo cấp độ tự chủ

  • L1 là chỉ dành cho con người — quyết định chiến lược, tuyển dụng cuối cùng, hoàn tiền lớn, ký pháp lý, giao tiếp với hội đồng quản trị
  • L2 là AI chuẩn bị, con người phê duyệt — bản nháp cập nhật nhà đầu tư, redline hợp đồng, viết lại trang giá, macro hỗ trợ
  • L3 là AI thực thi, con người giám sát — phân loại inbound, định tuyến ghi chú cuộc họp, làm giàu lead, tạo bài test
  • L4 là tự chủ trong giới hạn rõ ràng — theo dõi đối thủ, tạo báo cáo ban đêm, trích xuất hóa đơn từ nhà cung cấp đã biết, phát hiện bất thường đơn giản

• Workflow nhàm chán thường thắng

  • Thay vì những việc nghe có vẻ hào nhoáng như bản ghi nhớ chiến lược hằng tuần, gắn thẻ hỗ trợ diễn ra thường xuyên gấp 10 lần mỗi ngày nên thu hồi được nhiều thời gian hơn và cung cấp dữ liệu đáp án sạch — tần suất thắng danh tiếng
  • Mục tiêu tấn công đầu tiên là những việc thường xuyên, đo lường được, có thể hoàn tác và gắn với nút thắt cổ chai thực sự

• Công việc không nên tự động hóa

  • Loại trừ những việc hiếm, mơ hồ, đòi hỏi độ tin cậy cao hoặc còn bất ổn
  • Đội ngũ C.H. Robinson từng đẩy việc phân loại 10.000 email mỗi ngày lên L4, nhưng phải quay về L2 vì không thể giám sát — khối lượng đã che lấp chi phí của phân loại sai
  • Nếu bạn không thể giải thích thế nào là một đầu ra tốt, thì công việc đó chưa sẵn sàng để mã hóa; và nếu chỉ một đầu ra sai cũng có thể làm tổn hại quan hệ khách hàng, hãy đi chậm lại

• Cấu hình khởi đầu

  • Bắt đầu với 1 trang và 3 workflow — cá nhân (phân loại inbox, daily brief, bản nháp cập nhật nhà đầu tư), đối diện khách hàng (tổng hợp cuộc gọi, phân loại ticket, làm giàu lead), nội bộ (tạo test, trích xuất hóa đơn, diễn giải chỉ số hằng tuần)
  • Thử nghiệm quá nhiều cùng lúc sẽ làm phân tán sự chú ý và gây ra kiểu thất bại phổ biến nhất: tạo ra 20 pilot dang dở

Bước 2 - Xây dựng hệ thống ngữ cảnh (Build The Context System)

• Ngữ cảnh là bộ nhớ vận hành (operating memory) của một startup AI-native, nơi lưu trữ mọi thứ công ty biết về chính mình để agent có thể đọc được
  • Mô hình có thể thay thế, nhưng ngữ cảnh mới là tài sản thực sự riêng của công ty — nó phân biệt giữa một agent làm việc như đồng sáng lập và một agent làm việc như nhân sự thời vụ hỗn loạn
  • Nếu thời gian viết lại đầu ra còn nhiều hơn thời gian review, thì vấn đề không nằm ở prompt hay mô hình mà ở chỗ agent chưa biết đủ về công ty

• Cách chẩn đoán hằng tuần

  • Giao một công việc tiêu biểu cho một agent mới chỉ có ngữ cảnh của workspace và yêu cầu 3 hành động tiếp theo
  • Nếu có từ 2 đề xuất mạnh trở lên thì ngữ cảnh đang phát huy tác dụng; nếu cả 3 câu trả lời đều chung chung thì ngữ cảnh đang nghèo nàn và không thể cứu bằng prompt

• Dựa trên kho lưu trữ Git

  • Bắt đầu với một kho lưu trữ Git dùng chung mà mọi thành viên và agent đều có thể đọc — có version control, diff, cả người lẫn agent đều đọc được, và không bị khóa vào runtime của một nhà cung cấp cụ thể
  • Workspace ở ngày thứ 7 có thể được tổ chức với một thư mục gốc duy nhất chứa CLAUDE.md, context/company.md, context/product.md, context/customers.md, context/lessons.md, cùng GTD.md cho công việc đang hoạt động
  • Giữ nó ở mức 40–60 dòng viết tay — tốt hơn một mớ văn bản rác 400 dòng được tạo ra nhưng chỉ dày đặc danh sách những điều cần tránh

• Phân tách theo ranh giới quyền hạn

  • Khi phát triển lớn hơn, có thể dùng kho công ty dùng chung + kho riêng theo chức năng (sales, product, engineering, finance, support), hoặc kho riêng theo dự án/khách hàng + thư mục gốc dùng chung cho toàn công ty
  • Ở quy mô enterprise, cấp quyền theo thư mục hoặc kho bằng máy chủ Git riêng như self-hosted Gitea, GitHub Enterprise hoặc GitLab
  • Harness nội bộ Goose của Block đọc cùng một luồng artifact theo scope từng vai trò; ngay khi scope bị lệch, nó bắt đầu trộn phát ngôn công khai với ngữ cảnh giao dịch riêng tư — ranh giới là cực kỳ quan trọng

• Ba loại dữ liệu đi vào hệ thống

  • Connector — thu thập dữ liệu bên ngoài từ SaaS, API, máy chủ MCP, email, lịch, CRM, support, analytics, GitHub, Linear, Stripe, warehouse và tài liệu
    • Mọi connector đều cần định danh, quyền theo scope, audit log và credential được quản lý; nếu không, nó sẽ trở thành lỗ hổng bảo mật lớn nhất — lớp IAM như Zitadel chịu trách nhiệm về kỷ luật định danh
    • Trong tác vụ thực thi mã MCP của Anthropic, mô hình nạp sẵn mọi định nghĩa công cụ theo mẫu filesystem thư mục máy chủ đã giảm mức dùng ngữ cảnh từ khoảng 150.000 token xuống khoảng 2.000 token, tức giảm 98,7% so với cách làm đó
  • Dữ liệu do công ty tạo ra — spec, tóm tắt khách hàng, quyết định, bài học, ghi chú dự án, quy tắc vận hành; mặc định là Markdown
    • Quy tắc quan trọng nhất là tách biệt bản gốc (raw) và bản chưng cất (distilled) — ghi âm cuộc gọi là bản gốc, còn quyết định rút ra từ cuộc gọi đó, phản đối của khách hàng, người phụ trách follow-up và rủi ro gia hạn là bản chưng cất mà agent thực sự tra cứu
    • Nhật ký quyết định nên được giữ theo kiểu append-only, mỗi dòng một mục, để quá trình suy luận luôn đi kèm với kết luận
  • Cơ sở dữ liệu và luồng dữ liệu — nơi dữ liệu gốc vốn đã tồn tại, như dữ liệu sản phẩm trong Postgres, marketing trong warehouse hay sự kiện analytics
    • Đừng mù quáng sao chép sang Markdown; hãy giữ DB là nguồn gốc, cấp cho agent một user chỉ đọc có giới hạn, tài liệu hóa schema trong tệp dành cho agent (data-models/postgres.md), và nêu rõ truy vấn cũng như quyền ghi được phép
    • Mặc định cấu hình để agent không thể xóa dữ liệu production — sự cố Replit giữa năm 2025 (một coding agent xóa DB production trong lúc chạy phiên) nhắc rằng chỉ dẫn trong prompt không phải là ranh giới bảo mật

• Phiên bản nâng cao và truy vết nguồn gốc

  • Đồ thị ngữ cảnh có cấu trúc — trước khi agent truy vấn, dữ liệu gốc được xử lý thành các thực thể và quan hệ như con người, công ty, phản đối, cam kết, yêu cầu tính năng, rủi ro gia hạn, follow-up, ngày tháng, quyết định và liên kết nguồn
    • Thay vì chỉ lưu transcript, hệ thống trích xuất nội dung để nối chuỗi các cuộc gọi của cùng một người hay dự án, nhờ đó có thể trả lời câu hỏi như “Rủi ro gia hạn của Vandelay Industries là gì?” bằng cách trích dẫn đúng dòng phát biểu
  • Mọi bản tóm tắt đều phải lần ngược được về nguồn (transcript, ticket, commit, hóa đơn, hàng dữ liệu DB) — nếu không có nguồn, những bản tóm tắt nghe hợp lý nhưng không thể kiểm chứng sẽ tích tụ, và chỉ cần câu trả lời sai đầu tiên là niềm tin vào toàn bộ agent sẽ sụp đổ
    • Có nguồn thì agent trở nên có thể audit, để thành viên trong nhóm chỉ cần một cú nhấp là kiểm tra được nguồn và giải quyết bất đồng trong vài giây

Bước 3 - Chọn tự động hóa đơn giản nhất (Choose The Simplest Automation)

• Đừng biến mọi quy trình làm việc thành agent - những hệ thống tốt nhất là sự pha trộn giữa script, con người được AI hỗ trợ, workflow mang tính quyết định và agent
  • Vai trò của nhà sáng lập là chọn công cụ nhẹ nhất có thể vận hành an toàn mà vẫn vượt được ngưỡng chất lượng

• Áp dụng theo từng loại công cụ

  • Script - các bước mang tính quyết định (xuất báo cáo, chuyển đổi CSV, chạy test, kiểm tra link, xác thực JSON, định dạng gói chỉ số hằng tuần)
  • Con người được AI hỗ trợ - các đầu ra cần phán đoán trước khi rời khỏi công ty (cập nhật cho nhà đầu tư, email của nhà sáng lập, nội dung giá, ghi chú hợp đồng)
  • Workflow - khi các bước đã được biết trước (thu thập cuộc gọi→tóm tắt→trích xuất phản đối→ghi chú CRM→tạo follow-up), engine như LangGraph, Temporal, Inngest, Prefect đảm nhiệm thứ tự, retry và khả năng quan sát
  • Agent - khi không thể định trước lộ trình (điều tra bug production, nghiên cứu thị trường, case hỗ trợ bất thường, tài khoản khách hàng bị rối)
    • bb agent của Browserbase là một agent đa năng đối diện qua Slack, nạp file kỹ năng và quyền theo phạm vi khác nhau cho từng tác vụ - tốt hơn việc tạo bot riêng cho từng việc (vì theo thời gian các bot sẽ lệch nhau)

• Harness - lớp an toàn 6 bước

  • Preflight - kiểm tra ngữ cảnh và quyền trước khi agent tiêu token
  • Plan - phân rã công việc và hiển thị giai đoạn đề xuất
  • Approve - cổng kiểm duyệt của con người hoặc mô hình phán định chặn kế hoạch xấu trước khi thực thi
  • Execute - thực thi công việc
  • Verify - xác minh đầu ra bằng test, schema, rubric và ví dụ
  • Log - ghi lại những gì đã xảy ra vào runbook để vòng lặp sau có đáp án đúng

• Guardrail phải nằm trong code và cấu hình (không phải prompt)

  • Prompt kiểu "đừng xóa dữ liệu production" không phải là ranh giới bảo mật
  • Những mục không thể thương lượng - giới hạn chi phí theo lần chạy/ngày, giới hạn retry, độ sâu gọi công cụ tối đa, thông tin xác thực theo phạm vi cho từng agent, cấm ghi vào production khi chưa phê duyệt, cấm auto-merge code, kill switch cho toàn bộ fleet
  • Các sự cố sinh đệ quy xảy ra suốt năm 2025 (agent liên tục gọi agent con) đã tạo ra chi phí thực cho đến khi harness bắt kịp - giới hạn phải được đặt ở runtime, trước cả khi mô hình có cơ hội phớt lờ chỉ thị

Bước 4 - Mã hóa kỹ năng và eval (Encode Skills And Evals)

• Mọi thứ đến đây mới chỉ là chuẩn bị; việc mã hóa công việc lặp lại thành kỹ năng và chấm bằng eval mới là động cơ giúp công ty tăng trưởng kép thêm một chút mỗi tuần
  • Kỹ năng là hướng dẫn tái sử dụng + ví dụ cho công việc lặp lại - sau khi làm tay hai lần thì mã hóa phần lặp lại
  • Mọi kỹ năng đều cần hình thức rõ ràng - phạm vi, đầu vào, ngữ cảnh cần nạp, quy trình, định dạng đầu ra, ví dụ, quy tắc escalation, người sở hữu, nhật ký chạy
  • Nếu không ghi rõ nhận gì, trả về gì, khi nào cần xin trợ giúp và ai bảo trì thì đó không phải kỹ năng mà chỉ là một prompt dài

• Ví dụ mẫu kỹ năng (customer-call-synthesis)

  • Scope: cuộc gọi bán hàng sau khi đã có transcript / Inputs: transcript, hồ sơ tài khoản, ngữ cảnh sản phẩm, cơ hội đang mở
  • Load: ICP, giá, roadmap sản phẩm, hệ phân loại phản đối / Steps: trích xuất sự kiện→gom cụm phản đối→xác định rủi ro→soạn follow-up
  • Output: ghi chú CRM, brief khách hàng, yêu cầu tính năng, hành động tiếp theo / Examples: 3 cuộc gọi trước đó có ghi chú kỳ vọng
  • Escalate: vấn đề pháp lý/bảo mật, rủi ro churn, giá enterprise / Owner: revenue lead / Eval: 30 cuộc gọi lịch sử có các trường trích xuất kỳ vọng

• Bắt đầu từ các kỹ năng thân thiện với nhà sáng lập

  • Tổng hợp cuộc gọi khách hàng - trích xuất phản đối, yêu cầu tính năng, rủi ro, cam kết và hành động tiếp theo từ transcript gốc
  • Phân loại inbox - sắp xếp tin nhắn của nhà đầu tư, khách hàng, tuyển dụng, vận hành và soạn nháp trả lời cho 3 nhóm đầu
  • Cập nhật cho nhà đầu tư - viết phần tường thuật từ chỉ số và quyết định, rồi trích dẫn hai phía
  • Phân tích trang giá - đối chiếu trang đang chạy với log phản đối khách hàng mới nhất
  • Tường thuật chỉ số hằng tuần - giải thích điều gì đã thay đổi, hỏng ở đâu và cần kiểm tra gì
  • Tạo test - chuyển spec thành test và PR nháp

• 3 lớp của eval (tích lũy theo thứ tự)

  • Thứ nhất, đáp án chuẩn được gán nhãn thủ công - con người đánh dấu đầu ra tốt là gì trên các ví dụ thực tế
  • Thứ hai, kiểm tra mang tính quyết định - cho phán định rõ ràng với chi phí bằng 0 (schema hợp lệ, số khớp với nguồn, link mở được, trích dẫn tồn tại, test pass)
  • Thứ ba, LLM phán định - chỉ cho những phần kiểm tra quyết định không chạm tới được (chất lượng văn bản, sắc thái, mức độ bám brief); mô hình nhỏ và nhanh là đủ nhưng cần hiệu chỉnh bằng các ví dụ do con người đánh dấu trước khi tin cậy

• Case study: tổng hợp cuộc gọi khách hàng

  • 30 cuộc gọi lịch sử được revenue lead đánh dấu - các sự kiện quan trọng, phản đối, rủi ro, follow-up
  • Kiểm tra quyết định - độ chính xác của tên, giá trị hợp đồng, tuần của ngày follow-up; còn việc brief có nghe giống cuộc gọi hay không thì do LLM phán định
  • Sau khoảng 50 lần chạy, thường có hai lỗi lặp lại - không theo được người nói trong cuộc gọi có từ 3 người trở lên, hoặc gộp hai phản đối khác nhau thành một - cần sửa ở cấp cụm và viết lại cho đến khi hành vi ổn định

• Case study: phân loại lead outbound

  • 300 lead lịch sử được nhà sáng lập gắn nhãn yes/no về mức độ phù hợp với ICP
  • Kiểm tra cơ học - công ty có thật hay không, website có tải được không, số lượng nhân viên có được điền không / phần còn lại để LLM phán định theo mô tả ICP
  • Khi đã có eval, các vòng lặp tiến hóa prompt mã nguồn mở (GEPA, DSPy) sẽ viết lại prompt phân loại qua đêm để khớp với nhãn - nhà sáng lập không đọc prompt cuối cùng; chỉ phán định của eval mới quan trọng

• 5 giai đoạn trưởng thành của eval

  • 1. kiểm tra thủ công một ví dụ → 2) chấm một số ít case bằng rubric đã viết → 3) áp dụng rubric đó lên 20~300 trường hợp lịch sử → 4) test bằng tập holdout mà agent chưa từng thấy → 5) theo dõi chỉ số kinh doanh mà kỹ năng được kỳ vọng sẽ tác động

• Giữ trạng thái tốt sau khi phát hành - 6 con số mỗi tuần

  • tỷ lệ chấp nhận, tỷ lệ override, chi phí mỗi lần chạy, cycle time, thời gian review, số lượng sự cố
  • Tỷ lệ chấp nhận là cốt lõi - nếu dưới khoảng 70% (các chỉnh sửa nhỏ vẫn được tính là chấp nhận) thì chưa sẵn sàng nâng mức tự chủ
  • Khi tỷ lệ chấp nhận thấp, viết lại prompt gần như không phải đáp án; thường là một trong bốn việc - thêm ngữ cảnh ở runtime, thu hẹp phạm vi kỹ năng, thêm ví dụ hoạt động vào file, hoặc viết quy tắc escalation rõ ràng cho các case lẽ ra không nên giao

Bước 5 - Biến đội ngũ thành AI-native (Make The Team AI-Native)

• Nhà sáng lập phải bắt đầu trước - con đường nhanh nhất để đưa cả đội sang cách vận hành mới là demo trực tiếp trong ngữ cảnh công ty
  • Trình diễn bản brief buổi sáng được kéo qua đêm từ calendar, inbox và Slack; bản tổng hợp khách hàng từ các cuộc gọi hôm qua; PR test do agent tạo dựa trên spec; và bản nháp cập nhật cho nhà đầu tư tạo từ gói chỉ số gần nhất
  • Mục tiêu là calibration - tự mình thấy rõ lớp agent làm được gì và không làm được gì
  • Jack Dorsey đã trực tiếp dùng các công cụ này nhiều giờ mỗi sáng trong suốt năm 2025 rồi tái cấu trúc Block - dẫn tới đợt tái cơ cấu hiệu quả quy mô lớn, và quyết định đó xuất phát từ ban lãnh đạo đã tự tay dùng agent

• Cài đặt ngay từ ngày đầu, onboarding kết thúc bằng sản phẩm đầu ra

  • Mỗi thành viên trong buổi đầu tiên phải bước ra với một đầu ra có thể ship ngay trong ngày đó (brief khách hàng đã được làm sạch, macro hỗ trợ, PR test, bài phê bình trang giá) - đào tạo không tạo ra công việc thực tế sẽ bị quên vào tuần sau
  • Công cụ Glass của Ramp tăng từ 20 người dùng mỗi ngày lên khoảng 700 chỉ trong 3 tháng nhờ quy tắc rằng mỗi buổi onboarding đều kết thúc bằng việc thêm 1 kỹ năng hoặc artifact của người mới vào thư viện dùng chung

• Vai trò của con người tăng lên

  • Con người thiết kế hệ thống, sở hữu quan hệ, phán định đầu ra và gánh trách nhiệm / agent chịu trách nhiệm thực thi
  • Những thành viên chỉ làm tác vụ hẹp sẽ bị lộ trong mô hình này; còn người biết chuyển phán đoán thành hướng dẫn, ví dụ và eval thì có giá trị hơn trước

• Tuyển dụng cũng thay đổi

  • Ngưỡng để mở một vai trò mới cao hơn - một phần những việc trước đây cần tuyển nay đã trở thành kỹ năng, nên chỉ mở vai trò mới cho những việc thực sự cần con người
  • Khi tuyển, thay vì hỏi kiến thức vặt, hãy giao một dự án lớn không thể hoàn thành bằng tay trong thời gian cho trước và quan sát cách họ chỉ huy agent - xem khả năng phán đoán, gu và năng lực phục hồi khi agent đi chệch hướng
  • Ví dụ thực tế - nhà phân tích làm báo cáo thật trong 3 giờ từ thu thập nguồn, trích xuất bằng chứng đến brief hoàn chỉnh; kỹ sư trong 1 ngày sao chép bề mặt sản phẩm thật hoặc xây công cụ nội bộ từ spec (kèm test); ứng viên growth lập market map và kế hoạch campaign cho 50~100 công ty (scraping, gom cụm, viết, ưu tiên) - điểm cốt lõi là tất cả đều không thể hoàn thành đúng hạn nếu làm hoàn toàn bằng tay

Bước 6 - Vận hành startup như một vòng lặp phản hồi (Run As A Feedback Loop)

• Startup AI-native cải thiện hệ thống vận hành mỗi tuần - quay lại từ đầu và bắt đầu lại
  • Nội dung review cần bao quát - agent đã làm gì, điểm nào con người override, eval nào thất bại, context nào bị thiếu, kỹ năng nào cần thu hẹp, workflow nào nên loại bỏ, workflow nào nên nâng mức độ tự chủ

• Chạy đồng thời hai vòng lặp

  • Inner loop - cải thiện các tác vụ hiện có (chi phí mỗi lần chạy↓, cycle time↓, sự cố↓, thời gian review trên mỗi artifact↓)
  • Outer loop - khám phá các yếu tố tiếp theo (phân khúc khách hàng mới, ý tưởng sản phẩm, thay đổi giá, quan hệ đối tác, động thái của đối thủ, thay đổi quy định, rủi ro churn), agent chạy nền cung cấp ứng viên 24 giờ mỗi ngày và con người chọn mục tiêu để theo đuổi

• Software factory (phần lớn nhất của inner loop)

  • Con người viết spec và test, agent triển khai theo đó, các kiểm tra mang tính quyết định tự chạy và con người review trước khi merge
  • Bắt đầu từ những nơi có tiêu chí chấp nhận rõ ràng và phạm vi ảnh hưởng nhỏ - tạo test, nâng cấp dependency, migration, công cụ nội bộ, integration scaffold, script QA, tự động sửa lỗi bảo mật
  • Hai quy tắc cứng - không có gì được auto-merge, không agent nào được ghi trực tiếp vào production
    • Ngay cả Cursor cũng vẫn duy trì cổng review của con người trước khi merge cho đến đầu năm 2026, dù đang vận hành các agent cloud tự chủ ở quy mô lớn - chính cổng này giúp phần còn lại mở rộng an toàn

• Hệ thống học hỏi thị trường (outer loop)

  • Ghi âm cuộc gọi, trích xuất objection, gom cụm yêu cầu tính năng, theo dõi đối thủ, quan sát thay đổi trong cách sử dụng, đọc các mẫu hỗ trợ, nghiên cứu các thương vụ đã mất
  • Chuyển các phát hiện thành giả thuyết rồi kiểm thử những giả thuyết mạnh nhất - trao đổi với khách hàng, test landing page, thử nghiệm sản phẩm, truy vấn mới trên dữ liệu
  • Agent đưa ra đề xuất và con người lựa chọn - nếu giao cả việc đề xuất lẫn quyết định chiến lược cho agent, nó sẽ ổn định ở mức đồng thuận an toàn hoặc tối ưu kiểu leo đồi cho chỉ số dễ cải thiện nhất

• Trọng tâm của tự cải tiến ở cấp độ công ty = năng lực viết eval

  • Gán nhãn thủ công hàng trăm ví dụ thành tốt/xấu rồi tạo eval và nối vào vòng lặp tiến hóa prompt - các framework như GEPA, DSPy dùng các mô hình phản chiếu nhỏ để đề xuất biến thể prompt, eval xếp hạng trên tập dữ liệu đã gán nhãn để triển khai phương án thắng cuộc, rồi lặp lại
  • Nhà sáng lập viết eval và đọc các cụm thất bại, nhưng không dùng cũng không đọc các prompt đã tiến hóa
  • Thứ cản trở không phải là năng lực của agent mà là liệu bạn có thể mã hóa tiêu chuẩn của cái gì là tốt hay không - biết code có ích nhưng không phải nút thắt, và chuyên gia domain có thể gắn nhãn đầu ra một cách đáng tin cậy là tốt/xấu có thể vận hành toàn bộ vòng lặp
  • eval là artifact cốt lõi chịu tải, và ngay khi việc viết eval dừng lại thì tăng trưởng lãi kép của công ty cũng dừng theo

Kết luận

• Điều cần thiết không phải thiên tài hay đội ngũ lớn mà là kỷ luật để lập bản đồ công việc, tích lũy context, viết eval và chạy vòng lặp mỗi tuần - trong lúc mọi người đều dùng cùng một mô hình, hệ điều hành vận hành chính là vũ khí bí mật