State of the Software Factory

1. Mở đầu: ai đang để AI viết 99% code, và Dex là ai

Dex mở màn bằng mấy câu hỏi giơ tay với khán giả. Ai đang viết 99% code bằng AI, gần như từng dòng một? Rất nhiều tay giơ lên. Rồi anh hỏi tiếp: trong số những người viết phần lớn code bằng AI, có ai vẫn cố gắng đọc phần lớn code đó không, có thể không phải tất cả nhưng là một lượng đáng kể? Gần như không ai. "Okay." Anh hỏi thêm ai là người dùng Claude Code, rồi ai dùng Codex, và tự trả lời rằng tới lúc này chắc ai cũng dùng cả hai.

Rồi anh vào đề. Talk này ban đầu định đặt tên là "There's no Dark Factory without better Verifiers", nghĩa là không có "nhà máy tắt đèn" nếu không có verifier tốt hơn. Nhưng tên đó hơi dài dòng, nên đổi thành "State of the Software Factory": cái gì đang chạy tốt, chuyện gì đang diễn ra, cái gì mới, và cái gì vẫn còn hỏng, "không may, hoặc may mắn, tuỳ bạn là ai".

Phần anh ghét nhất trong talk là tự giới thiệu, vì anh chỉ muốn dạy mọi người thứ gì đó. Anh đã làm rất nhiều video trên YouTube về coding agent, tổng cộng chắc đã hơn một triệu rưỡi lượt xem. Anh sẽ đưa link lên sau: mọi thứ HumanLayer từng viết và nói về coding agent đều nằm ở đó. Quan điểm của họ thay đổi một chút mỗi khi model thay đổi, nên người đọc có thể theo dõi cả dòng thời gian.

Trang hlyr.dev/resources của HumanLayer — Trang hlyr.dev/resources: "HumanLayer, All Resources". Trang gom mọi bài viết, video và talk theo từng giai đoạn: Aug 2026 tới nay "The future of software factories must be open and composable"; May tới July 2026 "Software Factories: Design Patterns and Failure Modes" (có "Why Software Factories Fail"); February tới May 2026 "From RPI to QRSPI, and the crusade against slop"; October tới January "No Vibes Allowed"; cho tới April 2025 "12-Factor Agents and the Birth of Context Engineering". Góc trên liệt kê số liệu: khoảng 1.9M lượt xem YouTube cộng dồn và nhiều bài lên front page Hacker News.

Anh là Dex, CEO và co-founder của công ty HumanLayer. Công ty tồn tại vì họ muốn giúp mọi người giỏi agentic coding. Họ đang xây các building block cho software factory của tương lai: chuyện gì đến sau khi tất cả chúng ta code trên workstation của mình. Họ tập trung vào việc giải hard problems trong complex codebases.

2. Hard problems in complex codebases, và hai phía của cơn hype

Slide Hard Problems in Complex Codebases, 100+ Engineers — Slide "Hard Problems in Complex Codebases, 100+ Engineers": bối cảnh mà HumanLayer nhắm tới là tổ chức có hơn trăm engineer và hàng trăm repo, không phải solo builder.

"Hard problems in complex codebases" thường nghĩa là hàng trăm engineer, hàng trăm repo. Dex nói nếu bạn là solo builder, trải nghiệm của bạn với coding agent sẽ rất khác so với việc cố nối Claude Code hay Codex vào một codebase lớn hơn, kiểu enterprise hơn.

Một trong các luận điểm của họ là: làm một automation từ ticket tới PR không hề tầm thường, nhưng ai cũng làm được. Rất nhiều người đang tập trung vào chuyện "ta cần một hàng đợi việc, việc đi vào một agent, agent build, và một PR đi ra ở đầu kia". Nhưng Dex tò mò hơn về câu hỏi khác: làm sao ta cộng tác một cách có ý nghĩa trên những việc lớn, những thứ không thể để agent one-shot rồi đẩy qua.

Slide Anyone can build a ticket-to-pr automation for the small stuff, how do we collaborate meaningfully on the big stuff — Slide hai vế: "Anyone can build a **ticket-to-pr automation** for the small stuff... ...how do we collaborate **meaningfully** on the big stuff?" Việc nhỏ thì automation lo được; câu hỏi thật là việc lớn.

Tất cả chúng ta đều đang cố tìm cách đưa AI coding vào production, và có rất nhiều noise và hype phải lọc qua. Ví dụ, mùa hè vừa rồi có cả phong trào "loops engineering": đừng prompt agent nữa, cứ viết loop đi, giờ ta chỉ làm loop thôi.

Nhưng ở phía bên kia có một báo cáo khác. Họ xem dữ liệu của nhiều engineer đã dùng Claude Code từ khoảng tháng Một, tháng Hai năm nay, tức là sau Opus 4.5, và thấy: code review đang dài hơn, nhiều comment hơn, comment dài hơn. Rất nhiều PR thật ra bỏ qua review hoàn toàn. Và số incident trên mỗi PR tăng mạnh, số bug trên mỗi PR cũng tăng mạnh. Có người sẽ nói đây là "skill issue", tức là bạn tự tìm ra cách giải được. Dex nghĩ dữ liệu nói điều ngược lại, xét theo năng lực hiện tại và năng lực có thể có trong tương lai của các model. Và anh còn dữ liệu khác nữa.

