Building an Autonomous Engineering Org

1. Block, goose và những người dùng coding agent đầu tiên

Angie Jones mở đầu bằng việc cô đã làm trong vài năm gần đây: biến tổ chức engineering khoảng ba nghìn rưỡi người của Block thành một tổ chức autonomous, tức là tổ chức mà agent tự làm được phần lớn công việc engineering. Theo cô, đây là bài toán mà phần lớn các công ty công nghệ đang cố giải, hoặc sẽ phải giải trong tương lai rất gần. Talk này là con đường Block đã đi để tới đó, kể theo từng chặng.

Slide tiêu đề Building an Autonomous Engineering Org, Angie Jones góc phải — Slide mở đầu: Building an Autonomous Engineering Org. Dòng nhỏ phía trên ghi Angie Jones, VP tại Agentic AI Foundation, nơi cô làm hiện nay; câu chuyện trong talk là những gì cô đã làm ở Block.

Hành trình agentic coding của Block bắt đầu rất sớm. Họ đã xây goose, coding agent nội bộ, từ trước khi các LLM hỗ trợ tool calling. Block làm việc với Anthropic với vai trò design partner cho bản phát hành đầu tiên của MCP (Model Context Protocol), và goose trở thành reference implementation cho phía MCP client. goose hiện là dự án open source, repo ở github.com/aaif-goose/goose.

Slide Early users of coding agents — "Early users of coding agents": Block là một trong những nơi dùng coding agent sớm nhất trong ngành, vì chính họ xây goose.

Nhờ vậy, trong nội bộ Block, những engineer tò mò nhất thuộc nhóm người đầu tiên trong cả ngành dùng loại coding agent này. Sau vài tháng, khoảng 90% engineer của Block đã dùng đều đặn các công cụ như goose và Claude Code để sinh code. Trên giấy tờ, Block trông như đã "all in" vào AI.

2. Dùng AI rất nhiều nhưng không ship nhanh hơn

Nhưng CEO của Block tin chắc rằng bộ phận engineering hoàn toàn không dùng AI. Kiểu như: làm sao mà họ dùng được, đúng không? Với ông, bằng chứng rất đơn giản: Block không hề ship nhanh hơn.

Angie thì có số liệu trong tay, cả metrics lẫn hoá đơn token, nên cô biết chắc engineering có dùng AI thật. Nhưng ông ấy cũng đúng. Feature rõ ràng không tới tay khách hàng nhanh hơn chút nào. Thế là cô bắt đầu đào sâu vào chuyện này.

Cô nhìn AI enablement theo ba phase: experimentation (thử nghiệm), adoption (áp dụng) và impact (tác động). Block đã vượt qua phase experimentation, vì 90% tổ chức engineering đang dùng AI. Nhưng họ vẫn chủ yếu dùng AI bên trong IDE: hỏi vài câu, hoặc viết boilerplate code. Cô biết rằng nếu muốn thấy kết quả có tác động thật, Block phải tìm cách tích hợp AI vào chính cách họ build và ship.

Slide Where We Are với ba phase Experimentation, Adoption, Impact — "Where We Are": ba phase của AI enablement. Experimentation là khám phá và bình thường hoá việc dùng AI; Adoption là mở rộng việc dùng bằng cấu trúc và sự nhất quán; Impact là tạo ra kết quả đo được và năng suất tăng thật. Thanh tiến độ cho thấy Block đang đứng giữa, ở Adoption, chưa tới Impact.

Nửa đầu năm 2025, Angie dẫn dắt AI enablement cho toàn bộ công ty: mười hai nghìn nhân viên ở mọi bộ phận, từ marketing, design, finance cho tới legal. Sau đó CTO giao cho cô nhiệm vụ xây một agentic engineering org. Cô kể lại phản ứng của mình: "Ừ, được thôi. Nhưng cái đó thực sự nghĩa là gì?" Không có playbook nào cho mấy chuyện này cả. Cô biết vậy vì cô đã đi đọc blog của mọi người, hy vọng các công ty khác đã tìm ra hết rồi, nhưng chỉ thấy toàn bài viết kể rằng ai cũng đang vừa làm vừa nghĩ ra. Nên cô cũng làm y như vậy.

