# Software factory giải thích từng bước bởi một Senior Engineer

[Bogdan Nedelcu](https://homus.dev/speakers/bogdan-nedelcu) · [theSeniorDev](https://homus.dev/orgs/theseniordev), [Dragos Nedelcu](https://homus.dev/speakers/dragos-nedelcu) · [theSeniorDev](https://homus.dev/orgs/theseniordev)

> Bogdan Nedelcu đi qua từng khối của một agentic software factory đang chạy thật: triage, refinement, implementer, quality pipeline, AI reviewer, QA agent.

Topics: Software Factory, Coding Agents, Workflow

Canonical: https://homus.dev/talks/software-factory-explained-by-a-senior-engineer-step-by-step

## 1. Agentic software factory là gì

Video là cuộc trò chuyện giữa hai người đồng sáng lập theSeniorDev. Bogdan Nedelcu là người trình bày: anh mở một tấm bảng trắng vẽ toàn bộ hệ thống mà team anh đang chạy, rồi đi qua từng khối. Dragos Nedelcu là người hỏi, chen vào những câu hỏi về ý nghĩa của nó với nghề.

Bogdan mở đầu bằng định nghĩa. Một agentic software factory, về cơ bản, là cách tích hợp agent vào suốt chiều dài của software development lifecycle, để tự động hoá phần lớn những phần lặp đi lặp lại. Còn bản thân anh, với tư cách engineer, hiện dành gần hết thời gian cho đúng hai việc: hoặc là build cái nhà máy, hoặc là review một phần code mà nhà máy làm ra. Và anh nói trước: lát nữa mọi người sẽ thấy anh thậm chí không review phần lớn code. Anh chỉ review code quan trọng (critical code).

![Bảng trắng The Agentic Software Factory với toàn bộ sơ đồ, hai người nói chuyện ở hai bên](https://homus.dev/photos/WOhJflEz3mY-0003.jpg)

Toàn cảnh tấm bảng "The Agentic Software Factory": hàng trên là Ingest, Triage Agent, Product Board với Refinement Agent, Prioritizer và Implementor Agent; giữa là Build & Quality Pipeline và Pull Requests; dưới là AI Reviewer, blast radius, Formal Verification, Staging, QA Agent, Production và một góc "Future work". Chú thích màu ở góc phải: AI agent, Formal Verification, Human Gate.

Theo anh, việc của engineer bây giờ đã đổi. Thay vì viết một component, bạn định nghĩa một design system. Thay vì viết một endpoint, bạn định nghĩa loại API mà team sẽ build: REST hay GraphQL? Caching làm thế nào? Dựa trên những chỉ thị (directives) bạn đưa ra, có những con robot nhỏ, những agent nhỏ ở gần như khắp nơi lo phần implement.

Thế là rất nhiều việc nhàm chán được giao đi, và bạn phải làm việc ở tầng cao hơn. Khi đã build một software factory, cái bạn bận tâm là build dây chuyền sản xuất (production line), hoặc đóng vai một nhà khoa học: đi vào, làm một phép thử để kiểm một giả thuyết nào đó. Khi giả thuyết đã được kiểm xong, bạn ném nó vào dây chuyền kỹ thuật (engineering line), nhưng bạn không đứng trong dây chuyền đó. Bạn không ở dây chuyền lắp ráp (assembly line) mà tự tay dựng từng dòng code. Việc bạn thật sự làm là build chính cái nhà máy. Bogdan tóm lại: bạn đi từ build sản phẩm sang build cái nhà máy build ra sản phẩm.

## 2. Stack và chi phí: ai cũng build được

Câu hỏi tiếp theo: build một agentic software factory thế nào? Bogdan cho một phần giới thiệu ở mức cao trước. Phần lớn hệ thống của team chạy trên AWS, và bạn có thể làm việc này với nhiều dịch vụ thuộc free tier, không cần trả tiền cho tất cả. Toàn bộ những gì anh dựng được làm bằng một gói Claude Max cá nhân, và anh còn chưa dùng hết gói đó. Nên có lẽ bạn làm được với một gói thấp hơn (theo video đăng ngày 12/10/2026).

Ý anh muốn nói: nếu bạn đang là developer, bạn build được thứ này. Các công cụ đều có sẵn. Không có gì đặc biệt cả. Bạn không cần làm cho một frontier lab mới build được một hệ thống như vậy. Bạn cũng không cần một ngân sách token vô hạn, đơn giản vì các gói subscription của Claude hiện rất hào phóng: bạn có hàng triệu token. Bạn hoàn toàn tự build được.

Anh hứa sẽ đi một vòng tổng quan ở mức cao trước, rồi mới đào vào từng khối cụ thể. Ở mức cao, trong trường hợp của team anh, kiến trúc gồm một front end dạng monolith và một số backend microservice. Bogdan nói tất cả nằm trên GitLab; trên bảng thì khối pipeline mang logo GitHub, và phần sau anh cũng kể GitHub trong danh sách MCP server.

Stack Bogdan kể: một front end monolith, vài backend microservice, chủ yếu chạy trên AWS, còn toàn bộ agent chạy bằng một gói Claude Max cá nhân chưa dùng hết.

## 3. Triage agent: tự động gom bug

Khối đầu tiên là ingest. Hiện tại, team có một triage agent nhận các issue đổ về từ ba nguồn: Slack, Sentry, hoặc do người dùng báo. Tất cả đều là hook. Mỗi khi một người dùng báo bug, hoặc team thấy một lỗi bật lên trên Sentry, hook sẽ gọi để gửi toàn bộ context cho một agent. Agent đó làm triage và trả lời mấy câu: đây có phải lỗi thật không? Đã có gì tương tự trong backlog chưa? Lỗi này đã được sửa rồi chưa?

![Khối Ingest trên bảng: logo Slack, Sentry, User Reported, Dev Reported, các chấm màu đổ vào Triage Agent](https://homus.dev/photos/WOhJflEz3mY-0203.jpg)

Khối Ingest: bên trái là các nguồn (Slack, Sentry, một nguồn nữa, "User Reported", "Dev Reported"), ở giữa là đám issue lộn xộn, và Triage Agent gom chúng thành các hàng gọn gàng. Ghi chú dưới agent: "dedup, reproduce", tức loại trùng và tái hiện lỗi.

Đó là bước đầu tiên: team tự động hoá kiểu công việc gom bug (bug collection) này. Trên bảng, khối ingest còn có thêm một nguồn "Dev Reported", tức bug do chính developer báo, bên cạnh "User Reported".

## 4. Refinement agent: từ báo lỗi thành ticket có scope

Sau triage là refinement agent. Agent này cố ước lượng scope, blast radius (thay đổi này ảnh hưởng tới bao nhiêu service), mức ưu tiên (đây có phải bug đang làm hỏng production cần sửa ngay không), và kích thước. Tất cả những việc đó, Bogdan nói, là phần product work mà team từng tự làm.

![Product Board với Refinement Agent như một lăng kính tách ra scope, blast radius, priority, size; bên phải là Prioritizer với kill switch](https://homus.dev/photos/WOhJflEz3mY-0243.jpg)

Refinement Agent được vẽ như một lăng kính: một issue đi vào, tách ra bốn thuộc tính scope, blast radius, priority, size, kèm acceptance criteria. Bên phải là Prioritizer: một hàng đợi đánh số 5 đến 1 và một nút "kill switch".

Điều anh thấy đẹp ở đây: việc này từng tốn nhiều ngày trong một team. Bạn thức dậy, rồi nghĩ: được rồi, để tôi tái hiện issue này xem, nó có phải issue thật không. Và việc đó khá máy móc. Có rất ít bug thật sự cần bạn có mặt. Nên anh rất thích phần này, vì nó lấy đi một phần công việc mà chính anh, với tư cách engineer, cũng chẳng thích làm.

Anh nhắc lại một lần nữa: tất cả đều là agent, nên chúng cố ước lượng, cố đoán. Đừng tin rằng nó sẽ cho một con số ước lượng tốt bằng của bạn. Nhưng nó sẽ đủ tốt. Với phần lớn thay đổi, phần lớn bug nhỏ, nó đủ tốt rồi. Bạn không cần tốn thêm thời gian vào đó; không đáng.

Dragos chen vào để chốt lại: vậy là anh vừa nói phần refinement này sẽ làm thay cái việc mình không thích, về cơ bản là cố hiểu ticket? Bogdan xác nhận: đúng. Refinement agent cố khoanh scope, tìm ra blast radius, tái hiện lỗi, rồi cuối cùng tạo một ticket ngay trên board của team.

## 5. Ticket do agent viết, kèm video tái hiện lỗi

Bogdan mở board thật. Như mọi người thấy, tất cả các ticket ở đây đều do agent tạo. Thường anh chỉ đưa cho chúng một screenshot rất sơ sài và nói kiểu: này, kiểm cái này giúp tôi? Đây có phải bug không? Có người vừa báo cái này.

![Board Linear của theSeniorDev, danh sách issue In Progress, mỗi dòng gắn nhãn blast:low, Bug, factory:refined, factory:escalated](https://homus.dev/photos/WOhJflEz3mY-0320.jpg)

Board issue của theSeniorDev, mục "In Progress" có 15 ticket. Mỗi ticket mang mã TSD và các nhãn do nhà máy gắn như `blast:low`, `Bug`, `factory:refined`, `factory:in-review`, `factory:escalated`, cùng số pull request liên quan.

Trong ứng dụng của team có một nút: khi anh nhận được tin nhắn của người dùng, anh chỉ việc bấm "report a bug" và nó đi thẳng vào pipeline này. Các agent làm toàn bộ phần nặng nhọc. Chúng dùng Cypress và Playwright, và chúng nhìn được toàn bộ ứng dụng. Chúng có dữ liệu production giả lập (mock production data), nên có thể thử tái hiện đúng y cái bug đó. Thường thì chúng quay một video bằng Playwright, nên anh còn xem được cảnh chúng tái hiện lỗi. Và chúng đính kèm video đó vào ticket.

Đây là hình dạng của một ticket. Bogdan thừa nhận một vấn đề lớn với AI: ticket hiện đang quá dài dòng (verbose), và đó là thứ anh sẽ xử lý sau. Nhưng như mọi người thấy, ticket cố đi qua các bước để tái hiện, scope, acceptance criteria và bằng chứng tái hiện (repro evidence). Thường nó có screenshot và video, cố chỉ ra chỗ có vấn đề.

Ticket mẫu trên màn hình là một test e2e chập chờn (flaky) ở trang chi tiết bài viết trong community: comment cứ nằm ở trạng thái skeleton sau khi tải lại trang. Phần "Expected" ghi rằng trong khoảng 15 giây thread phải thoát khỏi skeleton: thử lại, render comment khi thử lại thành công, hoặc hiện một trạng thái lỗi gọn kèm nút thử lại nếu mọi lần thử đều hỏng. Phần "Steps taken" liệt kê tám bước agent đã làm: mở trang community bằng một tài khoản QA của nhà máy (Desktop Chrome 1280x720), xác nhận request lấy comment trả về 200, chặn request comment rồi tải lại trang, đợi 20 giây và chụp màn hình (6 phần tử skeleton, không có comment), đợi thêm 25 giây (tổng khoảng 45 giây) và thấy vẫn chỉ có một request comment đang treo nên trang không bao giờ thử lại, rồi đóng trình duyệt. Bên phải là thuộc tính: In Progress, mức High, 4 điểm, và các nhãn `blast:low`, `Bug`, `factory:in-review`, `factory:refined`, `factory:reproduced`.

Vì thế, thay vì review code, Bogdan thường nhìn một bức tranh ở mức cao và tự hỏi: mình có thật sự cần đi vào code không? Đó chính là refinement agent, và kết quả cuối cùng của nó là một ticket đã được khoanh scope (scoped-down ticket).

## 6. Prioritizer và implementer agent: CLAUDE.md, skill, MCP server

Khi đã có hàng đợi ticket, team còn có một prioritizer. Nó cố xác định ticket nào nên được implement, ticket nào chưa sẵn sàng để implement, ticket nào cần con người góp ý. Lý do: rất nhiều thứ trong đó là câu hỏi kiểu "có đáng làm không?", "nó có làm thay đổi kiến trúc không?", "nó có thật là bug không?". Nếu đó là một bug rất rõ ràng và dễ sửa, ví dụ thường là những chỉnh sửa nhỏ ở front end, thì nó đi thẳng tới một instance của thứ team gọi là implementer agent.

![Khối Implementor Agent: CLAUDE.md, skills, MCP servers với logo GitHub, Linear, Sentry, subagents, x N instances worktree + sandbox each](https://homus.dev/photos/WOhJflEz3mY-0443.jpg)

Khối Implementor Agent: agent ở giữa nối với file CLAUDE.md, một chồng skills, các MCP server (logo GitHub, Linear và một dịch vụ nữa) và các subagent. Dưới agent ghi "× N instances, worktree + sandbox each": nhiều bản chạy song song, mỗi bản có worktree và sandbox riêng. Mũi tên đỏ bên phải: "fail → fix · 3 retries → escalate".

Implementer agent chính là developer, là kẻ viết code. Nó có quyền đọc CLAUDE.md của team, nơi team định nghĩa kiểu: mỗi khi build thứ gì, hãy xem design system của chúng ta; mỗi khi viết một endpoint, hãy dùng cái này hoặc xem cái kia. Bogdan định nghĩa ở đó cách team làm caching, cách dùng database, và gần như toàn bộ stack. Nhờ vậy nó không phải nghĩ quá nhiều.

Tiếp đến là một số skill. Anh thường ưu tiên skill đến từ chính stack mình dùng: những thứ như skill của Vercel cho React, skill AWS do AWS làm. Anh muốn đi càng sát nguồn càng tốt, vì biết rằng nhà cung cấp công nghệ thường có hiểu biết tốt nhất về cách công nghệ đó vận hành, và họ đóng gói hiểu biết đó thành skill.

Agent có quyền truy cập tất cả MCP server của team. Trong trường hợp này là Sentry, PostHog (để nó tự chạy query của mình), tất nhiên là Linear, và GitHub. Ngoài ra còn có nhiều subagent khác nhau. Điểm đẹp là bạn làm song song được trên rất nhiều ticket. Bogdan hẹn sẽ quay lại implementer agent sau.

## 7. Đổi tư duy: sửa nhà máy, không sửa code

Về cơ bản, khi code đã được viết xong, nó đi vào built-in quality pipeline của team. Bogdan nói đây có lẽ là một trong những mảnh quan trọng nhất, và cũng là chỗ anh vẫn đang làm tiếp ngay lúc này. Anh hẹn sẽ nói về các antipattern nữa, những antipattern của agent: agent bị kẹt và mắc lỗi ra sao, và khi build một nhà máy thì bạn kiểm soát chuyện đó thế nào.

Built-in quality pipeline, theo anh, chính là lý do khiến bạn ngủ ngon, hoặc mất ngủ, khi bạn không đọc code. Nên phần lớn việc anh làm những ngày này là nhìn vào kết quả cuối. Anh đi vào source code, nhìn các component, rồi tự hỏi: mình cần thêm gì vào built-in quality pipeline, hoặc vào context, để cái này tốt hơn? Tức là anh không sửa một component. Anh sửa, một lần nữa, cái nhà máy. Đó là một cú đổi tư duy lớn mà bạn phải làm.

Và bạn luôn nghĩ theo hệ quả bậc hai, bậc ba. Câu hỏi không còn là: nếu mình đổi chỗ này và biến nó thành một custom hook, component sẽ thay đổi ra sao? Mà là: nếu agent bắt đầu viết custom hook khắp codebase, hệ quả cuối cùng sẽ là gì? Nó có làm tăng mật độ bug không? Nó có làm tăng công sức testing không? Đó là cách bạn nghĩ bây giờ. Ngày trước thì khác: anh phải tự làm toàn bộ phần việc chân tay, dành rất nhiều thời gian chỉ để build một endpoint, một component hay một view cụ thể. Làm xong rồi, anh mới đội mũ architect lên và nhìn vào hệ thống tổng thể.

Cú đổi tư duy Bogdan nhấn mạnh: thấy một component tệ thì không sửa tay component đó, mà sửa quality pipeline hoặc context để mọi lần nhà máy chạy sau ra kết quả tốt hơn, và luôn nghĩ đến hệ quả bậc hai, bậc ba.

## 8. Vì sao engineer nên hào hứng thay vì sợ

Dragos dừng lại để hỏi. Nhìn toàn bộ những gì Bogdan vừa trình bày, anh nói (và nhờ Bogdan sửa nếu sai): vì ngày trước mọi việc đều làm tay, bạn nghĩ ra một thứ với tư cách engineer, rồi phải bỏ ra rất nhiều thời gian, vài tiếng, để implement nó. Còn bây giờ bạn có tất cả những agent này để chỉ huy, nghĩa là đây gần như là giấc mơ của một engineer. Không có gì phải sợ chuyện agent và AI xoá sổ việc làm của engineer, khi chính chúng cuối cùng cũng cho phép ta hiện thực hoá cái tầm nhìn nằm trong tất cả những cuốn sách clean code, toàn bộ lý thuyết về phát triển phần mềm đúng cách. Những thứ đó giờ thật sự implement được, vì một trong những lý do chính khiến chúng chưa từng được implement là quá tốn thời gian. Vậy đây là điều engineer nên hào hứng, đúng không?

Bogdan đồng ý hoàn toàn. Anh kể: đây là lần đầu tiên, ví dụ thế, codebase của team được phủ bằng integration test. Trước đây việc đó quá khó để làm và để duy trì. Giờ team có 950 bộ test độc lập trong bộ đầy đủ, chạy test mọi thứ mỗi đêm. Bình thường bạn cần một team testing chuyên trách ngày nào cũng viết test mới có được như vậy. Vậy là rất nhiều thứ từng khó làm giờ đã được dân chủ hoá.

Nhiều người nói rằng bạn không còn suy nghĩ nữa vì AI viết code. Nhưng thực tế, theo Bogdan, AI chỉ là một công cụ. Nó viết code rất kém. Nhưng vì nó lo phần viết code, bạn làm phần lớn việc suy nghĩ. Anh nói: anh nghĩ nhiều hơn bao giờ hết, nhưng code ít hơn bao giờ hết.

## 9. Built-in quality pipeline: đo bằng thứ deterministic

Dragos hỏi tiếp: nói về built-in quality pipeline này, nếu anh không nhầm thì nó có lẽ là mảnh quan trọng nhất của cả hệ thống. Bogdan có thể dẫn mọi người đi qua nó và cách build nó không?

Bogdan trả lời: khi build quality pipeline và thêm tất cả những guardrail chất lượng để đảm bảo code thật sự làm đúng việc nó phải làm, và không có code chết, bạn phải quyết liệt hơn nhiều so với ngày trước. Lý do không chỉ là AI mắc lỗi, mà còn là bạn đang ship khối lượng lớn hơn rất nhiều, nhiều code hơn rất nhiều. Ý chính là: bạn muốn có các thước đo deterministic trên code, vì bản thân AI đã đưa vào rất nhiều thứ xác suất (probabilistic), và như thế là quá nhiều rủi ro. Không thể cứ để nó hallucinate. Nên phải quay về kiến thức software engineering truyền thống.

![Khối GitHub Build & Quality Pipeline: linter, fallow tsc static analysis, rẽ ra complexity, duplication, dead code](https://homus.dev/photos/WOhJflEz3mY-0903.jpg)

Khối "Build & Quality Pipeline" trên GitHub: code đi qua linter, rồi static analysis (ô "fallow tsc"), từ đó tách ra ba phép đo complexity, duplication và dead code trước khi tới e2e test.

Khi nói thước đo deterministic, thứ đầu tiên team dùng là một code linter với bộ luật tự định nghĩa, hoặc đơn giản là dùng mặc định của ESLint, vốn đã khá tốt. Rồi đến TypeScript. Ngày trước, chừng đó là đủ. Nhưng giờ có những công cụ tốt hơn như [Fallow](https://github.com/fallow-rs/fallow) cho static analysis. Nếu bạn chưa biết nó, Bogdan khuyên hãy xem project này, anh recommend 100%.

Fallow là công cụ anh chạy để biết code có bị trùng lặp không: nó nhận diện bằng phân tích tĩnh những chức năng bị lặp trong code. Anh biết có nhiều người ngoài kia nói: code trùng thì đã sao? Nhưng hoá ra nếu bạn có code trùng, bạn sẽ tốn nhiều token hơn hẳn, vì phải viết unit test cho cả phần code trùng đó, và lần sau mở rộng codebase thì agent lại phải nạp nó vào. Nên dù có AI hay không, code trùng và feature trùng đều không phải điều tốt.

Tiếp theo, công cụ còn kiểm cyclomatic complexity. Bogdan giải thích đây là một cách đo các hàm và mức độ phức tạp của chúng, để không có những component nguyên khối dài cả nghìn dòng. Điểm hay là bạn chạy được các thước đo tĩnh này, và chúng đưa kết quả ngược vào agent. Vậy là agent tự sửa code của chính nó dựa trên các thước đo tĩnh.

Team cũng nhìn vào code chết (dead code). Chuyện này xảy ra khá thường với AI: bạn bỏ một feature, nhưng còn sót lại endpoint backend mà nó không xoá, hoặc một bảng database không còn cần. Và bạn tích tụ đủ thứ rác đó. Càng đi nhanh, rác càng tích tụ nhiều. Theo anh, rất quan trọng là phải dọn dẹp: xoá đi lượng code nhiều ngang với lượng bạn thêm vào.

## 10. End-to-end test thay vì TDD, visual diff và giới hạn 100 lượt

Tiếp đến là end-to-end test. Tất nhiên, Bogdan nói, rất nhiều người đang nói về unit testing, kiểu "tôi làm TDD với AI". Anh tin rằng TDD phần lớn là lãng phí token, nhất là khi bạn lặp rất nhanh, vì component và code thay đổi quá nhanh. Việc có một unit test cho một hàm mới mà model vừa viết không cho anh chút tự tin nào. Nhưng end-to-end test viết dựa trên các feature của team, chạy trong môi trường thật, thì khiến anh ngủ ngon.

![Phần cuối pipeline: e2e tests, visual diff, dấu tích xanh, và mũi tên đỏ fail, fix, 3 retries, escalate](https://homus.dev/photos/WOhJflEz3mY-1103.jpg)

Cuối pipeline: complexity, duplication, dead code hội tụ vào e2e tests, rồi visual diff (hai ảnh trước và sau), rồi dấu tích xanh. Đường đỏ ở trên ghi "fail → fix · 3 retries → escalate": hỏng thì quay lại sửa, thử lại 3 lần rồi chuyển lên người.

Team làm end-to-end test, và còn có visual diff trên mọi pull request. Agent được dặn chụp screenshot trước khi có feature, rồi checkout sang branch đã sửa, rồi chụp screenshot và quay video feature mới. Bạn cần thứ này vì thực tế là bạn sẽ không đọc ba trang văn bản do AI sinh ra. Bạn cũng sẽ không đọc code, trừ khi đó là thứ quan trọng, đơn giản vì bạn không có thời gian. Nên kiểm bằng hình ảnh là một trong những cách tốt nhất anh tìm được để thật sự có tự tin.

Điều nữa: mỗi khi bạn chạy các công cụ này và chạy test, agent sẽ fail, rồi nó cố tự sửa, rồi lại fail tiếp. Đó là thứ team gọi là lượt (turn): agent đã mất bao nhiêu lượt để thật sự sửa xong bug hay feature này? Lúc đầu, bạn nghĩ chúng chỉ làm ba hay bốn lần. Nhưng có những edge case mà dù bạn dùng model nào, có thể là Fable, có thể là Opus 5.5, chúng cứ thế tự lao vào vòng lặp, có thể vì thiếu context nào đó, hoặc vì cứ tự mâu thuẫn với chính mình. Bogdan từng có agent cố giải một bug đến cả trăm lần.

Và đó là giới hạn cứng trong pipeline của anh hiện tại: 100 lượt. Nếu mất hơn 100 lượt thì dừng lại và quay về cho con người review, vì nếu không nó sẽ đốt sạch subscription và giới hạn token của bạn. (Trên bảng, mũi tên quay lại implementer thì ghi "3 retries → escalate".)

Theo Bogdan, đây là chỗ kỹ thuật thật sự bắt đầu. Mỗi khi gặp một ca như vậy, anh có thể dành cả ngày chỉ để nghĩ chuyện gì đã xảy ra, và mình đổi nhà máy hay kiến trúc code thế nào. Mình modular hoá code ra sao? Có nên đi sâu hơn vào event-driven microservices không? Context bị thiếu ở đâu, để hiểu thật sự vì sao model không sửa được issue? Model có rất nhiều kiến thức, nhưng anh khẳng định bạn chắc chắn thông minh hơn với tư cách engineer. Dù người ta nói gì, model vẫn mắc những lỗi rất ngớ ngẩn. Và khi chúng sai, chúng sai tới tận đáy. Đỉnh của AI rất cao, nhưng đáy cũng rất thấp. Đó là lý do bạn có mặt ở đó. Và khi đã tìm ra vấn đề là gì, bạn có thể nhân rộng phán đoán (judgment) của mình bằng cách nhúng nó vào agent và skill.

## 11. Pull request, blast radius và auto-merge

Kết quả của tất cả những thứ trên là rất nhiều pull request. Nhiều người đang tranh luận có nên code review hay không. Bogdan nói thật: anh chỉ review dựa trên blast radius và các service bị ảnh hưởng. Mọi người để ý ngay từ đầu, team đã nói về scope và blast radius, do refinement agent làm. Nếu blast radius rất nhỏ và chỉ ảnh hưởng một service, anh cứ để AI merge.

Blast radius nghĩa là gì? Bạn có thể hình dung nó gần như theo tầng. Nếu thay đổi chạm vào database, đó là blast radius rất lớn. Nếu chỉ là một chỉnh sửa trên một component front end, thậm chí không nằm trong design system, đó là blast radius rất nhỏ. Nếu nó đi vào design system, vì ảnh hưởng tới toàn bộ, thì blast radius lớn hơn.

Blast radius theo cách Bogdan hình dung, như các tầng: thay đổi càng chạm sâu (component lẻ, design system, database) thì vòng ảnh hưởng càng lớn và càng cần người xem.

Để demo một chút, anh cho xem buổi sáng của mình hiện trông thế nào. Anh thức dậy với rất nhiều pull request do agent tạo. Tuỳ vào ticket anh xem, anh quyết định merge hay không. Anh chưa auto-merge nhiều. Nhưng anh nghĩ khi team ngày càng tự tin hơn, và ngày càng nhiều bản release thành công, nếu đạt tỉ lệ 99% kiểu anh chỉ lướt qua PR và nó ổn, thì có lẽ team sẽ chuyển sang auto-merge: một lần nữa, nếu blast radius nhỏ, bạn cứ merge ticket và deploy lên production.

![Trang All pull requests trên GitHub: 25 open, 488 closed, các PR TSD do tsd-factory bot mở](https://homus.dev/photos/WOhJflEz3mY-1259.jpg)

Danh sách pull request: 25 đang mở, 488 đã đóng. Các PR như "TSD-126: Flaky e2e...", "TSD-117: Job Hunt 1/9: nav-depth primitives..." đều do tài khoản bot của nhà máy mở, mỗi PR kèm số task và số check đã qua (ví dụ 7/7).

Bogdan chỉ vào danh sách: nhân tiện, đây mới chỉ là hôm qua thôi, rất nhiều PR. Với software factory, team trung bình có 10 đến 20 PR mỗi developer mỗi ngày (theo video đăng ngày 12/10/2026). Dragos đáp gọn: hoàn hảo, vậy đó là các pull request.

## 12. AI reviewer: bắt những đường tắt của AI

Ở bước này team có thêm một AI reviewer. Đó là một agent riêng, không có context của các agent khác, và nó cố kiểm xem có bị thoái lui về kiến trúc (architecture regression) không. Bogdan giải thích: đôi khi team build một số microservice, và AI cứ thế giải issue bằng mọi giá. Có lúc chúng hard-code mọi thứ trong test. Chúng vi phạm ranh giới module (module boundaries). Và đây là chỗ clean code và kỹ thuật thật sự bước vào.

![Khối AI Reviewer: architecture regression, modularity, redundant system state; mũi tên xuống hình thoi blast radius, low auto-merge sang Staging trên AWS](https://homus.dev/photos/WOhJflEz3mY-1403.jpg)

Khối AI Reviewer nhận các pull request và kiểm ba thứ: architecture regression, modularity, redundant system state. Sau đó là hình thoi "blast radius": nhánh "low · auto-merge" đi thẳng sang Staging trên AWS, nhánh "high" đi xuống.

Team cũng kiểm xem có state hệ thống bị thừa (redundant system state) không. Lại nữa, AI rất thích thêm thứ mới. Chúng sẽ viết lại toàn bộ. Chúng bịa ra một hàm, kể cả khi hàm đó đã được khai báo rồi. Kiểu phải nhắc: đừng quên ta có một module nơi chức năng này được gom về; bạn phải lấy logic đó ra khỏi component và chuyển vào module.

Chuyện tương tự xảy ra ở backend với database. Nó đi tắt rất nhiều. Bogdan nói anh chưa từng thấy ai đi nhiều đường tắt như AI. Ví dụ bạn sẽ thấy nó dùng JSON stringify để lưu object vào database, như thể vậy là ổn. Và anh phải nói: không, không, không, mình sẽ cấu trúc dữ liệu đó. Đây không phải database MongoDB. Đây là relational database. Bạn không được làm kiểu này. Làm vậy là bạn vi phạm referential integrity. Đó là chỗ kỹ thuật bước vào.

Và nó khá thú vị, theo anh, vì bạn dành nhiều thời gian nghĩ về cách lưu dữ liệu, về clean code. Thành thật mà nói, ngày trước đây là thứ người ta hỏi trong phỏng vấn, rồi năm năm đi làm bạn chạm vào nó được một ngày. Phần lớn thời gian chỉ là cày feature, sửa bug nhỏ và nói chuyện với product.

## 13. Staging, smoke test, QA agent và môi trường tái hiện được

Tuỳ vào blast radius như đã nói, team đang tiến tới chỗ: blast radius thấp thì đi vào auto-merge, rồi lên staging. Trên staging, team chạy một tập con của bộ end-to-end test. Như đã nhắc, team có 950 bộ end-to-end test. Chạy hết thì quá đắt nếu tính bằng GitHub Actions: lần gần nhất Bogdan kiểm, mỗi lần chạy tốn khoảng 1,50 USD. Như vậy không bền vững, nhất là khi release nhiều thế này. Không bền cho công ty nhỏ, mà cũng chẳng bền cho công ty lớn, hay cho một team nhỏ.

Nên team làm một tập con gồm những test quan trọng. Team gọi đó là smoke testing, nhưng thật ra nó nhiều hơn smoke testing một chút: nó kiểm những thứ như đăng nhập và các chức năng cốt lõi không bị hỏng. Team chạy nó mỗi lần.

![Staging trên AWS, mũi tên sang QA Agent với acceptance criteria tested on staging, closes the ticket, rồi Production; dưới là Eng Review và Observability](https://homus.dev/photos/WOhJflEz3mY-1543.jpg)

Đoạn cuối của dây chuyền: Staging (AWS) sang QA Agent, với ghi chú "acceptance criteria tested on staging" và "closes the ticket" (logo Linear), rồi sang Production. Ô "Eng Review" màu đỏ đẩy lên Staging; góc phải là biểu đồ Observability, nối về một đường "feedback loop".

Nếu ổn, còn có một QA agent. Đây là thứ Bogdan mới đưa vào trong tuần này. Kể cả khi mọi thứ đã qua, team vẫn muốn có một agent đóng vai người dùng. Agent này chỉ có context của người dùng và của feature cần test. Nếu mọi thứ suôn sẻ, nó đóng ticket trên Linear trực tiếp và team merge lên production.

Bogdan dùng AWS Amplify cho front end. Anh thấy nó rất hay vì bạn tạo được các môi trường (environment) dựa trên front end. Backend thì phức tạp hơn một chút, vì mọi thứ anh kể đều đòi bạn cho agent khả năng tái tạo môi trường. Chúng cần một bản sao database để tự dựng lên. Chúng cần backend. Chúng cần checkout được một branch cụ thể ở front end, kéo toàn bộ code về. Và nếu bạn có nhiều service, chuyện này có thể trở nên rất phức tạp.

Nên phần lớn việc bạn sẽ phải làm nếu muốn build software factory của riêng mình, anh nói thẳng, là chắp vá bằng băng keo (duct taping): đảm bảo môi trường tái hiện được, quyết định dữ liệu nào đưa cho agent. Đôi khi team ẩn danh hoá dữ liệu. Anh kể mình nói kiểu: này, lấy năm người dùng dùng nhiều nhất, ẩn tên và email của họ, ẩn mọi thứ họ đã làm, rồi build một phiên bản thay thế giữ đúng ngữ nghĩa. Ví dụ đặt Lorem Ipsum vào bài đăng community của họ: dùng chữ giả Lorem Ipsum nhưng tạo bài có cùng độ dài, để tái hiện chính xác cách họ dùng sản phẩm. Phần lớn công việc của bạn sẽ là như vậy.

## 14. Formal verification, output có kiểu và observability

Thứ team đang làm thêm, và theo Bogdan đây là mũi nhọn hiện tại, là formal verification. Đây là một thuật ngữ gần đây rất phổ biến trên X. Về cơ bản, nó là cách để bạn viết những luật cứng ở mức cao hơn cho phần mềm của mình. Ví dụ: một người dùng không được thanh toán hai lần trong vòng năm giây; hoặc một người dùng không được nộp hai code challenge trong vòng hai phút.

![Hình thoi blast radius, nhánh high đi xuống khối Formal Verification TLA+ có biểu tượng ổ khoá, sang Eng Review, rồi lên Staging; dòng feedback loop](https://homus.dev/photos/WOhJflEz3mY-1703.jpg)

Nhánh "high" của blast radius: thay đổi lớn đi qua khối "Formal Verification · TLA+" (vòng trạng thái có một nhánh bị chặn và biểu tượng ổ khoá), rồi tới "Eng Review" do người làm, sau đó mới lên Staging. Dưới cùng là đường "feedback loop".

Bạn mã hoá những luật này vào phần mềm, và đó là phần tri thức thật sự tĩnh. Mỗi khi agent build code ở tầng thấp hơn, như JavaScript hay TypeScript, chúng chạy các luật đó. Nhờ vậy chúng đảm bảo bản thân phần mềm, tức hình hài cụ thể của nó, có thể được kiểm chứng hình thức (formally verified) bằng những trừu tượng ở mức cao. Bogdan nghĩ rất nhiều phần của software engineering sẽ đi theo hướng này.

Anh nhắc tới những ngôn ngữ như [Bend](https://github.com/HigherOrderCO/Bend) đang cố làm việc đó; trên bảng thì khối này ghi TLA+. Mọi thứ còn rất sớm. Nhưng anh cảm thấy mỗi khi bạn có một kiến trúc lớn hơn, nơi cần duy trì một số logic nhất định, thì việc làm điều đó bằng cách hỏi agent là không thực tế. Bạn sẽ cần một tầng kiến trúc tĩnh, những luật tĩnh không thể bị phá. Bend là một trong những thứ đang lên, và anh nghĩ năm 2027 ta sẽ thấy nhiều hơn về nó.

Team cũng dùng Jev làm model cho các tác vụ classification, vì nó có output dạng tĩnh: nó cho output tĩnh, type-safe từ các tác vụ phân loại. Vậy là rất nhiều thứ đang dịch chuyển theo hướng: làm sao đưa những hệ thống rất lớn, rất mang tính xác suất, về chỗ type safety và tính dự đoán được, vốn là thứ phần mềm enterprise cần.

Cuối cùng, đây là chỗ engineering review bước vào: với PR lớn hơn, feature lớn hơn. Bogdan còn đang thêm một tầng observability. Thứ anh đang cố tìm ra là: mỗi khi thấy rất nhiều bug quanh một feature, thường đó là dấu hiệu kiến trúc đã thay đổi, có lẽ đang có vấn đề. Đó là thứ team đang nhìn. Và bạn có thể dùng một agent cho việc này: đi qua tất cả ticket Linear đã đóng trong tháng trước (thường là rất nhiều), rồi tự hỏi: chúng đã chạm vào mảnh hạ tầng nào? Vì sao chuyện này xảy ra? Nó có lặp lại không? Mình làm được gì với nó?

Vậy là bạn đang làm hai việc song song. Bạn build một nhà máy, nhưng bạn cũng nhìn vào codebase và thiết kế một codebase mà giờ người ta gọi là agent friendly: một codebase modular, dễ mở rộng, có ranh giới rõ ràng để khoanh vùng lỗi. Và làm mọi thứ ta đã học từ software engineering cổ điển: microservices, micro frontends, chuyển sang event-driven, vân vân.

## 15. Việc tiếp theo, và phần thưởng cho engineer

Về các việc sắp làm, Bogdan đã ghi lại vài thứ. Thứ nhất là có một model router, để chọn giữa model rẻ và model mạnh. Hiện tại anh dùng Opus 5.5 cho mọi thứ (theo video đăng ngày 12/10/2026). Anh đùa rằng cách này sẽ còn chạy được cho tới IPO, tức tới khi công ty lên sàn và cuối cùng bắt đầu tính đúng giá thật của inference.

![Ghi chú Future work: model router cheap vs strong model per task, docs / changelog agent, feature flags + automatic rollback, incident → causing-PR attribution](https://homus.dev/photos/WOhJflEz3mY-1903.jpg)

Góc "Future work" trên bảng, được gạch chân khi Bogdan nói: model router chọn model rẻ hay mạnh cho từng task; một agent viết docs và changelog; feature flags kèm tự động rollback; và từ một sự cố truy ra PR đã gây ra nó.

Thứ hai là một agent viết docs và changelog. Hiện tại agent để quá nhiều comment trong code. Chúng có một thói quen điên rồ là thêm comment chứa tên issue ngay trong code, khiến code trông kinh khủng. Team sẽ dọn chỗ đó, xoá hết comment khỏi code.

Thứ ba, team muốn có feature flag. Hiện chỉ có một flag theo từng người dùng. Và thứ cuối là điều anh đã nhắc: đi từ một sự cố (incident), dành thêm thời gian làm post-mortem, để hiểu có thay đổi kiến trúc nào cần làm hay không, chứ không chỉ sửa bug. Đó là những thứ agent làm chưa tốt: chúng tối ưu quá mức cho một ràng buộc cụ thể.

Vậy như mọi người thấy, phần lớn việc của Bogdan sau khi dựng xong hệ thống này là: bạn giao đi các bug cấp thấp, giao đi việc viết và gõ code. Nhưng rất nhiều việc suy nghĩ dồn về bạn, và bạn có cơ hội đi vào database, nhìn schema và hỏi: mình áp dụng chuẩn hoá dữ liệu (data normalization) ở đây thế nào? Đó là những thứ ngày trước bạn còn chẳng có thời gian làm. Ngày trước bạn phải làm cả cuối tuần mới làm được chút refactoring cho code sạch, vì product lúc nào cũng đẩy feature và bạn luôn phải giành giật. Giờ bạn không phải làm vậy nữa, vì họ có feature của họ, còn bạn được làm thứ mình thật sự thích. Nên building một software factory có một mặt rất tích cực, và anh nghĩ làm việc với AI cũng có mặt tích cực.

## 16. Nghề software engineering đang đổi thế nào

Nhưng Bogdan cũng nói: nếu nhìn cách AI được quảng bá và áp lên developer, anh hiểu vì sao người ta bực, thậm chí giận một số công ty, vì toàn bộ thông điệp là thay thế engineer. Rồi giờ họ nhận ra: ôi, mình làm marketing quá tệ, chẳng ai muốn dùng công cụ của mình, thôi đổi marketing. Có thể họ sẽ thành công. Nhưng gác chuyện đó sang một bên, anh nghĩ công nghệ này có rất nhiều điều tuyệt vời. Miễn là bạn hiểu mình đang làm công việc kỹ thuật, bạn coi trọng phán đoán của mình, bạn đầu tư vào kỹ năng code và trở thành một developer giỏi hơn.

Dragos nói đó chính là điều anh muốn hỏi. Đây không chỉ là một CI/CD pipeline mới. Đây là một thay đổi nền tảng trong cách ta build phần mềm. Hơn thế nữa, nó là thay đổi nền tảng của cả nghề software engineering, và những việc bạn làm hằng ngày cũng thay đổi.

Câu hỏi của anh: nếu Bogdan nhìn lại chính mình, ví dụ năm năm trước, về tư duy và các kỹ năng kỹ thuật anh tập trung, những thứ anh làm hằng ngày, rồi nhìn bây giờ, sau agentic software factory, một pattern mà Dragos chắc chắn, cùng kiến trúc đi kèm, sẽ chiếm lĩnh software engineering. Ngày càng nhiều công ty đang implement nó, và điều đó hợp lý vì nó mang lại giá trị kinh tế. Vậy khi so hai phiên bản, Bogdan của ba, bốn năm trước và bây giờ, khác biệt lớn nhất anh thấy về kỹ năng và tư duy của software engineer sau khi agentic software factory lên ngôi là gì?

Câu hỏi Dragos đặt ra: engineer của ba, bốn năm trước khác engineer làm việc với một agentic software factory ở chỗ nào. Cột phải tóm các ý Bogdan trả lời ở phần sau.

## 17. Nhà khoa học và kỹ sư nhà máy

Bogdan trả lời: cú đổi tư duy số một khi đi từ phát triển phần mềm truyền thống sang làm việc và build agentic software factory của riêng mình là, anh thấy phần lớn thời gian mình có hai vai trò. Vai thứ nhất là nhà khoa học: anh đi vào, nhìn các thuật toán, phải kiểm những giả thuyết rất trừu tượng, rất cao. Kiểu: nếu dùng hash map cho state của một feature lớn hơn này, hoặc chuyển sang array, hoặc đổi định nghĩa state, thì sẽ thay đổi ra sao? Cần bao nhiêu lần thay đổi state (state mutation) để UI này chạy được? Cái đó mang tính khoa học hơn. Nếu nghĩ kỹ, bạn sẽ thấy nó cách khá xa chuyện product.

Nhưng khi giả thuyết đã được chứng minh, anh chuyển sang tư duy của kỹ sư đưa vào sản phẩm (productizing engineering): được rồi, ta tìm ra một vật liệu hay ho này, làm sao đưa nó vào sản phẩm? Và lúc đó bạn đi vào nhà máy. Anh nghĩ đó cũng là cách kỹ thuật truyền thống vận hành ngày nay: rất nhiều phần kỹ thuật xoay quanh sản xuất và build nhà máy, và người ta thiết kế sản phẩm sao cho dễ sản xuất.

Thứ đầu tiên bạn học ở trường kỹ thuật, anh kể, là: ừ, bạn build được bất cứ thứ gì, nhưng hệ quả của nó là gì? Nó sẽ đắt cỡ nào? Bạn dùng vật liệu gì? Và bạn thiết kế cả quy trình xử lý cụ thể cho từng vật liệu thế nào? Nó có khả thi không? Nên anh thấy theo một nghĩa nào đó, ta đã tiến gần hơn tới kỹ thuật truyền thống. Ta cần sắc sảo hơn nữa về nền tảng phần mềm (software fundamentals). Nhưng chắc chắn anh dành ít thời gian hơn cho tầng implement.

Ngày trước, anh nghĩ 80% thời gian của mình, nếu làm trong một team front end, là bàn về React: viết class component hay function component, có dùng arrow function không, những thứ cấp thấp mà thành thật thì rất phiền. Bây giờ, đó thường chỉ là một cuộc thảo luận lúc khởi đầu dự án. Rồi nếu mọi thứ đi xuống tệ, bạn mới đi vào lại: khoan, nhìn component này xem, vấn đề là gì, mình đổi nhà máy thế nào để cải thiện chất lượng?

Theo một nghĩa nào đó, công việc vui hơn. Nhiều người nói bạn phải buông việc code, ngừng code. Nhưng Bogdan nghĩ những người sẽ build những agentic software factory tuyệt vời lại chính là những người ngày trước rất đam mê code. Rất nhiều suy nghĩ, rất nhiều nền tảng của anh, anh dùng hằng ngày, thậm chí dùng thường xuyên hơn. Và nhiều phần công việc vui hơn, dù có vài thứ phải buông. Nhìn toàn bộ hệ thống, bạn sẽ thấy rất nhiều tự động hoá nằm ở khâu ingest, classification và ưu tiên, vốn từng là những cuộc họp bất tận mà engineer bị ép phải dự. Nên đúng là có vài thứ anh thích mà giờ không làm nữa, nhưng cũng có cả đống thứ anh ghét mà giờ không phải làm.

## 18. Hết thời craftsmanship chưa, và lời kết

Dragos hỏi tiếp: liệu có quá lời không nếu nói thời đại của software craftsmanship đã hết, và ta đang bước vào thời đại của kỹ thuật đúng nghĩa, giống sản xuất hàng loạt hơn?

Bogdan trả lời: chắc chắn có một khía cạnh của sự thủ công hằng ngày đã mất, nhưng ở cốt lõi bạn vẫn phải rất đam mê và rất khéo tay. Tự build một state machine, anh nghĩ, là một bài tập tốt. Bạn sẽ luôn làm những việc kiểu đó, nhưng không phải để giao hàng. Bạn làm để cải thiện phán đoán của mình, thứ rốt cuộc cải thiện cả phần mềm. Nên bạn tự thử thách mình nhiều hơn. Nhưng anh nghĩ người thợ thủ công vẫn còn đó khi bạn build và thiết kế một sản phẩm: ta không xuất xưởng cùng một chiếc xe hết lần này tới lần khác. Nên ý tưởng rằng sẽ có sản xuất hàng loạt thì không đúng. Đây vẫn là một bài tập thiết kế. Bạn build một sản phẩm liên tục thay đổi, không phải cùng một thứ chạy mãi trên băng chuyền.

Về bộ kỹ năng, anh nói bạn chắc chắn cần nền tảng. Nhưng giờ bạn còn phải biết cloud, biết một chút kiến trúc, biết thuật toán, biết một chút system design, nhưng biết nhiều về API design chẳng hạn, hoặc end-to-end testing. Bạn phải trở nên end-to-end hơn: thời đại siêu chuyên môn hoá đã hết. Tuy vậy, điều anh thấy sau khi chạy hệ thống này trên production là: mỗi khi mọi thứ đi rất tệ, bạn vẫn cần kiến thức chuyên sâu đó. Ví dụ ở tầng UI, bạn có thể vá rồi đi tiếp, nhưng nếu muốn thứ gì tốt hơn hẳn, bạn phải vào chế độ kỹ thuật, làm như một front end engineer thực thụ đi vào thiết kế một design system. Backend cũng gần như vậy: muốn một hệ thống tốt hơn hẳn, bạn phải đi từ monolith sang microservices. Nên mỗi khi bắt đầu giải những bài toán khó, bạn vẫn cần chuyên môn hoá.

Cảm nhận của anh là người ta đang nói về vibe coding, và họ vibe code mọi thứ vì không thật sự quan tâm tới chất lượng hay tới người dùng. Họ đặt rất nhiều gánh nặng lên người dùng: release thứ đầy bug, rồi người dùng báo lỗi, rồi họ đưa báo lỗi đó vào agent. Nhưng anh nghĩ trong tương lai người dùng sẽ khó tính hơn nhiều. Họ sẽ muốn thứ có chất lượng cao hơn. Và nếu bạn muốn chất lượng và tính dự đoán được, bạn cần kỹ thuật.

Dragos đồng ý: rốt cuộc, chính người dùng trả giá cho việc bạn không build phần mềm chất lượng. Mỗi lần chuyện đó xảy ra, một chút niềm tin của người dùng lại mất đi, cho tới khi bạn mất khách hàng, điều mà rất nhiều công ty đang gặp ngay lúc này. Anh tin người dùng sẽ hoài nghi hơn trước rất nhiều. Nhưng nhìn vào hệ thống này, anh thấy đây gần như là sự kết hợp hoàn hảo giữa nền tảng software engineering, cả cấp cao lẫn cấp thấp, với những gì AI và agent làm được: một kiểu cộng sinh hoàn hảo, nhìn vào thấy đẹp. Nếu đưa thứ này cho một developer của năm năm trước, họ sẽ năng suất hơn; và giả sử họ build đúng thứ cần build, công ty sẽ vượt lên. Nên đây là một tương lai thú vị.

Ý khép lại video: mỗi khối của nhà máy có hai lớp, phần tự động hoá bằng AI và phần nền tảng software engineering giữ cho khối đó vững trong toàn bộ "hậu cần" của nhà máy.

Dragos nói anh rất muốn đi sâu vào từng khối, vì mỗi khối lại có phần tự động hoá và AI, và phần nền tảng kỹ thuật, cùng câu hỏi làm sao build cho chắc để các khối vững trong toàn bộ hậu cần của nhà máy. Nhưng video không đủ thời gian. Anh mời người xem để lại bình luận nếu muốn anh và Bogdan làm phần hai đi sâu vào từng khối. Cuối video có vài lời mời tham gia các chương trình đào tạo và mentorship của kênh. Anh cảm ơn Bogdan và hẹn gặp lại mọi người ở video sau.

## Nguồn và liên kết

- Tên gốc: software factory explained by a Senior Engineer (step by step)
- Sự kiện: [YouTube](https://homus.dev/events/youtube)
- Video gốc: [https://www.youtube.com/watch?v=WOhJflEz3mY](https://www.youtube.com/watch?v=WOhJflEz3mY)

- Kênh YouTube theSeniorDev (Bogdan Nedelcu & Dragos Nedelcu): [youtube.com/channel/UC07G4rT6ZvDv0lokaVHKeQw](https://www.youtube.com/channel/UC07G4rT6ZvDv0lokaVHKeQw)

- Trang giới thiệu đội ngũ theSeniorDev (Dragos Nedelcu, Senior Engineer & Co-Founder; Bogdan Nedelcu, Principal Engineer & Co-Founder): [theseniordev.com/about-us](https://www.theseniordev.com/about-us/)

- Fallow, công cụ phân tích codebase TypeScript và JavaScript (complexity, duplication, code không dùng tới): [github.com/fallow-rs/fallow](https://github.com/fallow-rs/fallow)

- Bộ skill chính thức của Vercel cho agent: [github.com/vercel-labs/agent-skills](https://github.com/vercel-labs/agent-skills)

- Tài liệu Claude Code về CLAUDE.md và cách Claude nhớ project: [code.claude.com/docs/en/memory](https://code.claude.com/docs/en/memory)

- Playwright, công cụ end-to-end test agent dùng để tái hiện lỗi và quay video: [playwright.dev](https://playwright.dev/)

- AWS Amplify, nơi chạy front end và các môi trường theo branch: [aws.amazon.com/amplify](https://aws.amazon.com/amplify/)

- TLA+, ngôn ngữ đặc tả cho formal verification ghi trên bảng: [lamport.azurewebsites.net/tla/tla.html](https://lamport.azurewebsites.net/tla/tla.html)

- Bend, ngôn ngữ Bogdan nhắc tới (repo mô tả là "a fast language that blocks AI mistakes via proof"): [github.com/HigherOrderCO/Bend](https://github.com/HigherOrderCO/Bend)

- Bài ra mắt Jev của TypeSafe, model cho output có kiểu: [typesafe.ai/blog/introducing-system-one-models-and-jev](https://typesafe.ai/blog/introducing-system-one-models-and-jev)

Nguồn: https://homus.dev/talks/software-factory-explained-by-a-senior-engineer-step-by-step · cập nhật 2026-10-18