3. Software factory trước AI: từ NATO 1968 tới sơ đồ năm 2022

Trước hết anh muốn định nghĩa software factory. Anh hỏi có ai đang làm cái mà họ gọi là software factory không; vài người giơ tay kiểu "một chút". Software factory nghe như một khái niệm AI mới, nhưng thật ra đó là một từ đã có từ lâu.

Slide Software factory was defined at a NATO conference in 1968, but we're gonna start around 2022 — "Software factory was defined at a NATO conference in 1968", và dòng thứ hai: "but we're gonna start around 2022". Đó cũng là hội nghị gắn với sự ra đời của thuật ngữ software engineering (xem NATO Software Engineering Conferences).

Nó được định nghĩa tại một hội nghị NATO năm 1968, cùng năm có người đưa ra thuật ngữ software engineer. Nhưng Dex tua nhanh tới khoảng năm 2022, ngay trước AI: software factory lúc đó trông ra sao, và những thứ gì không đổi khi có AI?

Bạn có engineer, có product manager, có người dẫn dắt project hay team, có người mang tầm nhìn, có thể là CEO. Họ nghĩ ra việc cần làm: thứ muốn build, vấn đề muốn giải. Việc đó vào issue tracker. Trước AI, bước tiếp theo là ai đó kéo việc về, build nó, chạy automated testing, có thể làm manual testing, chọc thử trong browser hay dùng curl.

Sơ đồ A Software Factory Circa 2022, bản đầu với Loop #1 — "A Software Factory Circa 2022", bản đầu. CEO / Vision, Product Managers, Engineers tạo ra "stuff to do" (Linear, Jira, issue tracker, state machine). "Someone builds the thing" kèm automated testing và manual testing (ví dụ browser). Rồi tới Pull request với ci/cd checks, unit testing, static scanning, security checks, human tests the change, human reviews the change. Mũi tên LOOP #1 quay từ Pull request về người build khi có gì sai. Qua PR là rollout / deployment lên PROD tới USERS.

Khi sẵn sàng, bạn mở pull request và chạy cả loạt check trên nó: security check, scanning, v.v. Rồi một người review code, và có khi còn có người kéo về test thử. Nếu có gì sai, việc quay lại người đang build (đó là vòng lặp thứ nhất). Khi ổn, nó lên prod. Nếu software factory của bạn tinh vi, bạn có canary, rollout, staging environment, và đưa thay đổi tới user một cách an toàn. Tới lúc đó user làm việc mà user thích làm: gửi feature request và phàn nàn về chỗ hỏng. "Tôi yêu user của chúng tôi, nhưng họ đúng là thích làm vậy."

Sơ đồ software factory 2022 thêm complaints, feature requests và MONITORING — Bản thứ hai của sơ đồ: từ USERS có nhánh "complaints / feature requests" quay về phía CEO, PM, Engineers; PROD nối thêm khối MONITORING.

Thứ nữa ta muốn có là một hệ thống production monitoring, "vì ta thích đánh thức engineer lúc 3 giờ sáng khi có gì hỏng". Nếu bạn là người cầm pager thì phần đó rất tệ. Nhưng nhìn chung, bị pager đánh thức vẫn tốt hơn là bị khách hàng gọi điện giận dữ.

Sơ đồ software factory 2022 đầy đủ với incidents và LOOP #2 — Bản đầy đủ: MONITORING sinh ra "incidents" quay về Engineers, và mũi tên LOOP #2 đi từ USERS về tận CEO / Vision. Hai vòng lặp: vòng nhỏ giữa build và review, vòng lớn giữa sản phẩm ngoài đời và những người quyết định làm gì tiếp.

4. The agentic software factory: build nhanh, review vẫn là bottleneck

Điều đó dẫn tới cái Dex gọi là agentic software factory. Chuyện gì đã thay đổi với AI coding? Ai cũng có một cái automation ticket-to-PR, và họ không ngừng nói về nó; ai cũng có một cái, ai cũng rất tự hào về nó.

Ta lấy software factory trước AI, và về cơ bản người build thứ đó trở thành một agent build thứ đó. Vậy là ta có orchestration, harness, sandbox, model và mọi thứ khác. Anh không đi sâu vào đó, nhưng đó là phần chính.

Sơ đồ The Agentic Software Factory với orchestration, harness, sandbox, model và agentic code review — "THE AGENTIC SOFTWARE FACTORY": khối "someone builds the thing" được thay bằng "agent builds the thing", gồm bốn lớp orchestration, harness, sandbox, model, kèm automated testing và agentic testing (ví dụ computer use). Ở phía PR xuất hiện thêm khung "agentic code review" và "agentic regression testing" bên cạnh ci/cd checks; nhưng "human tests the change" và "human reviews the change" vẫn còn nguyên.

Điều bạn nhận ra rất nhanh: phần build giờ chỉ mất vài phút hay vài giờ, nhưng phần testing và review vẫn mất hàng giờ hay hàng ngày. Nên ta đưa vào agentic code review, agentic testing và vài thứ khác, với hy vọng phần đó nhanh hơn và bắt được những lỗi dễ bắt. Nó nhanh hơn thật, nhưng nó vẫn là bottleneck.