3. Agentic engineering org nghĩa là gì

Nói đơn giản nhất, Angie định nghĩa agentic engineering org là một tổ chức mà engineer dùng AI agent làm phương tiện chính để tạo ra kết quả engineering.

Slide We need to be Agentic Engineers — "We need to be Agentic Engineers": mục tiêu không phải là dùng AI nhiều hơn, mà là mỗi engineer trở thành một agentic engineer, người làm việc chủ yếu thông qua agent.

Điều đó có nghĩa là engineer phải coi agent như thành viên cốt lõi trong workflow engineering của mình. Không phải dùng AI chỗ này chỗ kia để viết vài đoạn code, mà thực sự làm việc cùng agent: chia nhỏ vấn đề (decompose), giao việc (delegate), rồi review và verify những gì agent đã làm. Block muốn engineer điều phối công việc theo cách đó như cách làm việc mặc định của họ.

Slide Treat agents as core collaborators — "Treat agents as core collaborators": agent là cộng sự cốt lõi trong workflow, không phải công cụ autocomplete dùng thỉnh thoảng.

Nhưng tất nhiên, tuyệt đại đa số engineer của Block chưa ở mức đó. Để biết cần đi tới đâu, Angie dựng ra một maturity model.

4. AI Maturity Model: sáu stage

Model này đo mối quan hệ giữa engineer và AI agent: họ nghĩ thế nào, delegate thế nào, orchestrate thế nào. Angie đã có một phiên bản của model này từ Q3 năm ngoái, nhưng bài viết về Gas Town của Steve Yegge giúp cô sắp xếp lại thành một model tốt hơn.

Slide AI Maturity Model với sáu ô Stage 0 tới Stage 5 — AI Maturity Model với sáu ô từ Stage 0 tới Stage 5, ghi chú bên dưới là phỏng theo bài viết Gas Town của Steve Yegge. Ở các slide sau, mỗi ô được gắn nhãn và đánh dấu nơi Block đang đứng.

Stage 0 (Unengaged): engineer hoàn toàn không dùng công cụ AI trong workflow.
Stage 1 (Assisted): dùng AI để autocomplete, nhưng có lẽ chưa bao giờ dùng agent mode.
Stage 2 (Conversational): engineer chat với agent, nhưng không dùng agent để tạo ra PR nào.
Stage 3 (Directed): engineer delegate task cho agent và review output.
Stage 4 (Parallel): chạy nhiều agent song song.
Stage 5 (Autonomous): "final boss". Engineer delegate trọn vẹn task cho agent, và agent tạo ra kết quả có thể ship mà con người không nhất thiết phải dẫn dắt.

Sáu stage đo mối quan hệ giữa engineer và agent. Giữa năm 2025, phần lớn engineer của Block nằm giữa Stage 1 và Stage 2; nhiệm vụ của Angie là đưa họ tới Stage 5.

Theo Angie, tới cuối nửa đầu năm, phần lớn engineer của Block nằm giữa stage 1 và stage 2. Và cô cần đưa họ lên stage 5.

5. Ba trở ngại và quy tắc 1/9/90

Angie không chắc làm sao để đưa ba nghìn rưỡi engineer lên mức đó, nhất là vì ba lý do:

Mọi thứ đều cực kỳ thử nghiệm. Một lần nữa, không có playbook nào cho bất cứ chuyện gì ở đây.
Mọi thứ thay đổi quá nhanh: thứ được coi là best practice tuần này có thể lỗi thời ngay tuần sau, khi một tool mới hay một model mới ra mắt. Và thật lòng mà nói, chuyện này đang gây ra AI fatigue, sự mệt mỏi vì AI.
Mọi người đã thấy chán ngán vì áp lực từ trên xuống của ban lãnh đạo, về cơ bản là thông điệp "AI or die": dùng AI hoặc chết.

