Khi AI Viết Code, Engineering Đi Về Đâu? 9 Phát Hiện Từ Retreat Của ThoughtWorks

Nếu AI viết code, engineering đi về đâu?

Tháng 2/2026, ThoughtWorks tổ chức một retreat quy tụ các chuyên gia engineering cấp cao từ những công ty công nghệ lớn, để đối mặt với câu hỏi quan trọng nhất khi AI tái định hình cách chúng ta xây dựng phần mềm. Hơn 20 chủ đề được thảo luận qua các phiên breakout, theo luật Chatham House — không tiết lộ tên người tham dự hay tổ chức của họ.

Kết quả không phải một tầm nhìn thống nhất, mà là thứ hữu ích hơn: một bản đồ các đường đứt gãy (fault lines) — nơi thực hành hiện tại đang vỡ ra và thực hành mới đang hình thành. Câu hỏi lặp lại ở mọi phiên: "Nếu AI xử lý code, thì engineering thực sự nằm ở đâu?" — không ai có câu trả lời giống nhau, nhưng ai cũng đồng ý rằng nó cấp bách.

📄 Tài liệu gốc (PDF, 17 trang): The Future of Software Development Retreat — Key Takeaways — ThoughtWorks (tháng 2/2026)

Bản đồ 10 chủ đề theo chân trời thời gian

Chủ đề	Chân trời	Insight cốt lõi
Rigor đi về đâu?	Ngay bây giờ	Chất lượng engineering không biến mất khi AI viết code — nó di cư lên spec, test, constraint và quản lý rủi ro.
Code review bị "gỡ gói"	Ngay bây giờ	4 chức năng của review (mentorship, consistency, correctness, trust), mỗi chức năng cần một "nhà mới".
Nghịch lý productivity/experience	Ngay bây giờ	Năng suất và trải nghiệm developer đang tách rời nhau.
Bảo mật bị xem nhẹ	Ngay bây giờ	Agent security cực kỳ lạc hậu — chỉ cần quyền email là chiếm được toàn bộ tài khoản.
The middle loop	0–1 năm	Loại công việc giám sát mới giữa inner loop và outer loop — chưa ai đặt tên.
Cognitive debt	0–1 năm	Technical debt trở thành cognitive debt: khoảng cách giữa độ phức tạp hệ thống và hiểu biết con người.
Agent topologies	1–3 năm	Conway's Law áp dụng cho cả agent — kiến trúc doanh nghiệp phải tính đến mobility, specialization, drift.
Knowledge graphs & semantic layers	1–3 năm	Công nghệ "ế" hàng chục năm bỗng nhiên hot trở lại làm lớp grounding cho agent.
Tương lai vai trò	1–3 năm	PM/developer/designer hội tụ; staff engineer có kỳ vọng mới; junior giá trị hơn bao giờ hết.
Hệ thống tự phục hồi	2–5 năm	Từ incident response của con người sang agent tự chữa — phải giải bài toán "latent knowledge" trước.

1. "Where does the rigor go?" — câu hỏi quan trọng nhất retreat

Rigor (kỷ luật engineering) không biến mất — nó di cư về 5 điểm đến:

Lên spec review: nhiều practitioner chuyển review từ code sang plan (bản kế hoạch) đi trước nó — "pre-review plans, post-review engineering". User stories truyền thống quá mơ hồ; các team quay lại EARS (Easy Approach to Requirements Syntax), state machines, decision tables — kỹ thuật cũ được "tái phát hiện" vì chúng cho AI agent đủ độ chính xác để sinh code đúng.
Vào test suites như artifact hạng nhất: insight "shareable" nhất của retreat — TDD cho kết quả tốt hơn hẳn từ AI coding agents. Cơ chế cụ thể: TDD chặn lỗi "agent viết test xác nhận hành vi sai". Test có trước code = agent không thể gian lận. Nhiều người chuyển toàn bộ review sang test suite, coi code sinh ra là thứ dùng một lần (disposable).
Vào type systems & constraints: làm cho code sai không thể biểu diễn được (unrepresentable) thay vì review sau khi sinh. Phân biệt quan trọng: specification (mô tả cái gì nên thay đổi) vs constraint (giới hạn bối cảnh, cái gì KHÔNG được đụng — giới hạn blast radius). Khi phải phá constraint → tín hiệu cần ranh giới hệ thống mới → refactor.
Vào risk mapping: phân tầng code theo blast radius (internal tools / external-facing / safety-critical). Câu hỏi mới thay cho "ai đã review code này?": "blast radius nếu code này sai là gì, và mức verification của ta có tương xứng không?" — từ craft model sang risk management model.
Vào continuous comprehension: code thay đổi nhanh hơn con người review được — weekly architecture retrospectives, ensemble programming, AI-assisted code comprehension. Review từng là kênh học chính (mentorship); mất nó mà không thay thế = comprehension gap cộng dồn theo thời gian.