Dex hỏi ai đang dùng một code review agent trong production pipeline, trong "factory" của mình. Nhiều tay giơ lên. "Okay, cool. Các bạn đều đang xây software factory mà không biết đấy." Những mảnh nhỏ cứ chồng lên nhau theo thời gian.

5. Lights-off software factory, và vì sao hôm nay nó chưa chạy

Từ đó người ta đi tới cái gọi là lights-off software factory (nhà máy tắt đèn). Lập luận là: được rồi, ta đã có đủ AI trong cỗ máy này. Cái khâu review thì tệ. Đó là phần tệ nhất trong công việc của tôi: đọc slop code của người khác. Vậy nếu ta thôi đọc nó thì sao? Nếu ta cứ để model "nấu", và dồn đầu tư vào mọi phần còn lại của factory để chất lượng đủ cao, đủ để ta vẫn maintain được hệ thống? Khi đó công việc của bạn chỉ còn là: bạn nghĩ ra được gì để nhờ AI làm.

Bỏ khâu người đọc code, dồn lực vào các khâu còn lại. Dex cho rằng giả định này chưa đúng với model hiện nay.

Đó là một tầm nhìn rất tương lai. Dex không nghĩ hôm nay nó chạy được, và anh giải thích vì sao. Thách thức chính là: khi để model chạy không giám sát, tức là bạn không lái nó ở mức code, model không thể giữ hay cải thiện chất lượng codebase theo thời gian.

Model đã trở nên cực giỏi trong việc giải bài toán một lần. Astra làm được các demo Blender, model giỏi lên rất nhiều trong việc hack vào hệ thống và những thứ tương tự. Nhưng kỹ năng cụ thể là cải thiện chất lượng một codebase và giữ nó maintainable thì không khá lên bao nhiêu. Có một benchmark đi thẳng vào chuyện này, anh sẽ nói ngay. Nhưng nếu bạn đã làm việc với coding agent một thời gian, chắc bạn cũng có cảm giác có rất nhiều slop lọt vào. Khán giả đồng thanh "yes". "Okay, great."

6. Maintainability không có oracle, và SlopCodeBench

Hồi tháng Sáu Dex có một talk ở AI Engineer World's Fair ("Why Software Factories Fail"), đi vào phía trực giác và cảm nhận của chuyện này: benchmark trông thế nào, RL training trông thế nào. Kết luận là: bạn không biết một đoạn code là slop cho tới vài tuần, vài tháng, có khi vài năm sau, khi bạn đang ngồi giữa một đống spaghetti cố sửa nó. Bạn không biết nó không maintainable cho tới khi bạn thử maintain nó.

Để làm reinforcement learning cho model giỏi, chẳng hạn, việc maintain một codebase, bạn cần một oracle: một verifier nhìn vào một khối code và nói "cái này maintainable". Và maintainability không có oracle nào như vậy. Tới lúc bạn nhận ra thứ gì đó unmaintainable thì nó đã nằm trong codebase rồi, đã quá muộn, bạn phải sửa nó. Đây chính là lý do của cái tên ban đầu: không có dark factory nếu không có verifier tốt hơn.

Slide SlopCodeBench: Initial Spec, Spec 2, Spec 3+, chất lượng giảm dần tới Unmaintainable — Cách SlopCodeBench hoạt động. "Initial Spec: Basic Python code search" cho ra Solution 1, Good Quality (main.py, rules.py). "Update Requirements" thành "Spec 2: Add JavaScript & C++ support", agent sửa tiếp trên code của chính nó: main.py +100, rules.py +60, Solution 2, "Degradation Begins". "Further Updates" tới "Spec 3+: More Features": main.py +260, rules.py +150, Solution N, "Unmaintainable".

Có một benchmark chứng minh điều đó, tên là SlopCodeBench, từ một lab ở University of Wisconsin. Về cơ bản họ xây một benchmark trong đó các feature cần build được hé lộ dần cho model. Bạn không nói hết mọi thứ từ đầu; nó không phải kiểu "clone toàn bộ Redis trong một lượt". Model cứ thừa kế codebase của chính nó. Các thử thách xoay quanh: model có biết gom abstraction về một chỗ không, có dám xoá code tồi không, có tìm được đúng layer không, và có giữ codebase ở trạng thái làm việc được không.

Điều thú vị nhất về benchmark này là nó còn rất chưa bão hoà (unsaturated). Khi họ chạy GPT-5.5 hồi tháng Năm, nó được 14.8%. Dex hứa sẽ đưa số của Astra ngay sau, "và chúng không tốt hơn bao nhiêu".