Slide How can we level up? — "How can we level up?": câu hỏi trung tâm, làm sao để cả một tổ chức lớn lên level khi không có playbook, công cụ đổi hằng tuần và mọi người đã mệt.

Cô nghĩ tới quy tắc 1-9-90 trong các cộng đồng số: khoảng 1% người tạo ra nội dung, 9% tương tác, và 90% chỉ tiêu thụ một cách thụ động (xem 1% rule). Quy tắc này khớp gần như hoàn hảo với cách engineer áp dụng AI. Sẽ có một nhóm nhỏ đào thật sâu, bắt đầu tạo ra các agentic pattern và khám phá những kỹ thuật hữu ích để làm việc với agent. Sẽ có một số người chỉnh file AGENTS.md chỗ này chỗ kia. Còn phần lớn mọi người sẽ không bỏ thêm công sức để tự tìm hiểu mấy chuyện này.

Kim tự tháp 1/9/90 Rule: Power Users, Tinkerers, Consumers — Kim tự tháp 1/9/90 áp vào engineering: 1% Power Users ở đỉnh (người tạo pattern), 9% Tinkerers ở giữa (người chỉnh sửa, thử nghiệm chút ít), 90% Consumers ở đáy (người dùng lại những gì có sẵn).

Từ đó Angie nhận ra: nếu chiến lược AI của cô phụ thuộc vào việc từng cá nhân tự nâng level cho mình, cô sẽ không bao giờ thấy được tác động trên diện rộng.

6. AI Champions: chọn đúng một phần trăm

Vì vậy cô dựa hẳn vào model 1/9/90 và biến nó thành lợi thế. Thay vì tập trung vào cả ba nghìn rưỡi engineer, cô quyết định tập trung vào việc tạo ra nhóm 1%: những power user đến từ các team quan trọng nhất. Cô lập chương trình AI Champions, tự tay chọn khoảng 50 engineer trên toàn công ty, những người có thể đi tiên phong định hình agentic engineering trông như thế nào cho team của họ.

Slide The 1%: AI Champions, ghi chú actually ~1.43% — "The 1%: AI Champions". Dòng chú thích nhỏ ở góc slide nói thật ra là khoảng 1,43%: 50 người trên khoảng 3.500 engineer.

Đây không phải lời kêu gọi tình nguyện. Cô phải chọn một cách có chiến lược. Cô cần những engineer sẵn sàng dành ít nhất 30% thời gian để đầu tư vào AI enablement. Cô cần những người không nản vì tính non-deterministic của AI và không bỏ cuộc khi nó không chạy ngay từ đầu, điều mà, theo lời cô, xảy ra rất thường xuyên. Angie dành một tuần để nói chuyện với các tech lead và manager, tìm ra 50 engineer có thể đại diện cho những repository quan trọng nhất của Block.

Nhớ rằng lúc này phần lớn engineer đang ở giữa stage 1 và stage 2: chat với AI nhưng chưa thật sự dùng nó để tạo PR. Nên mục tiêu đầu tiên là đưa nhóm AI Champions lên stage 3.

AI Maturity Model, Stage 0 mờ đi, dấu tích giữa Stage 1 và Stage 2 — Maturity model với nhãn đầy đủ: Unengaged, Assisted, Conversational, Directed, Parallel, Autonomous. Stage 0 đã mờ đi, dấu tích xanh nằm giữa Stage 1 và Stage 2, đúng vị trí của phần lớn engineer lúc đó.

Thời điểm đó là khoảng tháng 6/2025. Các model đã đủ tốt để viết một feature cho bạn. Nhưng khả năng rất cao là code đó không tuân theo convention và standard của team bạn. Nên developer chưa đủ tin agent để giao việc cho nó.

7. Biến repo thành hệ thống AI-friendly