"Tôi có kết quả tốt hơn với TDD + agent coding so với bất cứ nơi nào khác, vì nó chặn một lỗi tư duy cụ thể: agent viết test xác nhận hành vi sai." — Practitioner insight

2. The middle loop — khái niệm first-mover mạnh nhất

Từ trước đến nay có 2 loop: inner (viết/test/debug cá nhân) và outer (CI/CD, deploy, ops). Retreat xác định loop thứ ba: công việc giám sát (supervisory engineering) — điều hướng, đánh giá, sửa output của AI agents. Kỹ năng khác hẳn viết code: phân rã vấn đề thành work packages cỡ agent, hiệu chỉnh trust vào output agent, nhận ra "plausible-looking nhưng sai", duy trì coherence kiến trúc qua nhiều luồng agent song song.

Người giỏi middle loop thường: nghĩ theo delegation & orchestration thay vì implementation trực tiếp; có mental model mạnh về kiến trúc hệ thống; đánh giá nhanh chất lượng output mà không cần đọc từng dòng. Đây là kỹ năng senior thường có, nhưng hiếm khi được phát triển hay công nhận trong career ladder.

Hệ quả nghề nghiệp: khủng hoảng danh tính cho dev "yêu code" — công việc "dịch ticket thành code" đang biến mất. Phép loại suy kinh điển: 1992, kỹ sư code tay thuật toán vẽ polygon; 2 năm sau công việc đó bị đẩy vào hardware, nghề thành animation & lighting. Ai khăng khăng "tôi được thuê để render polygon" thì bị bỏ lại. Cùng động lực đó đang diễn ra với code production. Phía PM cũng bất ổn: một công ty lớn đang nghiên cứu đổi tên vai trò PM; công ty khác huấn luyện toàn bộ PM làm việc trong Markdown + dev tools.

3. Agent topologies — Conway's Law cho agent

Extension của Team Topologies: nếu tổ chức thiết kế hệ thống phản chiếu cấu trúc giao tiếp, thì khi agent thành participant hạng nhất sẽ ra sao? Agent nhân bản tức thì, không friction onboarding — database agent có thể tồn tại ở mọi team cùng lúc. Nhưng 3 vấn đề:

Speed mismatch: agent đốt sạch backlog trong vài ngày rồi đâm vào tường — cross-team dependencies, architecture reviews, ra quyết định với tốc độ con người. Kết quả: cùng tốc độ, thêm frustration — bottleneck dịch từ engineering capacity sang "mọi thứ khác".
Agent drift: agent học từ context sẽ phân kỳ (database agent e-commerce vs ERP dù khởi đầu giống hệt). Tranh luận: quản lý drift (chuẩn hóa) hay chấp nhận (tối ưu local)?
Decision fatigue thành bottleneck mới: agent sinh work nhanh hơn leader duyệt được; middle manager từ điểm phối hợp thành nút thắt phê duyệt. Câu hỏi gai: "nếu con người có giới hạn hiểu hệ thống mà agent không có, ta có cần nhiều middle manager không?" — chưa có đồng thuận, nhưng chính câu hỏi đã là tín hiệu.

"Chúng ta tối ưu quy trình giao phần mềm cho con người. Giờ đây không chỉ có con người, chúng ta phải tự hỏi tổ chức thực sự có nghĩa là gì."

4. Self-healing systems — tham vọng thật, tiền đề chưa có

Phân biệt self-healing (đưa hệ về trạng thái tốt đã biết) vs self-improving (tiến hóa non-functional qualities). Tiền đề hầu hết tổ chức thiếu: ledger của mọi thay đổi, "operating system cho agent" (identity + permission), mitigation generic (rollback, feature flags) không cần sửa code, fitness functions định nghĩa "healthy" theo ngôn ngữ agent đánh giá được.

Kết luận thẳng thừng: code changes nên là phương án cuối cùng cho incident remediation — đường đến self-healing chạy qua rollback/feature flags/observability tốt hơn trước khi qua agent viết lại production code.