Biểu đồ which slop metrics actually separate the models — Biểu đồ "which slop metrics actually separate the models": thay đổi từ checkpoint 3 tới checkpoint 8 trên bộ `circuit_eval`, chỉ tính rate metrics. Round two gồm GPT-5.6 Sol, Fable 5 và Kimi K3 (hai lần chạy); prior run gồm Opus 5, Opus 4.8, Sonnet 5 (chỉ để tham khảo, không phải đối chứng). Các metric như `cc_max` (cyclomatic complexity lớn nhất) tăng tới hơn +400% ở một model, `cloned_pct` (tỉ lệ code bị nhân bản) tăng hơn +100%; các dòng còn lại như `mean_func_loc`, `lines_per_symbol`, `max_nesting_depth` dao động quanh 0%. Chú thích dưới: checkpoint 3 là điểm đầu tiên cả bốn lần chạy round two đều có clone rate khác 0, nên mọi thay đổi tương đối đều hữu hạn.

Anh có cả loạt biểu đồ và sẽ link tới bài viết của HumanLayer về paper này và phần nghiên cứu họ tự làm (Benchmarking Opus 5 on SlopCodeBench). Có nhiều metric thú vị về cách họ đo độ "sloppy" của code được sinh ra, qua khoảng 200 detector khác nhau, và về chuyện độ phức tạp của codebase cứ đi lên theo thời gian, tệ dần, tệ dần.

7. Chính các lab cũng thừa nhận, và "slop grenades"

Các lab thậm chí đã thừa nhận chuyện này. Dex nhắc tới một bài viết về safety alignment của Anthropic, đại ý: "à, chúng tôi đã gặp vấn đề này, và nguyên nhân là một đống code lộn xộn tích tụ theo thời gian". Họ nói về khoảng tháng Tư, tháng Năm, tức là họ đang dùng các model hạng Mythos mà vẫn gặp vấn đề đó. Và một researcher đã đáp lại: giá mà có một benchmark chứng minh được chuyện này, hay ít nhất đo được nó.

Cả Astra lẫn Fable cũng vậy. Kết luận chung của nhiều người thông minh, dành rất nhiều thời gian với coding agent, là: model giỏi lên ở những thứ ngẫu nhiên như làm video, làm demo Blender, nhưng không tiến bộ bao nhiêu ở một số chiều nhất định của coding task.

Bạn của Dex là Ian, người đã bán startup coding agent của mình cho Expo, nói rằng ta cần tạo ra các RL task khiến model giỏi abstraction, giỏi gom logic về một chỗ và giỏi thiết kế chương trình.

Ngay cả Tobi Lütke (Shopify) cũng đã đi tới điểm này. Hồi tháng Tư ông còn rất kiểu "ta cần dùng AI nhiều hơn". Giờ, theo Dex, ông đã quay lại hoàn toàn. Ông rất chín chắn về chuyện này, và đã nhận ra: nếu bạn chỉ bảo mọi người dùng AI nhiều hơn, bạn thật ra tạo thêm việc cho tất cả, vì người ta tắt não đi và thích ném cái ông gọi là "slop grenades" (bài trên Fortune): output AI gửi cho người khác mà mình chưa đọc. Dex khen đây là một thuật ngữ tuyệt vời và anh sẽ dùng nó.

8. Steve Yegge, Gas Town, và lời khuyên: hãy tiếp tục đọc code

Dex hỏi có ai nhớ Steve Yegge nổi tiếng vì gì không. Khán giả đoán lung tung ("Phoenix"), rồi có người nói đúng: Gas Town. Dex nói anh quý Steve: rất thông minh, "bộ não to bằng một hành tinh", các dự đoán của ông là huyền thoại, khả năng nhìn thấy tương lai rất giỏi. Nhưng lần này anh sẽ "đá xoáy" ông một chút.

Steve đã đi khắp Internet nói với bất kỳ ai chịu nghe rằng: nếu bạn vẫn còn cố đọc code, bạn thật ngốc, bạn sẽ không trụ được, bạn phải thôi làm vậy. Rồi mới khoảng chưa tới hai tuần trước, Steve thừa nhận rằng ông đã thôi đọc code, và ngay cả một model như Fable 5, qua vài tháng, đã tạo ra một hệ thống phức tạp tới mức chính Fable 5 cũng không maintain nổi, và ông hy vọng Fable 5.1 sẽ sửa được. Dex chưa nghe cập nhật; có khi hôm nay anh sẽ ping vào tweet của ông hỏi "thế kết quả sao rồi?".

Hai con số SlopCodeBench Dex đưa ra: 14.8% hồi tháng Năm và 16.3% với các model mới nhất ở mức xhigh. Model có giỏi lên trong việc maintain code theo thời gian, nhưng chậm hơn nhiều so với điều các lab muốn ta tin.

Họ đã chạy Sol xhigh và Astra xhigh, và số cho Fable cũng sắp có. Số SlopCodeBench là 16.3%. Vậy là khả năng maintain code theo thời gian của model có tốt lên, nhưng không nhanh như những người đang build model muốn bạn nghĩ. Một phẩy năm điểm phần trăm trong sáu tháng. "Tôi không biết, có thể nó sẽ tăng tốc, để xem."

Nhưng thông điệp là: nếu code của model không được giám sát sẽ tệ đi theo thời gian, thì "làm ơn, tôi xin các bạn", có lẽ bạn nên tiếp tục đọc code. Đặc biệt nếu bạn làm production system, nếu bạn làm hard problems trong complex codebases, nếu bạn ở financial services, healthcare, hay bất kỳ ngành nào mà ai đó sẽ bị page lúc 3 giờ sáng khi hệ thống hỏng, hoặc có thể bị phạt hàng triệu đô nếu sai.

