# Senior engineer đang dùng AI sai cách, và ẩn dụ software factory là sai

[Joe Maddalone](https://homus.dev/speakers/joe-maddalone) · [Joe Maddalone](https://homus.dev/orgs/joe-maddalone)

> Best practice nào là nguyên lý, cái nào chỉ là cách chữa cho chi phí code do người viết, và vì sao ẩn dụ software factory là sai.

Topics: Software Factory, Coding Agents, Workflow

Canonical: https://homus.dev/talks/senior-engineers-are-using-ai-wrong-and-software-factories-are-dumb

## 1. Những cuốn sách lịch sử máy tính và Marvin Minsky

Joe Maddalone mở đầu video bằng mấy cuốn sách trên tay: "Đây là sách. Với những bạn có thể chưa biết, sách giống như podcast nhưng ở dạng in." Một số cuốn trong đó viết về lịch sử ngành máy tính. Điều anh để ý là các câu chuyện ấy có một điểm chung: luôn có một người bị bỏ lại phía sau, vì họ không nhìn được xa hơn những gì mình đã biết.

Ví dụ anh đưa ra là Marvin Minsky, một nhân vật quan trọng trong cuốn Genius Makers. Theo Joe, Minsky là một trong những người tiên phong đầu tiên của trí tuệ nhân tạo, nhưng ông lại rất hoài nghi neural network, chủ yếu vì ông không hình dung nổi một cỗ máy có thể tạo ra một ý tưởng mới mà nó chưa từng được dạy một cách tường minh trước đó. Và cũng theo Joe (video đăng ngày 30/10/2026), gần như một mình Minsky đã gây ra cái mà ngày nay người ta gọi là "AI winter" (mùa đông AI).

![Ảnh đen trắng Marvin Minsky ngồi cạnh một cánh tay robot và các khối gỗ, kèm một câu trích dẫn](https://homus.dev/photos/4Oq_gdhjYUw-0043.jpg)

Ảnh đen trắng Marvin Minsky bên một cánh tay robot xếp khối gỗ. Trên màn hình là câu trích dẫn: "If you just have a single problem to solve, then fine, go ahead and use a neural network. But if you want to do science and understand how to choose architectures..."

Với Joe (video đăng ngày 30/10/2026), đó là một ví dụ tuyệt vời cho thấy ngay cả những người xuất chúng cũng có thể chật vật khi phải tưởng tượng ra một tương lai không khớp với mental model (mô hình tư duy) hiện có của họ.

## 2. Sách công thức và sách nguyên lý

Cuốn tiếp theo Joe giơ lên là Refactoring của Martin Fowler. Trong video đăng ngày 30/10/2026, anh gọi đó là một cuốn sách phát triển phần mềm được yêu mến, nhưng phần lớn nó giống một cuốn sách công thức nấu ăn: anh có thể rút nó khỏi kệ, tra một kỹ thuật, áp dụng, rồi đặt lại chỗ cũ là xong.

Còn hai cuốn kia, The Phoenix Project và The Pragmatic Programmer (cuốn sau là một trong những cuốn anh thích), thì theo anh (video đăng ngày 30/10/2026) nói về nguyên lý của phát triển phần mềm. Chúng dạy qua ngụ ngôn và ẩn dụ: cách nghĩ về phát triển phần mềm, cách tiếp cận vấn đề, cách ra quyết định tốt hơn, và cách trở thành một kỹ sư giỏi hơn.

Hai kiểu sách Joe phân biệt trong video đăng ngày 30/10/2026: một bên là công thức tra cứu, một bên là nguyên lý được dạy qua ẩn dụ.

Lý do, theo anh (video đăng ngày 30/10/2026), là chúng ta có xu hướng hiểu công nghệ mới bằng cách so sánh nó với thế giới mình đã biết.

## 3. Mã lực, cái bàn làm việc và icon đĩa mềm

Ví dụ đầu tiên Joe đưa ra (video đăng ngày 30/10/2026): công suất động cơ xe hơi của bạn nhiều khả năng được đo bằng mã lực (horsepower). Đó là một dấu vết rõ ràng của phương tiện đi lại chủ đạo trước khi có ô tô, tức là con ngựa.

Ví dụ thứ hai: theo Joe (video đăng ngày 30/10/2026), tới nay chúng ta vẫn giả vờ rằng máy tính là những chiếc bàn làm việc nhỏ. Máy tính có document, có tủ hồ sơ, có sổ địa chỉ, có một thùng rác nhỏ và một clipboard, vì đó là một ẩn dụ vững chắc giúp ích cho con người.

Ví dụ thứ ba là icon Save quen thuộc ở khắp nơi: nó là hình chiếc đĩa mềm 3,5 inch. Với cả một thế hệ người dùng máy tính, điều đó hoàn toàn hợp lý. Họ biết đó là hình một chiếc đĩa mềm, và họ biết lưu một thứ gì đó vào đĩa mềm nghĩa là gì. Nhưng theo Joe (video đăng ngày 30/10/2026), ngày nay có những người trưởng thành chưa từng tận mắt thấy một chiếc đĩa mềm. Họ nhận ra icon ấy không phải vì nó đại diện cho thứ họ từng chạm vào, mà chỉ vì họ đã học được ý nghĩa của nó, tức ý định và nghĩa đằng sau nó. Ẩn dụ đã sống lâu hơn chính thứ mà nó đại diện.

![Một chiếc đĩa mềm cũ trưng bày trong tủ kính bảo tàng, bên cạnh là điện thoại hiện icon đĩa mềm](https://homus.dev/photos/4Oq_gdhjYUw-0243.jpg)

Hình minh hoạ Joe dùng cho ý "ẩn dụ sống lâu hơn thứ nó đại diện": chiếc đĩa mềm thật nằm trong tủ kính bảo tàng, còn icon của nó vẫn sáng trên màn hình điện thoại.

Theo Joe (video đăng ngày 30/10/2026), những ẩn dụ này có tác dụng thật. Chúng làm công nghệ dễ tiếp cận hơn bằng cách mượn từ thế giới mà con người đã hiểu. Nhưng chúng cũng định hình những gì người ta chờ đợi ở máy tính. Chúng ta xây giao diện quanh các ẩn dụ đó, hình thành thói quen quanh các giao diện đó, rồi dần dần coi những thói quen đó như thể chúng là thuộc tính vốn có của ngành máy tính.

Nhưng Joe nói (video đăng ngày 30/10/2026) chúng không phải thuộc tính nền tảng của máy tính. Chúng là những quyết định thiết kế được thừa hưởng từ thời mà chúng ta cần làm cho máy tính dễ hiểu hơn với một người chưa từng dùng máy tính bao giờ.

## 4. Ẩn dụ tạo ra mental model, mental model tạo ra thói quen

Nói ngắn gọn, theo Joe (video đăng ngày 30/10/2026): một ẩn dụ như "desktop", một ẩn dụ hay, sẽ định hình một mental model, và mental model đó định hình thói quen. Khi mental model đúng, thói quen đúng. Và tương tự, khi mental model sai, thói quen cũng sai.

Chuỗi nhân quả Joe nêu trong video đăng ngày 30/10/2026: ẩn dụ định hình mental model, mental model định hình thói quen.

Trong video đăng ngày 30/10/2026, anh dùng hình ảnh bánh xe phụ (training wheels) của xe đạp. Khi dựa vào bánh xe phụ, có thể đến một lúc chúng ta quên mất rằng bánh xe phụ là thứ tháo ra được. Và bạn có thể thấy mình đang bảo vệ những quyết định thiết kế đưa ra từ thập niên 1970 hay 1980 như thể chúng là định luật vật lý.

![Tranh vẽ một người đàn ông trưởng thành đạp chiếc xe đạp nhỏ có bánh xe phụ](https://homus.dev/photos/4Oq_gdhjYUw-0401.jpg)

Tranh vẽ một người lớn vẫn đạp xe có bánh xe phụ, minh hoạ cho ý của Joe trong video đăng ngày 30/10/2026: ta dễ quên rằng bánh xe phụ vốn tháo ra được.

## 5. Best practice được sinh ra từ chi phí

Theo Joe (video đăng ngày 30/10/2026), rất nhiều best practice và thói quen kỹ thuật phần mềm tốt của chúng ta được rút ra từ chi phí phát triển, bảo trì và phối hợp phần mềm do con người viết. Nhưng AI đang thay đổi tận gốc bài toán kinh tế của phát triển phần mềm, và điều đó lẽ ra phải khiến một số best practice thôi còn hợp lý.

![Hình nền kiểu bản vẽ kỹ thuật màu xanh với dòng chữ Best practices are based on cost, hai bánh răng và một khối ghi Cost](https://homus.dev/photos/4Oq_gdhjYUw-0443.jpg)

Hình kiểu bản vẽ kỹ thuật với dòng chữ "Best practices are based on cost": hai bánh răng đẩy một khối có nhãn "Cost". Đây là luận điểm Joe đặt ra trong video đăng ngày 30/10/2026.

Thế nhưng, mỗi khi anh nhìn vào một app được gọi là "vibe coded" (tính đến video đăng ngày 30/10/2026), anh lại thấy đúng y những best practice cũ đó được implement. Với anh, đó là dấu hiệu cho thấy chúng ta chưa thật sự sẵn sàng buông các mental model cũ, và anh nói rõ là kể cả chính anh.

## 6. Người thợ thủ công, DRY và cái giá của trùng lặp

Joe lấy lại cuốn The Pragmatic Programmer làm ví dụ. Theo anh, toàn bộ triết lý của cuốn sách, và thật lòng là toàn bộ truyền thống phát triển phần mềm hiện đại, dựa trên hình ảnh người lập trình như một người thợ thủ công (craftsman): tự tay đánh bóng từng function, ám ảnh với clean code, và tuân thủ những nguyên tắc nghiêm ngặt như DRY, "Don't repeat yourself" (đừng lặp lại chính mình).

Theo Joe (video đăng ngày 30/10/2026), lối nghĩ đó hoàn toàn hợp lý khi mỗi ký tự trên màn hình đều do một bàn tay người gõ ra, và mỗi bug trong tương lai đều có nghĩa là một con người phải đọc và phân tích đúng đoạn code đó bằng chính mắt người của mình.

![Hình pixel với dòng chữ Human eyes read every bug, sáu khung code giống nhau và dòng 8 copies, 8 bug hunts](https://homus.dev/photos/4Oq_gdhjYUw-0543.jpg)

Hình minh hoạ "Human eyes read every bug": nhiều bản sao của cùng một đoạn code, kèm dòng "8 copies, 8 bug hunts". Đây là logic chi phí cũ đằng sau DRY mà Joe mô tả.

Nhưng theo Joe (video đăng ngày 30/10/2026), nếu AI có thể refactor hoặc vứt bỏ, chẳng hạn, 500 dòng boilerplate trong bốn giây, thì cái giá của sự trùng lặp (duplication) đã thay đổi. Cái giá của abstraction cũng thay đổi. Vậy nên bỗng nhiên, việc bỏ ra ba tiếng đồng hồ để tự tay đánh bóng cái class hierarchy siêu module hoá tinh tươm của bạn không còn là tay nghề nữa. Đó là hoài niệm.

Trong lúc anh nói về abstraction, màn hình (video đăng ngày 30/10/2026) hiện một hình có tiêu đề "My Amazing Framework, 100% Abstraction", với một đường cong đánh số từ 1 tới 5: Bannana, Gorilla, Trees, Jungle, Continent.

## 7. Không còn là thợ mộc, mà là nhà quy hoạch đô thị

"Chúng ta không còn là thợ mộc nữa", Joe nói trong video đăng ngày 30/10/2026. Chúng ta giống với những nhà quy hoạch đô thị (urban planner) hơn. Một nhà quy hoạch đô thị không bận tâm tới thớ gỗ chính xác trên một băng ghế công viên. Họ quan tâm tới luồng giao thông và công suất của hạ tầng tiện ích. Việc họ làm là đặt ra ranh giới, áp đặt các ràng buộc, và định hướng sự phát triển.

![Đôi tay đang vẽ bản quy hoạch một thành phố hình rẻ quạt, các trục đường chính tô màu đỏ](https://homus.dev/photos/4Oq_gdhjYUw-0623.jpg)

Một nhà quy hoạch vẽ trục đường chính trên bản đồ thành phố: hình ảnh Joe dùng trong video đăng ngày 30/10/2026 cho vai trò mới của kỹ sư, lo ranh giới và luồng giao thông, không lo thớ gỗ.

Theo Joe (video đăng ngày 30/10/2026), khi công cụ của bạn viết code thay bạn, giá trị của bạn với tư cách một kỹ sư không còn nằm ở khả năng viết cú pháp sạch. Nó nằm ở khả năng diễn đạt ý định rõ ràng (express clear intent), đánh giá các trade-off, và định hướng sự phát triển. Theo lời anh, thuật ngữ đang được dùng cho việc này (tính đến video đăng ngày 30/10/2026) là "design engineering". Trên màn hình lúc đó lần lượt hiện các dòng chữ "You don't write code?", "Express intent" và "Direct growth".

Và nếu bạn vẫn đối xử với phát triển phần mềm như thể đang tự tay khắc một khúc gỗ, thì theo Joe (video đăng ngày 30/10/2026), bạn đang chăm chăm vào một băng ghế trong khi cả thành phố xung quanh bạn đang cháy.

![Tranh vẽ một người cặm cụi gọt một băng ghế gỗ trong công viên, phía sau là thành phố đang bốc cháy](https://homus.dev/photos/4Oq_gdhjYUw-0703.jpg)

Hình minh hoạ cho câu "focused on a bench while the city around you burns": một người mải gọt băng ghế gỗ, sau lưng là những toà nhà đang cháy (video đăng ngày 30/10/2026).

## 8. Tủ hồ sơ và cách tổ chức code theo ngữ nghĩa

Điều đó đưa Joe quay lại với những ẩn dụ mà chúng ta dường như không thể buông, bắt đầu từ cách chúng ta tổ chức công việc. Theo anh (video đăng ngày 30/10/2026), suốt nhiều thập kỷ, chúng ta đã kiểu giả vờ rằng phần mềm của mình sống trong những chiếc tủ hồ sơ vật lý. Chúng ta tạo thư mục, thư mục con, các đường dẫn lồng nhau, tất cả để phục vụ một mental model dựa trên tổ chức theo không gian (spatial organization): ý tưởng rằng muốn tìm một thứ, hay muốn hiểu một hệ thống chạy thế nào, bạn cần biết nó nằm ở đâu trong một kiểu lưới nào đó.

Nhưng theo Joe (video đăng ngày 30/10/2026), các large language model và vector database "chẳng thèm quan tâm" rằng helper function của bạn bị chôn sâu ba cấp trong một thư mục tên là `utils`. Chúng đánh giá code dựa trên ngữ cảnh ngữ nghĩa (semantic context): code thực sự mang ý nghĩa gì, nó làm gì, và nó liên quan thế nào tới vấn đề đang giải, bất kể nó nằm ở đâu trên ổ đĩa.

![Thẻ có tiêu đề The vector way, Chunk it. Embed it. Ask it., với ba bước Chunks, Vector space, Nearest wins](https://homus.dev/photos/4Oq_gdhjYUw-0746.jpg)

Thẻ minh hoạ "The vector way: Chunk it. Embed it. Ask it." với ba bước Chunks, Vector space, Nearest wins. Ngay trước đó là thẻ "Lost in the folders" rồi thẻ "The price of looking: Fourteen files. Zero answers." Đây là phần so sánh Joe đưa ra trong video đăng ngày 30/10/2026.

Và theo Joe (video đăng ngày 30/10/2026), dù anh thấy rất nhiều kỹ sư nói "tôi không còn đọc code nữa" (trên màn hình hiện câu "I don't even read the code, bro."), có vẻ họ vẫn tốn rất nhiều công sức dạy AI sắp xếp code đó theo một cái nạng (crutch) mà chúng ta phát minh ra từ năm 1985 để giải quyết vấn đề trí nhớ ngắn hạn rất con người của chính mình.

Theo Joe (video đăng ngày 30/10/2026), chúng ta đơn giản là chưa chuyển từ mental model tổ chức theo không gian sang mental model mới dựa trên ngữ nghĩa. Chúng ta vẫn đối xử với thế giới số của mình như một chồng giấy tờ trong tủ hồ sơ.

## 9. Cái bẫy "AI chỉ hữu ích cho senior"

"Được rồi, đây là chỗ tôi sẽ làm mất lòng rất nhiều người trong các bạn", Joe nói, "nên tôi nói trước luôn: xin lỗi, nhưng không hối hận đâu."

Theo anh, nếu bạn để ý những cuộc bàn luận quanh AI và chuyện viết code tính đến lúc quay video (đăng ngày 30/10/2026), có một câu chuyện đang chiếm lĩnh: công cụ AI chỉ hữu ích nếu bạn đã là một senior software developer. Lập luận đi như sau: bạn cần một nền tảng phát triển phần mềm sâu rộng để bắt được lỗi của AI, và bạn cần biết mọi pattern phát triển phần mềm kinh điển để giữ cho hệ thống không chệch đường ray. Và theo Joe, vào thời điểm video được quay, đây chắc chắn là những tiếng nói to nhất trong phòng: các senior engineer nhìn những công cụ này và nói "nhìn xem tôi làm những việc mình vốn đã biết nhanh hơn bao nhiêu".

Bề ngoài thì nghe có vẻ hợp lý, nhưng Joe gọi đó là một cái bẫy. Theo anh (video đăng ngày 30/10/2026), khi một developer dày dạn dùng AI, họ có xu hướng dùng nó như một công cụ autocomplete siêu hiệu quả cho chính mental model của mình. Họ viết đúng những design pattern và kiến trúc mà họ đã viết từ năm 2008, chỉ là nhanh hơn. Họ không hình dung lại công việc. Họ chỉ tiếp thêm sức mạnh cho đống hành lý và thói quen mà họ mang theo vào công việc.

Cái bẫy Joe mô tả trong video đăng ngày 30/10/2026: AI trở thành autocomplete cho mental model cũ, nên đầu ra vẫn là kiến trúc cũ, chỉ nhanh hơn.

Trên màn hình lúc này hiện dòng chữ "AI agent: I do TDD so hard!", bên dưới là một dòng kèm một từ tục.

## 10. Những người sẽ đưa nghề sang kỷ nguyên mới

Theo Joe (video đăng ngày 30/10/2026), những người sẽ đưa chúng ta sang kỷ nguyên phát triển phần mềm tiếp theo không phải là những người đi lại với 20 năm best practice mắc kẹt trong đầu. Họ là những người không biết đĩa mềm là gì, và họ không gắn bó cảm xúc với DRY hay các kỹ thuật refactor truyền thống.

Trên màn hình lúc đó hiện dòng chữ "Hire a junior", bên dưới là "they come with less" kèm một từ tục.

Họ không phải tốn nhiều sức để gỡ bỏ (unlearn) 40 năm giáo điều phát triển phần mềm, và họ không cố ép AI vào một workflow cũ. Theo Joe (video đăng ngày 30/10/2026), họ hoàn toàn tự do phát minh ra những cách hoàn toàn mới để làm việc với code, từ con số không.

Hai nhóm người Joe đặt cạnh nhau trong video đăng ngày 30/10/2026.

Và theo anh (video đăng ngày 30/10/2026), điều đó dẫn tới cái bẫy mới nhất mà tất cả chúng ta sắp sa vào: software factory.

## 11. Software factory: CI/CD đã là dây chuyền, phần còn lại thì sao

Theo Joe (video đăng ngày 30/10/2026), trong khoảng 20 năm, xê dịch chút ít, ngành phần mềm đã kiểu bị ám ảnh với việc biến quy trình phát triển phần mềm thành một dây chuyền lắp ráp (assembly line). Và chúng ta đã thành công được một nửa: CI/CD chạy tốt. Nó rất giống một dây chuyền lắp ráp hay một nhà máy. Một khi đã dựng xong, chúng ta không lo lắng gì nhiều về nó. Việc test, build và deploy một ứng dụng chạy rất tốt.

![Sơ đồ CI/CD From commit to production với năm bước Commit, Build, Test, Staging, Production đều có dấu tích xanh](https://homus.dev/photos/4Oq_gdhjYUw-1103.jpg)

Một commit đi qua Commit (git push), Build (compile), Test (unit + e2e), Staging (preview env) rồi Production (deploy), mỗi cửa phải qua thì mới đi tiếp. Đây là nửa "nhà máy" mà Joe nói đã chạy tốt, theo video đăng ngày 30/10/2026.

Nhưng theo anh (video đăng ngày 30/10/2026), chúng ta đang đứng trước một bước nhảy mới và nguy hiểm: biến toàn bộ vòng đời phát triển phần mềm thành một quy trình dây chuyền lắp ráp. Và dây chuyền đó sẽ được lấp đầy bởi các AI agent được huấn luyện trên những mental model cũ. Trong đoạn này, màn hình lướt qua thumbnail của nhiều video khác cùng nói về "software factory" và một hình nhà máy toàn robot đứng máy.

Theo Joe (video đăng ngày 30/10/2026), bạn có thể hình dung một kiểu đầu vào nào đó, nơi một product manager thả vào một bản đặc tả (specification), rồi một dây chuyền AI bắt đầu nhả ra code, và ở đầu bên kia lăn ra một sản phẩm hay ứng dụng hoàn chỉnh.

![Thẻ Output, code rolls off the line, The line spits out code, các khối code chạy vào một thư mục main có dấu tích](https://homus.dev/photos/4Oq_gdhjYUw-1143.jpg)

Phần cuối của hình minh hoạ dây chuyền AI: sau thẻ "It starts with a spec" là "The line spits out code", các khối code chạy vào nhánh `main`. Đây là mental model "spec vào, phần mềm ra" mà Joe phản bác trong video đăng ngày 30/10/2026.

Theo Joe, đó là một mental model rất hấp dẫn nếu bạn tin rằng lợi thế của developer hiện đại là tốc độ implement. Nhưng nó cũng sai hoàn toàn. Lợi thế của developer hiện đại, theo anh (video đăng ngày 30/10/2026), không phải là tốc độ. Đó là gu (taste), là khả năng kiểm chứng (verification), và là việc đánh giá các edge case.

## 12. Bài viết của Rob West: bốn chỗ ẩn dụ nhà máy gãy

Joe kể nhanh rằng trong lúc research để chuẩn bị cho video này, anh đã tìm xem có ai khác ngoài kia cảm thấy giống anh về chuyện này không. Và anh bắt gặp bài viết "The Agentic Software Factory is the Wrong Metaphor" (software factory dùng agent là một ẩn dụ sai). Anh nói bài này ra đời khoảng một tháng trước khi quay video, do Rob West viết; trang bài viết ghi ngày đăng 19/09/2026 (đọc ngày 30/10/2026).

![Trang bài viết The Agentic Software Factory is the Wrong Metaphor trên site của Rob West, Published 19 Sept 2026](https://homus.dev/photos/4Oq_gdhjYUw-1203.jpg)

Đầu bài viết của Rob West, ghi "Published 19 Sept 2026" với các tag AI, Engineering Leadership, Patterns and Practices. Đoạn mở bài nhắc lại rằng năm 2019 ông đã viết "coders are creatives, not factory workers", và bảy năm sau "nhà máy" quay lại, lần này công nhân trên dây chuyền là AI agent. Joe đọc bài này trong video đăng ngày 30/10/2026.

Joe nói anh sẽ diễn giải lại một chút, vì Rob đã viết ra điều này hay hơn nhiều so với việc anh sắp nói lan man. Bốn ý anh tóm lại từ bài viết (theo bài của Rob West, đăng 19/09/2026, và lời diễn giải của Joe trong video đăng ngày 30/10/2026):

- **Nhà máy mặc định rằng thiết kế đã được giải xong.** Nhưng việc tìm ra cần build cái gì và nó nên hành xử thế nào mới chính là công việc. Một ticket không phải là một bản thiết kế chi tiết (blueprint). (Theo bài của Rob West, đăng 19/09/2026.)

- **Quá trình phát triển phần mềm làm thay đổi hiểu biết của chúng ta về đặc tả ngay trong lúc build.** Nó không phải "spec vào, phần mềm ra". Design engineering làm đặc tả tiến hoá dần khi ta hiểu thêm về vấn đề. (Theo bài của Rob West, đăng 19/09/2026.)

- **Dây chuyền lắp ráp sinh ra để loại bỏ biến thể.** Design engineering thì được lợi từ biến thể: đó là cách chúng ta so sánh, thử nghiệm và tìm ra cách tiếp cận tốt hơn. (Theo bài của Rob West, đăng 19/09/2026.)

- **Nhà máy thì phải được "nuôi".** Điều đó tạo áp lực phải hình thức hoá yêu cầu trước khi ta hiểu vấn đề. Và sự mơ hồ không tự biến mất: các agent sẽ lấp khoảng trống bằng những phỏng đoán tốt nhất của chúng, và rất tự tin tạo ra một thứ sai. (Theo bài của Rob West, đăng 19/09/2026, và lời Joe trong video đăng ngày 30/10/2026.)

![Đoạn bài viết của Rob West với đoạn thứ ba về variation được tô sáng](https://homus.dev/photos/4Oq_gdhjYUw-1303.jpg)

Joe cuộn qua bài và tô sáng từng đoạn khi đọc; ở đây là đoạn thứ ba: sản xuất vận hành để loại bỏ biến thể, còn thiết kế lại dựa vào biến thể. Bài của Rob West đăng 19/09/2026, đọc trong video đăng ngày 30/10/2026.

Bốn ý Joe diễn giải từ bài của Rob West (đăng 19/09/2026) trong video đăng ngày 30/10/2026.

## 13. Ẩn dụ thế kỷ 19 cho một bước chuyển thế kỷ 21

Theo Joe (video đăng ngày 30/10/2026), vấn đề của software factory không nằm ở chỗ công nghệ tệ. Vấn đề là chúng ta đang áp một mental model công nghiệp của thế kỷ 19 lên một bước chuyển nhận thức của thế kỷ 21.

Và giống như Marvin Minsky đã không nhìn được xa hơn những giả định của mình về cách máy móc sẽ học, Joe cho rằng (video đăng ngày 30/10/2026) chúng ta có nguy cơ bỏ lỡ sức mạnh thật sự của những công cụ này, vì quá mải bắt chúng hành xử như những công nhân dây chuyền nhanh hơn. Chúng ta sẽ dùng một công nghệ mang tính đột phá chỉ để làm những việc sai nhanh hơn.

Những cuốn sách kinh điển, anh nói, đã đưa chúng ta tới được đây. Chúng cho ta những mental model và ẩn dụ cần thiết để sống sót qua kỷ nguyên đầu tiên của phát triển phần mềm. Nhưng theo Joe (video đăng ngày 30/10/2026), khi những công cụ mới này viết lại mức nền của việc build phần mềm là gì, việc bám lấy các ẩn dụ cũ sẽ không biến chúng ta thành kỹ sư giỏi hơn. Nó sẽ để chúng ta đứng lại trên một dây chuyền lắp ráp, sản xuất ra những thứ cho một thế giới đã đi tiếp từ lâu.

Đối lập Joe dùng để kết video đăng ngày 30/10/2026: ẩn dụ nhà máy của thế kỷ 19 so với bước chuyển nhận thức của thế kỷ 21.

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

- Tên gốc: Senior Engineers Are Using AI Wrong and Software Factories Are Dumb
- Sự kiện: [YouTube](https://homus.dev/events/youtube)
- Video gốc: [https://www.youtube.com/watch?v=4Oq_gdhjYUw](https://www.youtube.com/watch?v=4Oq_gdhjYUw)

- Kênh YouTube Joe Maddalone (Joe Maddalone): [youtube.com/channel/UCutKx7_WN6r2iduofUe7mlw](https://www.youtube.com/channel/UCutKx7_WN6r2iduofUe7mlw)

- Rob West, "The Agentic Software Factory is the Wrong Metaphor", đăng 19/09/2026 (đọc ngày 30/10/2026): [robwest.info/articles/the-agentic-software-factory-is-the-wrong-metaphor](https://robwest.info/articles/the-agentic-software-factory-is-the-wrong-metaphor/)

Nguồn: https://homus.dev/talks/senior-engineers-are-using-ai-wrong-and-software-factories-are-dumb · cập nhật 2026-10-30