Vì thế, mảng đầu tiên Block tập trung là làm cho repo AI-ready. Giả thuyết của Angie: nếu engineer nhúng AI trực tiếp vào repo của họ, không chỉ agent làm việc tốt hơn mà cả team đều được hưởng lợi, không riêng nhóm 1%. Repo là điểm tham chiếu trung tâm của mọi engineer đang đóng góp code. Để repo thân thiện với AI, các champion thêm vào những asset như context file và rules file, để agent có thể hiểu và di chuyển trong codebase một cách đáng tin cậy, cũng như đóng góp code vào đó.

Slide Turning repos into AI-friendly systems — "Turning repos into AI-friendly systems": đầu tư vào repo thay vì vào từng cá nhân, vì mọi engineer và mọi agent đều đi qua repo.

Khi lập nhóm AI Champions, Angie đảm bảo có người từ mọi góc của Block engineering: Square, Cash App, Afterpay, TIDAL; trải đều front end, back end, mobile, data, infra. Họ phủ đủ loại repo, đủ hình dạng và kích thước: những monorepo legacy khổng lồ và "khó chịu", các service nhỏ hơn, các mobile app. Sự pha trộn đó giúp Block pressure test các pattern trên những thực tế engineering rất khác nhau, để nhanh chóng thấy cái gì thực sự scale được.

Slide Not all codebases are equal — "Not all codebases are equal": monorepo, service nhỏ, web và mobile mỗi nơi cần một cách làm khác nhau.

Như dự đoán, monorepo có những thách thức riêng. Nhưng các dev JVM của Block vốn đã quen với pattern kế thừa (inheritance), nên họ đặt context và rules dùng chung ở root, rồi xếp lớp thêm những context, rules cụ thể hơn ở cấp từng service. Họ cũng nhanh chóng học được rằng cái chạy tốt cho web chưa chắc chạy tốt cho mobile. Thậm chí Android và iOS có lúc cũng cần cách tiếp cận khác nhau.

Cách các dev JVM xử lý monorepo: context và rules chung đặt ở root, các file cụ thể hơn xếp lớp ở từng service, giống cách kế thừa trong code.

Nên thay vì ép một giải pháp "one size fits all", mỗi champion tự tìm ra cái chạy được cho repo của mình. Sau đó các team có repo cùng hình dạng, cùng kích thước tự nhiên hội tụ về cùng tool và pattern. Và thật lòng mà nói, engineer rất thích chuyện này: Block để họ chọn thứ hợp lý cho repo của mình thay vì áp một mệnh lệnh từ trên xuống.

8. Bộ thành phần của một AI-friendly repo

Cuối cùng Block có một bộ thành phần chuẩn để làm một repo trở nên AI-friendly, nhưng một lần nữa, được tuỳ biến theo nhu cầu của từng team:

Agent Context: các context file như AGENTS.md hay CLAUDE.md để hướng dẫn agent về repo.
Agent Rules: rules file để đặt guardrail cho agent.
AI Workflows: các workflow lặp lại được, như slash command, và về sau là agent skill.
AI Code Review: bật một AI code reviewer, tốt nhất là kèm hướng dẫn về điều gì quan trọng và nó nên review cái gì.
AI attribution trên PR: ghi rõ phần nào do AI tạo ra.

Slide AI Friendly Repo với bốn thành phần đã bật: Agent Context, Agent Rules, AI Workflows, AI Code Review — "AI Friendly Repo" khi bốn thành phần đầu đã sáng lên: Agent Context, Agent Rules, AI Workflows, AI Code Review. Icon robot cuối cùng là AI attribution trên PR.

Tới lúc này, Block đã làm được rất nhiều việc tốt, và về mặt kỹ thuật, agent đã viết PR thật. Nhưng Angie còn vài mối lo. Thứ nhất, ngoài nhóm AI Champions, chưa nhiều người lên tới mức delegate việc cho agent. Ý tưởng ban đầu là công sức của nhóm 1% sẽ nâng mọi người lên, mà điều đó chưa xảy ra. Thứ hai, ngay cả các champion, dù đã delegate, vẫn đang kiểu "trông trẻ" (babysitting) cho cả quá trình.