9. "12 factor factories" (tạm gọi): plan before you build

Từ đó Dex đi tới thứ anh tạm gọi là "12 factor factories" (nối tiếp tinh thần 12-Factor Agents của HumanLayer). Anh không chắc đó sẽ là tên chính thức; co-founder của anh bảo không được đặt tên như vậy. Và anh cũng không chắc có đúng 12 cái, chắc là "khoảng 12". Đây là các practice tốt để xây software factory của bạn.

Cái hiển nhiên nhất mà rất nhiều người đã tìm ra là: plan before you build. Có nhiều lý do để lập plan. Lý do lớn nhất: nếu bạn bỏ 30 phút ở đầu, bạn có thể tiết kiệm hàng giờ ở khâu review.

Sơ đồ software factory 2022 thêm vòng planning: architecture proposal, sprint planning — "architecture proposal" và "sprint planning". Dưới sơ đồ: "build: hours or days" và "review: hours or days". Chữ xanh: "1 hour on planning" dẫn tới "decrease % chance of rework, reduce review time", và "reduce review from 6hr -> 20m".

Nhìn lại sơ đồ software factory, ngay cả ở những phiên bản kém tinh vi hơn, engineer đã làm chuyện này hàng chục năm: bạn nhận ra rằng ai đó build một thứ sẽ mất hàng giờ hay hàng ngày, và review, test nó có lẽ cũng mất hàng giờ hay hàng ngày. Nên ta làm architecture proposal từ đầu, làm sprint planning từ đầu, thống nhất với mọi người trong team. Hy vọng là giảm được lượng rework, tức là giảm xác suất thứ đi ra ở đầu kia phải làm lại nhiều, và có thể giảm thời gian review, vì ta đã ra mọi quyết định một cách rẻ ở đầu, khi chúng còn dễ đổi.

10. Seeking leverage: đường cong expected pain

Nhưng bạn cũng không thể plan quá tay. Dex gọi chuyện này là seeking leverage (tìm đòn bẩy).

Biểu đồ chance you'll have to rework it theo time/effort spent up front: 2 min, 5 hours, 20 hours — "chance you'll have to rework it" theo "time / effort spent up front". Điểm đỏ: "yolo a 2-sentence prompt", 2 phút, khoảng 50% rework. Điểm xanh lá: "hand-write a detailed spec", 5 giờ, khoảng 10% rework. Điểm xanh dương: "write all the code by hand", 20 giờ, khoảng 0% rework. QR dẫn tới "Why Software Factories Fail", hlyr.dev/wsff-gh.

Giả sử bạn "YOLO" một prompt hai câu và có 50% khả năng phải làm lại. Làm lại ở đây nghĩa là: được rồi, tôi gửi thêm vài prompt nữa cho tới khi code và sản phẩm đi ra đúng như tôi muốn. Đó là một cách tiếp cận coding với AI.

Hoặc bạn có thể tự tay viết một spec rất chi tiết và bỏ ra năm tiếng, có khi không phải tự tay viết mà là qua lại với model để plan toàn bộ project. Khi đó xác suất phải lặp lại thêm thấp hơn hẳn; ta gần với one-shot hơn.

Trường hợp cực đoan dĩ nhiên là tự viết toàn bộ code bằng tay, và khi đó có 0% khả năng phải làm lại vì thứ gì đó agent làm sai. Bạn vẫn có thể ra quyết định tồi, nhưng bạn không phải dọn agent slop, "chỉ dọn human slop thôi".

Slide expected pain = P(you'll have to change it) × how painful the change is — Công thức: "expected pain = P(you'll have to change it) × how painful the change is". Expected pain bằng xác suất phải đổi nhân với độ đau của việc đổi.

Cách Dex hình dung: expected pain là khả năng tôi phải thay đổi thứ này về sau, nhân với việc thay đổi nó sẽ khó tới đâu. Anh hiếm khi cãi với agent trong lúc planning về chuyện một cái nút màu gì, vì anh biết mình có thể gỡ nó ra bằng một prompt khác và sửa sau. Nhưng nếu database schema sai, nếu API contract sai, nếu data model và thuật toán lõi sai, thì phải quay lại sửa nhiều thứ hơn hẳn. Đó mới là chỗ đau.

Đường cong expected pain giảm nhanh, khoảng 80% expected pain biến mất ở giai đoạn đầu — Đường cong "expected pain" đi từ 50% ở mốc 2 phút, rơi nhanh xuống quanh 10% ở mốc 5 giờ, rồi gần như nằm ngang tới 20 giờ. Chú thích: "~80% of the expected pain, gone up front", phần lớn nỗi đau được loại bỏ bằng một lượng công sức vừa phải ở đầu.

Vậy tuỳ việc bạn đang làm, có một điểm nào đó trên đường cong mà bạn muốn đứng: bạn muốn loại bỏ bao nhiêu phần expected pain. Và một lần nữa: nếu bạn làm một thay đổi rất nhỏ, làm ơn đừng bỏ năm tiếng viết plan file. Quá nhiều token, quá nhiều thời gian, không đáng. Bạn sẽ kiệt sức.