Latent knowledge problem: senior engineer nhớ "mã lỗi X thực ra là triệu chứng của vấn đề infrastructure sâu hơn", "CPU cao trên service Y = check connection pool trước". Kiến thức này gần như không bao giờ được ghi chép. Giải pháp: "agent subconscious" — knowledge graph dựng từ năm tháng post-mortems và incident data.
Incident commander problem: commander con người thách thức giả thuyết, đẩy ngược lại; LLM có xu hướng positive reinforcement và đồng tình. Đề xuất: train "angry agents" chuyên phản biện giả thuyết đang thống trị.
Agent coordination risks: feedback loop — fix của agent này kích hoạt correction của agent khác. Ví dụ thực: agent có access linter giới hạn 500 dòng/file → phản ứng bằng cách làm mỗi dòng dài hơn — thỏa mãn luật, vi phạm nguyên tắc.

5. Phía con người — roles, skills, experience

Nghịch lý productivity/experience: DX truyền thống = flow + feedback loops + cognitive load. Giờ tổ chức đạt productivity gain bằng AI trong khi developer báo satisfaction thấp hơn. Reframe sắc bén: đổi tên "developer experience" thành "agent experience" — ví tiền mở nhanh hơn cho thứ giúp agent làm tốt, mà overlap với thứ giúp con người làm tốt gần như hoàn toàn.
Staff engineer dưới áp lực: data từ 500 công ty: staff dùng AI ít hơn junior nhưng khi dùng thì tiết kiệm thời gian/tuần nhiều hơn (context rộng = supervisor tốt hơn). Đề xuất: staff engineer thành "friction killers" — người dọn chướng ngại cho cả người lẫn agent. Vấn đề: learned helplessness sau nhiều năm "không có budget".
Junior giá trị hơn, không phải kém: AI đưa họ qua giai đoạn net-negative ban đầu nhanh hơn; họ là call option trên productivity tương lai; họ dùng AI giỏi hơn senior. Mối lo thật là mid-level engineers thời kỳ hiring boom 10 năm — không có fundamentals, đông nhất ngành, retraining thực sự khó.
Education signal: mô hình co-op University of Waterloo (nền tảng lý thuyết + 2,5 năm internship, 6 rotation 4 tháng) được nhấn mạnh; intern-to-hire giờ outperform graduate recruiting truyền thống.
PM tương lai: không ai định nghĩa được. Rõ một điều: AI phơi bày rối loạn chức năng sẵn có trong quan hệ PM–developer chứ không tạo ra cái mới — chỉ khiến chúng đắt đỏ hơn nếu bị phớt lờ. Tools như "boundary objects" cho phép các vai trò làm việc theo cách riêng mà vẫn shared visibility.

6. Nền tảng kỹ thuật — ngôn ngữ, semantics, agentic OS

Ngôn ngữ cho agent: mọi ngôn ngữ hiện tại đều được thiết kế cho con người. Nguyên tắc hội tụ: "cái gì tốt cho AI thì tốt cho con người" — ngôn ngữ làm code sai unrepresentable giúp cả hai. Tranh luận chia rẽ: source code có thể thành transient artifact (sinh theo yêu cầu, không lưu) — hay deterministic validation bắt buộc phải có artifact ổn định để test, và artifact đó dù gọi tên gì cũng là source code.
Semantic layers & knowledge graphs: công nghệ thất bại suốt hàng chục năm bỗng là lớp grounding cho agent hiểu business domain. Số liệu tạo cảm giác khả thi: ontology toàn bộ domain của một telecom lớn ≈ 286 concepts. Ứng dụng thực tế nhất: legacy modernization — LLM tự nhận diện commands/events/aggregates/policies từ code (auto-generate event storming artifacts), human experts validate, nén tuần discovery workshop thành vài ngày.
Agentic operating system: 4 thành phần — identity & permission management; memory & context-window management; work ledger (work tương lai/hiện tại/quá khứ kèm required skills, acceptance criteria, SLOs, cost constraints); governance paths qua graph capability & compliance. Insight trung tâm: agent = persona + goals + context + lịch sử công việc đã làm; model fungible (đổi LLM được) nhưng đổi model = đổi hành vi agent, phải track. Work ledger = primitive cốt lõi — "analogous to a financial blockchain: searchable, auditable, agent có thể discover và bid work".

7. Security, governance, agile

Security dangerously behind: phiên bảo mật vắng người nhất — bảo mật là chuyện "giải quyết sau". Ví dụ sốc nhất: chỉ cần agent có email access → password reset → account takeover. Giải pháp: platform engineering phải ép secure defaults (safe behavior dễ, unsafe behavior khó). 3 ưu tiên: security by design là baseline không thương lượng, liên minh liên ngành cho interoperable agent security standards, defense AI ngang tốc độ attack AI.
Agile đang tiến hóa, không chết: sprint nén còn 1 tuần + AI tự động hóa ceremony (demo, report); XP được tái khám phá (pair programming, ensemble, CI). Mối đe dọa thật là governance — "faster teams just hit the same walls sooner". Cảnh báo đáng chú ý nhất: stability đang giảm vì batch size tăng — AI dễ sinh changeset lớn → một số team trôi về waterfall pattern — đảo ngược trực tiếp một thập kỷ nghiên cứu DORA (batch nhỏ = stability cao).