AI Maturity Model với dấu tích vàng ở Stage 3 Directed — Maturity model lúc này: Stage 0 tới 2 mờ đi, dấu tích vàng (chưa phải xanh) ở Stage 3 Directed. Agent đã viết PR, nhưng chỉ nhóm champion làm được, và vẫn phải kè kè bên cạnh.

Nên cô muốn thử xem có thể giao việc cho agent theo cách "hands-off" hơn không, và làm cho việc đó dễ dàng hơn với cả những người nằm ngoài chương trình champions.

9. Delegate from anywhere: câu chuyện trong Slack

Có ba nơi phổ biến mà engineer nhận yêu cầu công việc: issue tracker như Jira hay Linear, GitHub issues, và một cách không chính thức, trong Slack. Angie muốn có thể giao việc cho agent từ bất kỳ nơi nào trong ba nơi đó, và nhóm champion đã làm được cả ba.

Slide Delegate from anywhere — "Delegate from anywhere": giao việc cho agent ngay tại chỗ yêu cầu xuất hiện, dù là ticket, GitHub issue hay một tin nhắn Slack.

Cô kể một chuyện có thật. Một hôm, mọi người đang trong Slack. Một engineer thấy một bug của sản phẩm và viết kiểu: "Ê, tôi thấy bug này. Có ai thấy chưa?" Engineer thứ hai trả lời: "Ừm, không, tôi chưa thấy cái đó." Engineer thứ ba tag goose ngay trong Slack: "Này goose, bạn thấy bug này bao giờ chưa? Kiểu, bạn đi kiểm tra xem đây có phải bug không?"

goose đi vào repo, kéo các file về, rồi trả lời: "Đúng, đây là bug. Nó nằm ngay đây. Nhưng đây cũng là ba phương án bạn có thể dùng để sửa." Tất cả ngay trong Slack, kèm code snippet. Engineer một nói: "Tôi thích phương án một." Engineer hai: "Ừ ừ, tôi cũng vậy." Engineer ba bảo: "goose, đi implement phương án một đi." goose làm, rồi quay lại với link tới PR.

Toàn bộ vòng đời của một bug, từ lúc ai đó nhắc tới cho tới lúc có PR sửa, diễn ra trong một thread Slack với goose làm phần việc kỹ thuật.

Cả chu trình, từ thảo luận, chẩn đoán, tạo issue, thống nhất cho tới bản sửa, chỉ mất khoảng năm phút, tất cả ngay trong Slack. Angie gọi đây là một "party trick" rất ngầu.

10. Agent vào sprint và con số sau ba tháng

Engineer cũng có thể assign ticket Linear, Jira và GitHub issue cho một agent, để agent implement công việc end to end. Vậy là agent đã trở thành một phần của sprint. Chuyện này làm mọi người choáng váng. Lần đầu làm vậy, team hết việc và phải kéo thêm ticket vào sprint, tới hai lần. Tất nhiên engineering manager và các team product rất thích flow này.

Cái hay của các flow này là không phải engineer nào cũng phải học một kỹ năng mới. Nhóm champion đã đặt nền móng để agent làm việc tốt trong các repo, và chúng làm việc tốt thật. Mọi thứ chạy được vì nó làm cho việc delegate trở nên tự nhiên với cách mọi người vốn đã làm việc: viết ticket, mở issue, nhắn Slack. Tới lúc này Angie mới thấy thoải mái để nói rằng Block thực sự đang delegate công việc cho agent.

Lúc đó đã ba tháng kể từ khi ra mắt chương trình champions, và kết quả rất tốt:

Ba con số: 69% AI-authored code, 37% reported time savings, 21x automated PRs — Kết quả sau ba tháng chương trình AI Champions: code do AI viết tăng 69%, thời gian tiết kiệm được (theo tự báo cáo) tăng 37%, và số PR tự động tăng 21 lần.

Code do AI viết (AI-authored code) tăng 69%.
Thời gian tiết kiệm được theo tự báo cáo (reported time savings) tăng 37%.
Số PR tự động (automated PRs) tăng 21 lần.