11. Đừng over-lever: ship sản phẩm, không chỉ build cỗ máy

Nhìn chung, đừng over-lever. Dex kể anh đã xây software factory suốt sự nghiệp, từ khi ra trường được một năm. Hồi đó anh nhận ra: người hữu ích nhất trong công ty là người xây cái thứ build ra thứ khác. Giờ tất cả chúng ta đang cố xây "cái thứ build ra cái thứ build ra thứ khác".

Nhưng anh dẫn Solomon Hykes, founder của Docker, với ý tưởng mới: bạn phải đo lượng code mình ship, nhưng net productivity của bạn là lượng code bạn ship trừ đi lượng code bạn ship chỉ để làm cho software factory cá nhân hay software factory của công ty. Vì nếu bạn đang build thứ gì đó, bạn cần ship giá trị cho user. Trừ khi bạn làm nghệ thuật hay side project, thứ Dex hoàn toàn ủng hộ (anh cũng hay code dạo bên lề), còn nếu làm chuyên nghiệp và muốn tạo ra thứ có giá trị, bạn phải ship chính sản phẩm, không chỉ build cái máy build ra nó.

Đo năng suất ròng, không đo tổng lượng code.

12. Aligning visually: skill show-me

Một trong những thứ có leverage cao nhất họ tìm ra là aligning visually, thống nhất với agent bằng hình ảnh. Họ build một skill tên là show-me, về cơ bản khuyến khích model đưa feedback trực quan rõ ràng hơn, để bạn không phải đọc những bức tường chữ của agent, "thứ tôi biết tất cả chúng ta đều phát ngán".

Trong HumanLayer có nhiều lựa chọn cho việc này: HTML mockup cho các sản phẩm sắp build, diagram kiểu "cái này sẽ chạy thế nào". Những thứ đó dễ hiểu hơn nhiều so với một bức tường chữ. Nên họ align với model rất nhiều theo cách này: làm sao để kênh giao tiếp giữa người và agent có bandwidth cao hơn khi quyết định sẽ build cái gì và build thế nào.

Ý tưởng của show-me: agent chọn biểu diễn nhỏ nhất đủ nói rõ ý (diagram, call tree, pseudocode, HTML nhỏ) thay cho văn xuôi dài.

Có rất nhiều ví dụ, kể cả chuyện: khi đã biết trạng thái cuối trông thế nào, ta sẽ stack các PR ra sao? Các bước thật sự để đưa thay đổi ra ngoài là gì, repo nào phải đổi, theo thứ tự nào? Skill này có sẵn online, và Dex nói repo của nó chắc đã hơn 20k star; anh sẽ đưa link ở cuối. Cài bằng lệnh sau (theo humanlayer/skills):

npx skills add humanlayer/skills --skill show-me

13. Cho agent tự test, và linter deterministic thay cho "make no mistakes"

Một việc dễ: giúp agent test công việc của chính nó. Agent phải chạy được app của bạn, hoặc ít nhất phần app bạn quan tâm. Nó phải gọi được bằng curl, dùng được browser, quay được video. Khá đơn giản.

Dex hỏi ai đang viết TypeScript. Nhiều người giơ tay. Nếu bạn viết TypeScript, hãy đi lấy repo này ngay, "à không phải ngay, sau talk": theo lời Dex, đó là khoảng một trăm oxlint rule do Dillon Mulroy, principal engineer ở Cloudflare, viết (repo dmmulroy/anti-slop, chạy trên Oxlint). Với mỗi slop pattern trong TypeScript mà anh ấy thấy và không thích, giờ bạn phát hiện được nó một cách deterministic.

Không còn kiểu "no more mistakes, make no mistakes, ultrathink" nhét vào CLAUDE.md nữa. Cứ dùng linter deterministic để bắt hết những thứ này; dễ hơn nhiều.

Còn nếu bạn viết Python, nhóm SlopCodeBench có khoảng 200 slop detector tuỳ biến. Bạn có thể chạy chúng trên mọi pull request, rồi cho một agent đi sửa khi complexity quá cao, hay những thứ tương tự.

14. Đưa user feedback, incident và experiment vào factory

Bạn nên đưa user feedback vào factory. Đây là một ca rất cụ thể: khi user gửi feature request, tại sao phải ngồi đọc một hàng đợi support ticket, rồi quyết định cái nào build, rồi mới đi làm? Lẽ ra bạn chỉ cần nhìn vấn đề support và cái PR mà agent đề xuất để sửa nó. Nếu vấn đề là thật và PR trông ổn, bạn bấm merge và issue được đóng.

Incident cũng vậy. Sẽ tuyệt biết bao nếu khi bị page lúc 3 giờ sáng, bạn nhận được: đây là cái đang hỏng, đây là cái agent nghĩ thật sự hỏng, và đây là một PR. Có lẽ 50% trong số đó sẽ là slop. Nhưng nếu 50% số lần bị page lúc 3 giờ sáng, bạn chỉ cần bấm nút merge vì nó trông ổn rồi quay lại ngủ, thì thật tuyệt.