8. Agent swarms

Rào cản đầu tiên là tinh thần, không phải kỹ thuật: kỹ sư được đào tạo để phân rã tuần tự khó hình dung work song song. Cách học hiệu quả nhất: chỉ cần yêu cầu agent parallelize và quan sát kết quả.
Nguyên lý thiết kế quan trọng nhất: với enterprise, độ chính xác hoàn hảo của từng agent ít quan trọng hơn sự hội tụ tập thể về mục tiêu — swarm agent "cá nhân không hoàn hảo" vẫn cho outcome giá trị nếu kiến trúc hệ thống dẫn dắt convergence.
Pattern phổ biến nhất không phải swarming: "patrol workers on loops" — agent chạy ETL transforms, data quality checks, business process monitors liên tục 24/7. Tổ chức có API thiết kế tốt được định vị tốt hơn hẳn cho cả hai pattern.
Model limitations: khi chọn model cho agent deployment phải test multi-agent coordination, không chỉ single-agent capability.

9. Open questions — 5 nhóm câu hỏi khiến "căn phòng không ngủ được"

Work & identity: giúp engineer yêu code tìm ý nghĩa trong supervisory work thế nào? Vai trò hội tụ PM–developer gọi là gì, ai sở hữu?
Organizational design: nếu agent làm các nút thắt của middle management hiện rõ hơn → ít manager hơn, manager khác kỹ năng, hay coordination model khác hẳn? Agent đi qua ranh giới team nhưng governance thì không — thiết kế lại thế nào?
Trust & verification: cần điều gì để ngừng review code AI hoàn toàn? Có thế giới nào test + constraints đủ verification không cần mắt người? Làm sao tin hệ thống non-deterministic (cùng input, khác output)?
Knowledge & comprehension: code đổi nhanh hơn người hiểu → model mới cho institutional knowledge? Knowledge graphs có thay được intuition từ năm tháng trong codebase? Đầu tư bao nhiêu cho "agent subconscious"?
Speed & stability: có đang ở regression (productivity gain bị offset bởi stability loss)? Development có phải chậm lại vì volume quyết định vượt capacity con người? Đo cognitive debt thế nào?

Điểm xuyên suốt: 3 pattern xuyên suốt mọi chủ đề

Mọi bottleneck đều dịch chuyển về phía "hiểu biết và quyết định": từ sản xuất code (đã tự động) sang hiểu spec, hiểu hệ thống, phê duyệt, tin tưởng. Rigor, verification, trust đều là các dạng của cùng một nỗi sợ: kiến thức không theo kịp tốc độ tạo ra.
Công nghệ cũ được tái định giá: EARS (2009), TDD (2002), XP (1999), knowledge graphs, event storming — tất cả đều "ế" trước đây vì tốn công người; AI làm chúng rẻ đi, và chúng trở thành ngôn ngữ giao tiếp giữa người và agent.
Vấn đề lớn nhất không phải kỹ thuật: "Đây không phải vấn đề kỹ thuật với giải pháp kỹ thuật. Chúng là vấn đề con người." Danh tính nghề nghiệp, tổ chức, trust — 3 thứ agent không giải quyết hộ được.

Kết luận

Retreat không tạo ra một roadmap — nó tạo ra sự hiểu biết chung rằng tấm bản đồ đang được vẽ lại, và những người ở vị thế tốt nhất để vẽ nó là những người sẵn sàng thừa nhận họ còn biết rất ít. Các ý tưởng sẵn sàng cho thảo luận rộng rãi: supervisory engineering middle loop, risk tiering như kỷ luật engineering cốt lõi mới, TDD như hình thức prompt engineering mạnh nhất, và agent experience reframe cho đầu tư developer experience.

Còn lại là những câu hỏi chưa có lời giải: giúp con người vượt qua cú sốc danh tính nghề nghiệp; quản trị tổ chức nơi agent di chuyển nhanh hơn con người quyết định; xây dựng niềm tin vào hệ thống vốn dĩ non-deterministic. Đây không phải bài toán kỹ thuật — chúng là bài toán con người, cần đối thoại thẳng thắn và hợp tác lâu dài.

📄 Tài liệu tham khảo: The Future of Software Development Retreat — Key Takeaways (PDF) — ThoughtWorks, tháng 2/2026