AI Maturity Model với dấu tích xanh ở Stage 3 Directed — Dấu tích ở Stage 3 Directed giờ chuyển sang xanh: việc delegate cho agent đã thành thật và lan ra ngoài nhóm champion. Bước tiếp theo là Stage 4 Parallel.

Block đã sẵn sàng theo đuổi stage 4: multi-agent parallelism. Với setup đã có, theo Angie, lên stage 4 gần như miễn phí. Lúc này Block đã khá giỏi việc delegate cho agent.

11. Parallelism và nút thắt code review

Nhưng stage này mang tới vài thách thức mới cần giải.

Slide Parallelism introduced challenges — "Parallelism introduced challenges": chạy nhiều agent cùng lúc không miễn phí, nó đẩy áp lực sang những chỗ khác trong hệ thống.

Engineer giờ tạo ra gấp ba, gấp bốn số PR so với trước, nhưng PR bị kẹt, chờ code review. Ngay cả trước khi có AI, mọi người đã vật vã để theo kịp code review rồi. Nên bạn biết là giờ nó tệ cỡ nào. Angie thừa nhận thẳng: đây chưa phải bài toán đã giải xong hoàn toàn, nhưng cô chia sẻ cách Block đã cầm được máu phần nào.

Slide Who is going to review all of this? — "Who is going to review all of this?": khi số PR tăng gấp ba, gấp bốn, review trở thành nút thắt mới.

Block bắt buộc phải để bot giúp review PR. Giai đoạn trước, việc này là tuỳ chọn, chủ yếu vì các AI code reviewer khi đó dở tệ, và bắt engineer dùng chúng chỉ làm họ bực mình. Nhưng giờ, nhờ phần việc làm repo AI-ready mà nhóm champion đã làm, cộng với model và tool tốt hơn (Angie gửi lời "shout out" tới Codex), kết quả đã tốt hơn rất nhiều.

Slide Handle AI overload with more AI — "Handle AI overload with more AI": dùng thêm AI để xử lý lượng việc mà AI tạo ra, cụ thể là AI review cộng với một vòng autofix.

Block bật Codex trên tất cả các repo, và tạo thêm một autofix loop: nếu Codex phát hiện vấn đề, một agent khác sẽ tự động sửa các vấn đề đó và commit vào chính PR. Nhờ vậy, ít nhất mọi người không còn than phiền là không muốn review những PR cẩu thả của bot nữa. Tới lúc người thật mở PR ra, nó đã ở trạng thái khá ổn.

Autofix loop của Block: Codex review, một agent khác tự sửa và commit thẳng vào PR, lặp lại cho tới khi sạch. Con người chỉ nhận những PR đã ở trạng thái khá tốt.

12. Máy laptop không chịu nổi, cloud workspace và Builder Bot

Một vấn đề khác, đặc biệt khi chạy nhiều agent song song, là các agent va vào nhau khi đang cố làm việc. Và quan trọng hơn, máy của engineer không còn chịu nổi tải nữa. Laptop của engineer hết memory, CPU nghẹt thở.

Slide We've outgrown the machines — "We've outgrown the machines": laptop cá nhân không còn đủ cho bốn, năm agent chạy cùng lúc.

Block đầu tư vào cloud workspace chuyên dụng, nơi mỗi agent chạy trong một môi trường riêng, cô lập. Nhờ vậy, Block dễ dàng chạy chúng song song, và chạy từ bất cứ đâu.

Tới lúc này, theo lời Angie, engineer "đang nấu" (cooking): mỗi người có bốn, năm agent chạy cùng lúc, và con số đó còn đang tăng. Một nhóm nhỏ engineer, trong đó có nhiều AI Champion, bắt đầu xây orchestrator riêng để điều phối tất cả các agent này: Builder Bot. Và Block cần Builder Bot để đi tới một autonomous engineering org.

AI Maturity Model với dấu tích xanh ở Stage 4 Parallel — Dấu tích xanh chuyển sang Stage 4 Parallel: chạy nhiều agent song song đã thành cách làm bình thường, nhờ AI review, autofix loop và cloud workspace.