Cùng tinh thần đó: để model tự thử nghiệm. Cho chúng công cụ để đưa một phiên bản mới của app tới, chẳng hạn, 1% user hay 0.1% user, rồi chúng lặp lại, kết hợp các experiment, và học từ điều gì thật sự giúp user giải vấn đề trong sản phẩm của bạn nhanh hơn. Cái này rất mạnh.

15. Loops thật sự là gì: forward pressure, back pressure, và compound over time

Và bạn có thể xây loop trên nền những thứ này. Dex tự nhận anh cứ nói chữ "loops" mãi. Anh nghĩ cách hữu ích hơn để nhìn khái niệm loop là tách nó thành hai phần: forward pressure và back pressure.

Forward pressure khiến việc bắt đầu, back pressure cho agent feedback trong lúc làm.

Forward pressure là thứ khiến việc mới bắt đầu: một cron, một PR đi vào, một incident, một tin nhắn Slack, bất kể là gì. Back pressure là ý tưởng: làm sao để agent nhận feedback về việc nó đang làm, để nó có thể hill climb về phía một outcome và làm việc độc lập lâu hơn. Theo Dex, đó là bài học cốt lõi nên mang về từ cơn hype loops, nếu bạn muốn đi xa hơn phần hype.

Slide Compound over time, Learn from past sessions — "Compound over time. Learn from past sessions."

Và bạn nên compound theo thời gian, học từ các session cũ. Nếu bạn làm trong team, nên có ai đó phân tích tất cả session mỗi tuần và hỏi: tuần này mọi người bực vì gì? Họ đang quát agent về chuyện gì? Agent đang bị kẹt ở đâu? Rồi cải thiện các skill nội bộ, AGENTS.md, hay bất kỳ lớp tuỳ biến nào khác của harness mà bạn đang xây.

16. The new software forge

Dex nghĩ tất cả những điều trên có hệ quả rất thú vị cho tooling, và anh nói về thứ anh coi là software forge mới.

Anh hỏi có ai từng dùng Git trước khi có GitHub không, gửi patch qua email trên mailing list, hay đặt chúng lên file server. Anh nghĩ team Linux vẫn làm vậy; Linus thích dùng Git theo cách phi tập trung nhất có thể. Nhưng phần lớn mọi người có một mental model tập trung và một source of truth tập trung cho chuyện này.

Slide The Forge Lifecycle: Before GitHub, After GitHub, Before AI-Native Forge, Centralized AI Native Forge — "The Forge Lifecycle" gồm bốn ô. Before GitHub: "wrangle git patches on email lists". After GitHub: "centralized commit management". Before AI-Native Forge: patch đã tập trung, nhưng "plans, specs, and sessions spread across slack, gdocs, notion, linear, github, workstation traces" (plans, session traces, "heres what my claude said", product specs, architecture docs, figma designs). Centralized AI Native Forge: product specs, prompts, designs, plans, sessions và patch cùng đổ về một trục, "centralize all software construction".

Trước AI-native forge, patch đã được tập trung, nhưng mọi thứ khác thì hỗn loạn. Theo Dex, thứ tương đương gần nhất với chuyện gửi git patch qua email ngày xưa là: tôi đang nói chuyện với agent của mình, tôi kẹt, không biết làm gì, tôi dán output vào Slack hay Teams. Đồng nghiệp nhặt nó lên, dán vào agent của họ, nơi có context khác, rồi lấy câu trả lời dán lại cho tôi, tôi dán nó vào agent của tôi, và có khi tôi mới có câu trả lời. Hy vọng chỉ phải làm một vòng như vậy.

Nhưng cách đó cực kỳ kém hiệu quả và ma sát rất cao, nên phần lớn mọi người không làm. Họ nghĩ "tôi sẽ làm tốt nhất có thể, gửi cái PR slop đi, hy vọng sếp sẽ chỉ ra tôi sai ở đâu". Dex cho rằng những session mọi người đang chạy, những doc và plan họ đang viết, và chính code, đều có thể được tập trung lại cùng nhau. Đó là một chút về thứ HumanLayer đang build, nhưng anh không đi sâu.

17. Các lớp của một software factory: infrastructure, dev environment, harness

Nếu cắt theo một chiều khác: nếu bạn định xây software factory và muốn tự lắp nó từ các mảnh vì team bạn có nhu cầu riêng, thì có mấy lớp.

Slide bốn lớp: Control Plane, Harness, Dev Environment, infrastructure / vms / sandboxes — Bốn lớp, từ dưới lên. **infrastructure / vms / sandboxes** (cloud or workstation): VMs, Containers, Isolates, Kubernetes, Lifecycling, Snapshotting, Warm Pools; "Buy or Build". **Dev Environment**: Library Dependencies, Internal svc/network deps, Preview Environments, pets or cattle; "No Good Abstraction, massive friction if not Customer-Owned". **Harness**: Agent, Tools, Skills, Memory, Compaction, Testing, MCP, Auth; "Buy (claude, codex, amp, devin, factory, cursor etc) or build (OC, pi, custom)". **Control Plane**: Dispatch Work, Collaborate on sessions and plans, Automation and Scheduling, Review and Iterate on Code (Forge), Permissions / Audit / Governance / Spend Mgmt, Compounding Engineering; "Buy or Build".