13. World model của cả công ty

Block nhận ra rằng nếu muốn xây bất cứ thứ gì gần với một autonomous engineering org, agent cần hiểu mọi thứ nằm ở đâu và cái gì phụ thuộc vào cái gì. Nên họ xây một company world model dựa trên toàn bộ codebase gồm 25.000 repo. Đây là một góc nhìn mà máy đọc được (machine-readable) về từng service một và cách tất cả chúng kết nối với nhau.

Slide Providing the agents with a world model — "Providing the agents with a world model": cho agent một bản đồ của cả công ty thay vì để mỗi agent tự mò từ đầu trong từng repo.

World model này cho phép các orchestrator, và các agent mà orchestrator delegate việc cho, kéo context vào khi cần và hiểu toàn cảnh trong lúc implement. Nó cũng cho phép nhiều agent khám phá các phần khác nhau của hệ thống song song, mỗi agent xây hiểu biết riêng, rồi quay lại để orchestrator ghép tất cả lại, đưa ra một plan trải trên nhiều codebase. Điều này đặc biệt hữu ích với Block khi họ đang xây những sản phẩm trải trên nhiều product cùng lúc.

Orchestrator chia việc cho nhiều agent; mỗi agent kéo context từ world model khi cần để hiểu phần hệ thống của mình, rồi orchestrator ghép các hiểu biết đó thành một plan trải trên nhiều codebase.

14. Stage 5, rồi giấc mơ thành ác mộng

Với world model, Block đã chạm tới stage 5: engineer delegate trọn vẹn task cho agent, và agent tạo ra kết quả có thể ship mà không cần con người cầm tay chỉ việc. Thậm chí việc này không còn giới hạn ở engineer nữa. Bất kỳ ai trong công ty cũng có thể tag Builder Bot trong Slack để nó sửa một bug hay implement một feature mới. Họ thậm chí không cần đến GitHub.

AI Maturity Model với dấu tích xanh ở Stage 5 Autonomous — Dấu tích xanh cuối cùng ở Stage 5 Autonomous: mục tiêu ban đầu đã đạt.

Mọi thứ giống như một giấc mơ, cho tới khi nó trở thành ác mộng.

Bài báo CNN Business: Block lays off nearly half its staff because of AI — Bài báo trên CNN Business, cập nhật ngày 26/2/2026: "Block lays off nearly half its staff because of AI. Its CEO said most companies will do the same". Block cắt giảm gần một nửa nhân sự vì AI, và CEO nói phần lớn các công ty sẽ làm điều tương tự.

Angie nói: tất nhiên đợt layoff nào cũng khó khăn, nhưng đợt này thì khác. Cô có rất nhiều câu hỏi. Đây có phải lỗi của mình không? Việc giúp nhân viên làm được những công việc tuyệt vời nhất trong sự nghiệp của họ, rốt cuộc lại dẫn tới việc họ bị cho nghỉ sao?

Chỉ một ngày trước đó, cô còn thấy rất tự hào. Cô kinh ngạc trước cách cả tổ chức đang làm việc, thấy mình đã đạt được điều lớn lao khi xây thành công một autonomous engineering org. Nhưng để làm gì?

15. Những câu hỏi để lại

Angie không kết thúc bằng một bài học hay một checklist. Cô để lại cho khán giả vài câu hỏi:

Chúng ta đang làm gì?
Chúng ta đang đi về đâu?
Và chúng ta có chắc đó là nơi mình muốn tới không?

Nhìn lại cả hành trình: từ 90% engineer dùng AI mà không ship nhanh hơn, tới AI Champions, AI-friendly repo, delegate from anywhere, autofix loop, cloud workspace, Builder Bot và world model, mỗi bước là một chặng kỹ thuật. Còn điểm dừng của câu chuyện là một câu hỏi về con người: khi tổ chức engineering đã thật sự autonomous, những engineer đã xây nên nó sẽ đứng ở đâu.