Lớp infrastructure: coding agent thật sự chạy ở đâu? Bạn có thể tự build, kiểu "ta có pod thừa trong cluster Kubernetes, cứ chạy coding agent ở đó". Hoặc bạn mua một thứ như Freestyle, E2B hay Daytona, các sandbox platform được xây riêng cho những agentic workload sống ngắn hơn.

Bạn phải định nghĩa dev environment. Nếu có 100 repo, chắc bạn không chỉ test từng cái một. Bạn cần kiểu: đây là repo ta đang làm, và để chạy và test nó, nó cần chạy trên internal cloud của ta, hoặc cần chạy thêm sáu repo khác để test được local. Chỗ này phức tạp lên rất nhanh.

Bên trên là harness. Bạn có thể mua harness: Devin, Factory, Cursor, hay harness của bất kỳ frontier lab nào. Và bạn luôn có một lớp harness mỏng bọc ngoài, như các skill và có thể các MCP mà bạn dùng để làm việc. Nhưng bên dưới đó bạn cũng có thể tự build những phần lớn của harness.

Dex hỏi có ai dùng Pi không, vài người giơ tay. Nếu chưa thử Pi, anh rất khuyên thử. Anh không phải người dùng Pi nhiều, "vì vài lý do", nhưng ai tới nói với anh "tôi mê Pi" thì anh mặc định: okay, chắc bạn là người rất có gu. Nếu bạn thích vọc, nếu bạn có một vim config đã mang theo qua mọi workstation suốt 20 năm, bạn sẽ mê Pi. Nó cho rất nhiều linh hoạt, anh là fan của project này. Nhưng bạn phải tự build nhiều hơn hẳn: Pi không có sẵn MCP support, bạn phải lấy từ plugin hoặc tự build.

18. Control plane, demo HumanLayer và lời kết

Trên cùng là control plane. Bạn dispatch việc mới thế nào? Cộng tác trên session, plan và code thế nào? Làm automation và scheduling thế nào? Làm permission, audit, governance và spend management thế nào? Và lại là chuyện compounding: học từ những gì mọi người đang vật lộn. Đây là chỗ HumanLayer đứng, ở lớp trên cùng này. Ai quan tâm thì anh sẵn lòng nói chuyện.

Sơ đồ kiến trúc HumanLayer: daemon HLD, backend, desktop app, sync client trong VPC — Kiến trúc HumanLayer. Trên workstation của bạn, humanlayer desktop app launch humanlayer daemon (HLD), daemon launch và quản lý session Claude Code hoặc Codex, stream session events, artifacts, diffs lên humanlayer backend. Daemon cũng chạy được trên "any compute (mac mini, ec2, etc)" hay "disposable compute (daytona, freestyle, github actions, etc)" với cờ `--run-with-idle-timeout 5m`. Coworker workstation và mobile PWA xem status, nhận events / artifacts / diffs, gửi follow up prompts hay new sessions. Trong "your VPC", một sync client (HumanLayer OSS hoặc container) nhận stream work requests, đưa new task cho orchestrator; orchestrator lifecycle compute (ví dụ tắt sau 24h hay snapshot khi timeout) và launch daemon trên enterprise-managed compute.

Anh có một demo rất ngắn, "thật ra là Claude làm". Anh không giải thích hết mọi thứ đang diễn ra, nhưng ý chính: bạn có thể mời người khác prompt vào session của mình, kể cả khi session chỉ chạy trên workstation của bạn. Nên bạn không cần cloud agent mới cộng tác được. Có một hệ thống document và artifact dựng sẵn, nơi bạn để lại comment cho đồng đội và thống nhất về plan. Điều rất hay là diff được stream trực tiếp lên cloud trong lúc agent đang làm, kể cả khi nó chạy trên workstation của bạn, nên ai cũng có thể vào để comment cho việc agent đang làm. Họ đã thiết kế kiến trúc để làm được điều này từ khi bắt đầu project, khoảng tháng Mười Hai. Nhiều chuyện kiến trúc rất hay mà anh không nói ở đây: "gặp tôi ở hành lang, tôi sẵn lòng nói tới mỏi tai các bạn".

"Tôi là Dex." Liên hệ: dexter ở humanlayer.dev. Anh để lại trang tài nguyên (hlyr.dev/resources): mọi thứ họ từng nói, cho ai muốn tìm hiểu thêm và đi sâu hơn, vì talk này đi ở mức rất cao; ở đó có rất nhiều bài deep dive.

Anh cảm ơn mọi người và hỏi có ai có câu hỏi không vì còn chút thời gian. Không ai hỏi. "Okay, cool. Chúng ta đã trả lời hết câu hỏi của mọi người." Có vẻ có một người định hỏi, rồi thôi. "Amazing. Tôi coi đó là bằng chứng đây là một talk hoàn hảo." Anh nói sẽ ở quanh đây, ai muốn nói thêm cứ tới tìm, cảm ơn năng lượng của mọi người. "Cheers."