- Nhóm AI của StrongDM đề xuất khái niệm Software Factory tạo ra phần mềm chất lượng cao mà không cần nhìn vào mã nguồn
- Dựa trên đặc tả/kịch bản, agent viết mã, chạy test harness và hội tụ không cần con người rà soát, theo phương thức phát triển phi đối thoại
- Con người không nên viết hay rà soát mã nguồn, và cần chi ít nhất 1.000 USD tiền token mỗi ngày cho mỗi kỹ sư thì software factory mới vận hành đúng cách
- Từ Claude 3.5 bản sửa đổi lần 2 (tháng 10/2024), workflow viết mã bằng agent dài hạn bắt đầu tích lũy độ chính xác theo lãi kép thay vì tích lũy lỗi, qua đó xác nhận khả năng của phát triển phi đối thoại
- Mở rộng khái niệm test hiện có bằng cách đưa vào scenario (kịch bản) và satisfaction (mức độ thỏa mãn), xây dựng hệ thống để LLM đánh giá xác suất mức độ hài lòng của người dùng
- Thông qua Digital Twin Universe (DTU), nhóm sao chép các SaaS chính như Okta, Jira, Slack để thực hiện kiểm chứng quy mô lớn, cho phép xác minh kịch bản ở mức lưu lượng và tốc độ vượt quá giới hạn production
- Kỷ nguyên agent đang thay đổi tận gốc kinh tế học phần mềm, khiến việc xây dựng bản sao SaaS độ trung thực cao vốn từng phi kinh tế nay trở thành công việc thường nhật
Khái niệm Software Factory
- Đặc tả (specs) và kịch bản (scenarios) vận hành agent để viết và kiểm chứng mã trong một hệ thống phát triển phi đối thoại
- Cấm con người viết và review mã, toàn bộ quá trình phát triển do agent đảm nhiệm
- Đo hiệu quả dựa trên mức tiêu thụ token trên 1.000 USD mỗi ngày cho mỗi kỹ sư
- Cách tiếp cận này nhắm tới việc xây dựng một môi trường sản xuất phần mềm tự trị nơi mã được tự động tạo ra, kiểm chứng và hội tụ mà không cần sự can thiệp của con người
Sự ra đời của nhóm AI StrongDM
- Ngày 14/7/2025, nhóm AI StrongDM được thành lập và bắt đầu thử nghiệm phát triển phi đối thoại
- Thành viên tham gia: Jay Taylor, Navan Chauhan, Justin McCarthy (đồng sáng lập kiêm CTO)
- Từ cuối năm 2024, sau Claude 3.5 (bản sửa tháng 10), độ chính xác trong viết mã dài hạn được cải thiện, cho phép tích lũy độ đúng (compounding correctness) thay vì dồn lỗi lặp đi lặp lại
- Thông qua YOLO mode của Cursor, năng lực viết mã dài hạn của mô hình bộc lộ rõ ràng
- Với các mô hình trước đó, khi lặp lại việc áp dụng LLM vào tác vụ lập trình, đủ loại lỗi như hiểu sai, hallucination, lỗi cú pháp, vi phạm DRY theo phiên bản, không tương thích thư viện... tích tụ khiến ứng dụng bị “sụp đổ”
- Khi mô hình được cập nhật của Anthropic kết hợp với YOLO mode, khả năng đầu tiên của phát triển phi đối thoại hay phần mềm được nuôi lớn bắt đầu được xác nhận
Nguyên tắc cốt lõi: buông tay
- Ngay giờ đầu tiên của ngày đầu tiên, nhóm AI đã lập ra hiến chương, với nguyên tắc quan trọng nhất là: "Con người không được trực tiếp viết mã"
- Ban đầu chỉ là trực giác và thử nghiệm đơn giản: có thể đi xa đến đâu nếu hoàn toàn không viết dòng mã nào bằng tay?
- Lúc đầu nhanh chóng chạm trần, nhưng sau khi bổ sung test thì bắt đầu có tiến triển
- Agent bị ám ảnh bởi tác vụ tức thời và chọn lối tắt: test viết quá hẹp có thể bị vượt qua bằng return true, nhưng điều đó không khái quát thành phần mềm mà ta thực sự mong muốn
- Chỉ test đơn giản là không đủ, cần mở rộng sang test tích hợp, test hồi quy, test end-to-end và test hành vi
Chuyển từ test sang kịch bản và mức độ thỏa mãn
- Chủ đề lặp lại trong kỷ nguyên agent là: cần một ngôn ngữ mới, từ “test” là không đủ và mơ hồ
- Test được lưu trong codebase có thể bị viết lại một cách lười biếng cho khớp với mã, hoặc mã có thể bị viết lại để vượt qua test một cách tầm thường
- Định nghĩa lại thuật ngữ scenario: đó là câu chuyện người dùng end-to-end, được lưu bên ngoài codebase (tương tự tập “holdout” trong huấn luyện mô hình), để LLM có thể trực giác hiểu và xác minh linh hoạt
- Vì chính phần mềm đang được nuôi lớn cũng chứa các thành phần agent, việc đánh giá thành công được chuyển từ giá trị boolean đơn giản sang mức độ thỏa mãn mang tính xác suất và thực nghiệm (satisfaction)
- Satisfaction: định lượng tỷ lệ các quỹ đạo quan sát được đã vượt qua mọi kịch bản và có khả năng làm người dùng hài lòng
Xác minh kịch bản thông qua Digital Twin Universe
- Trong cơ chế trước đây, người ta dùng test tích hợp, test hồi quy và tự động hóa UI để xác định “có hoạt động hay không?”
- Nhóm phát hiện hai giới hạn của các kỹ thuật từng được xem là đáng tin cậy:
- Test quá cứng nhắc: vì viết mã bằng agent và xây dựng vòng lặp LLM/agent như primitive thiết kế, nên việc đánh giá thành công thường cần đến LLM-as-judge
- Test dễ bị reward hacking: cần một cách xác minh ít dễ bị mô hình gian lận hơn
- Digital Twin Universe (DTU) là câu trả lời: các bản sao hành vi của những dịch vụ bên thứ ba mà phần mềm phụ thuộc vào
- Xây twin cho Okta, Jira, Slack, Google Docs, Google Drive, Google Sheets, tái tạo API, edge case và hành vi có thể quan sát được
- Nhờ DTU, có thể kiểm chứng ở lưu lượng và tốc độ vượt xa giới hạn production
- Cũng có thể kiểm thử các chế độ lỗi vốn nguy hiểm hoặc bất khả thi trên dịch vụ thật
- Có thể chạy hàng nghìn kịch bản mỗi giờ mà không chạm giới hạn tốc độ, không kích hoạt phát hiện lạm dụng, không phát sinh dồn chi phí API
Kinh tế học phi truyền thống
- Thành công với DTU cho thấy khoảnh khắc agent (Agentic Moment) đang thay đổi tận gốc kinh tế học phần mềm theo nhiều cách
- Việc tạo ra các bản sao độ trung thực cao của những ứng dụng SaaS lớn vốn luôn khả thi, nhưng không khả thi về mặt kinh tế
- Nhiều thế hệ kỹ sư từng muốn có một bản sao CRM đầy đủ chạy in-memory để test, nhưng thậm chí không đề xuất với quản lý vì biết trước sẽ bị từ chối
- Người xây dựng software factory cần thực hành sự ngây thơ có chủ đích (deliberate naivete): tìm ra và loại bỏ các thói quen, quy ước, ràng buộc của Software 1.0
- Với DTU, những gì 6 tháng trước còn không thể tưởng tượng nay đã được biến thành công việc thường nhật có quy trình lặp lại
Đọc thêm tiếp theo
- Principles: những niềm tin của chúng tôi về phát triển phần mềm bằng agent
- Nuôi lớn phần mềm bằng cấu trúc seed → validation harness → feedback loop, trong đó token đóng vai trò nhiên liệu
- Mọi phần mềm đều cần seed ban đầu: trước đây là PRD hay tài liệu đặc tả, hiện nay chỉ vài câu, ảnh chụp màn hình hoặc codebase sẵn có cũng được
- Validation harness phải là end-to-end và càng gần môi trường thực (khách hàng, tích hợp, tính kinh tế) càng tốt
- Vòng lặp kín phản hồi feedback đầu ra trở lại làm đầu vào giúp hệ thống tự sửa và tích lũy độ đúng theo lãi kép
- Lý thuyết về xác minh và phản hồi thì dễ hiểu, nhưng triển khai thực tế đòi hỏi kỹ thuật sáng tạo và tiên phong: tìm cách biến mọi chướng ngại thành biểu đạt mà mô hình có thể hiểu
- Techniques: các mẫu lặp để áp dụng những nguyên tắc này
- Digital Twin Universe (DTU)
- Tái tạo hành vi quan sát được từ bên ngoài của các phụ thuộc bên thứ ba quan trọng
- Xác minh ở lưu lượng và tốc độ vượt xa giới hạn production
- Cung cấp điều kiện test mang tính quyết định và có thể tái hiện
- Gene Transfusion
- Chỉ định agent vào các ví dụ cụ thể để chuyển mẫu vận hành giữa các codebase
- Có thể tái tạo giải pháp đi kèm tham chiếu tốt trong bối cảnh mới
- Filesystem
- Mô hình nhanh chóng khám phá repository và tự điều chỉnh ngữ cảnh bằng cách đọc/ghi tệp
- Thư mục, chỉ mục và trạng thái on-disk hoạt động như nền tảng bộ nhớ thực dụng
- Shift Work
- Tách biệt tác vụ tương tác và tác vụ được đặc tả hoàn toàn
- Khi ý định đã hoàn chỉnh (đặc tả, test, ứng dụng hiện có), agent có thể thực thi end-to-end mà không cần qua lại nhiều vòng
- Semport
- Porting tự động có nhận thức ngữ nghĩa, thực hiện một lần hoặc liên tục
- Di chuyển mã giữa các ngôn ngữ hoặc framework trong khi vẫn giữ nguyên ý định
- Pyramid Summaries
- Tóm tắt có thể đảo ngược ở nhiều mức zoom
- Nén ngữ cảnh mà không đánh mất khả năng mở rộng trở lại toàn bộ chi tiết
- Products: những công cụ chúng tôi dùng hằng ngày và nghĩ rằng cũng sẽ hữu ích cho người khác
- CXDB là kho lưu trữ ngữ cảnh tự host cho AI agent, cung cấp Turn DAG, khử trùng lặp blob, kiểu động và debug trực quan
- StrongDM ID là hệ thống định danh cho con người, workload và AI agent, hỗ trợ xác thực liên kết và chia sẻ theo phạm vi đường dẫn
- Attractor là agent lập trình phi đối thoại được cấu trúc bằng phase graph, thực thi end-to-end khi công việc đã được đặc tả đầy đủ
3 bình luận
Tôi đã thử phát triển theo đặc tả, sử dụng nhiều tác nhân để phát triển. Đúng là nó giúp giảm rất nhiều việc, nhưng vì giới hạn hiệu năng của LLM nên không thể tạo ra sản phẩm khiến khách hàng hài lòng. Không thể thay thế 100%, và vẫn cần một mức độ công việc nhất định của con người.
Hơi giật gân quá, nhưng cũng phần nào có thể hiểu được.. Đây là một bài viết khiến người ta có cảm giác khá kỳ lạ.
Xem bài này rồi đọc bài dưới đây sẽ càng thấy đồng cảm hơn.
Tiếc thương tinh thần thủ công của chúng ta
Ý kiến trên Hacker News
Tôi đồng cảm với khái niệm Digital Twin Universe
Codebase của tôi cũng tích hợp rất nhiều dịch vụ bên ngoài, nên khi chặn các lời gọi ra ngoài lúc test thì gần như không thể xác minh được gì
Vì vậy tôi đã tạo các bản triển khai giả cho từng API như Okta, Jira, Slack, Google Docs để kiểm thử
Chỉ là tôi không sao chép cả UI, mà chỉ mô phỏng hành vi của API
Câu nói “nếu không tiêu $1.000 token mỗi ngày cho mỗi kỹ sư thì vẫn còn chỗ để cải thiện” nghe quá phi thực tế
Tôi nghi ngờ không biết đây có thật sự là một tuyên bố nghiêm túc hay không
Tính ra thì khoảng $250k mỗi năm
Nếu AI thực sự tạo ra mức năng suất tương ứng thì cũng có thể là hợp lý
Thực tế thì chắc chỉ cỡ hiệu suất của hai kỹ sư junior
Cuối cùng con người có lẽ sẽ chỉ giữ vai trò dẫn dắt, phụ trách lập kế hoạch và kiểm chứng
Dù là lạc quan quá mức, nhưng cũng không hẳn hoàn toàn điên rồ
Tôi chỉ dùng gói Claude và OpenAI giá $20/tháng
Hết token thì tôi đi dạo hoặc đọc sách
Tôi không phải kiểu accelerationist, nhưng vẫn làm việc đủ tốt
Tôi là một thành viên trong đội StrongDM
Việc tiêu $1.000 token mỗi ngày thì dễ, nhưng điểm mấu chốt là rất khó dùng chúng một cách hiệu quả
Cái này trông như một kiểu làm màu đơn thuần
Kiểu phát tín hiệu rằng “chúng tôi đi trước các bạn về AI”
Khi đọc bài này tôi thấy khá ngượng ngùng thay
Có cảm giác như họ đang gói ghém mocks hay kiểm thử mô phỏng vốn đã có từ trước thành một thứ “đột phá”
Dù vậy, tôi vẫn ghi nhận việc họ thẳng thắn công khai cấu trúc chi phí
Tôi đã tìm trên trang của họ xem có code hay sản phẩm thực tế nào không
Thứ duy nhất tôi tìm thấy là strongdm/attractor
“coding với bạn gái người Canada” giờ đã trở thành mô hình kinh doanh rồi
Ngoài ra tôi còn thấy strongdm/cxdb, nhưng lịch sử commit đã được dọn lại
Có code thật trong repo cxdb
Tôi không biết đây là điên rồ hay là một lát cắt của tương lai
Trên trang Products cũng có cả database và hệ thống ID
Nếu nhiều agent cùng cộng tác, thì ngữ cảnh dùng chung và hệ thống phân quyền là bắt buộc
Tôi đã nghe webinar về BAML của BoundaryML
Spec-driven development là cách tiếp cận xây dựng workflow có cấu trúc với con người ở trong vòng lặp
Nó định nghĩa rõ vòng lặp
/research → /plan → /implement, và ở mỗi bước đều có xác minh của con ngườiĐây là triết lý hoàn toàn đối lập với tuyên bố của StrongDM rằng “con người không viết hay đọc code”
Cảm giác như lại là một bài blog rỗng tuếch nữa
Không có kết quả thực chất nào, và chuyện $1.000/ngày tiền token có vẻ chỉ để gây ấn tượng với nhà đầu tư
Nếu không giải quyết được bài toán xác minh, thì tất cả chuyện này chỉ là làm màu
Dù có dựng review tự động hay guardrail đi nữa, cuối cùng người phải xác nhận đặc tả có khớp với kết quả hay không vẫn là con người
Ở Speedscale, chúng tôi đang tự động hóa việc xác minh bằng capture và replay traffic
Thực ra lập trình viên con người cũng không hoàn hảo
Code review, test, QA và nhiều quy trình xác minh có hệ thống khác đã tồn tại từ lâu
Điều quan trọng không phải là AI có hoàn hảo hay không, mà là chất lượng của toàn bộ hệ thống có hội tụ hay không
Theo trải nghiệm của tôi, với Opus 4.5 thì có một chút lợi ích ròng
Tôi cũng gần như đồng ý
Cốt lõi là xác minh chứ không phải sinh ra
Tôi đang xây dựng một cấu trúc nơi nhiều agent độc lập bộc lộ bất đồng và đi đến đồng thuận với nhau
Nói ngắn gọn thì đây là đẩy việc xác minh và kiểm thử bảo mật sang cho người dùng cuối
Cần dùng ngôn ngữ dựa trên đặc tả và formal verification tích cực hơn
Cuối cùng, lập trình sẽ được định nghĩa lại thành “hành vi cụ thể hóa đặc tả”
Nếu là $1.000 token mỗi ngày thì tức là đang chi cho AI nhiều hơn cho con người
Điều này trông giống như điểm sụp đổ của tầm nhìn AI
Nghe nói Simon Willison đã cập nhật bài viết
$240k mỗi năm thì ngang một kỹ sư FANG mới vào nghề
Thành thật mà nói, cũng có nhiều junior còn kém hơn Claude
Cuối cùng có lẽ sẽ tái cấu trúc thành một mô hình kim tự tháp, với số ít con người ở trên đỉnh
Nếu có thể hoàn thành cùng một việc chỉ trong 5 ngày, thì chi phí so với tốc độ có thể vẫn hợp lý
Nếu đầu ra tăng tương ứng thì hiệu suất theo chi phí cũng có thể chấp nhận được
Hơn nữa, đơn giá token cũng có thể sẽ giảm
Ngành pháp lý và bảo hiểm sẽ chật vật nhất với thay đổi này
Sai sót của con người thì còn mô hình hóa được, nhưng lỗi dây chuyền trong vòng lặp tự trị lại là một vấn đề hoàn toàn khác
Các quyết định của AI rốt cuộc vẫn sẽ quy về trách nhiệm của con người
Đây có vẻ sẽ là phanh hãm của toàn bộ sự dịch chuyển sang agentic
$1.000 token mỗi ngày là một chỉ số hoàn toàn vô lý
Nếu chất lượng code kém thì mức tiêu token sẽ tăng vọt
Cuối cùng chính codebase bừa bộn mới làm chi phí phình ra
Nếu một team đốt nghìn đô mỗi ngày thì gần như chẳng có hiệu quả gì
(tham khảo: ảnh này)
Đây là vấn đề tối ưu ngắn hạn vs dài hạn
Chọn giữa nâng hiệu suất ngay bây giờ hay cải thiện toàn bộ hệ thống
Biết đâu giờ đây ban lãnh đạo mới nhận ra tầm quan trọng của việc refactor
Đội ngũ theo mẫu Dark Factory mà tôi từng nhắc đến trước đây chính là họ
Tôi đã viết bài này, và đây là những người thử nghiệm tham vọng nhất
Nhưng trên thực tế thì gần như không có kết quả đầu ra
Đưa $10k cho vài sinh viên đại học có khi còn làm ra thứ tốt hơn
$1.000 token mỗi ngày thì với ngân sách của team tôi là chuyện không tưởng
Với cá nhân tôi cũng không thể vì còn chi phí sinh hoạt
Cuối cùng có cảm giác như “làm cũng chết mà không làm cũng chết”
Nếu không có kết quả có thể kiểm chứng thì chỉ là lời nói suông
Mà giờ thì ngay cả lời nói cũng đã rẻ hơn nhiều nhờ LLM
Cần có sự công khai minh bạch về mặt đạo đức
Thuật ngữ trên site chỉ là cách đóng gói lại các khái niệm cũ
“Digital Twin Universe” là mocks, “Gene Transfusion” là đọc code tham chiếu, “Semport” là transpiling
Hoàn toàn không có dữ liệu hay benchmark thực tế nào
Đây là một ví dụ AI marketing được gói thành insight kỹ thuật
Thực ra phần lớn code cốt lõi đã có trên GitHub
Điểm khác biệt thật sự nằm ở thiết kế cơ chế và hệ giá trị
Tương lai sẽ đi theo hướng kết hợp formal methods với AI
Cách “giữ một số kịch bản làm holdout set để test” khá thú vị
Đây là khái niệm mô phỏng kiểm thử tấn công của đội QA
Việc tách đội build và đội tìm bug thành một cấu trúc cạnh tranh lẫn nhau khá ấn tượng
Tuy vậy, $1.000 token mỗi ngày vẫn là điều đầy tuyệt vọng với các nhà phát triển mã nguồn mở
Dùng model cục bộ có thể giảm chi phí
Như thread này, tự động hóa agent cục bộ cũng hoàn toàn khả thi
Biết đâu một ngày nào đó các agent sẽ hối lộ lẫn nhau
Tôi vẫn thích kiểu con người ở trong vòng lặp hơn
Cứ đốt token vô tội vạ là lãng phí
Trong bài “LLMs aren’t tools”, tôi đã đào sâu khung tư duy để tận dụng LLM
“Nhà máy phần mềm” là điểm kết hiện tại, nhưng bước tiếp theo là xem LLM như một ứng dụng
Tức là không chỉ tự động hóa workflow đơn thuần, mà là xây dựng một harness tùy chỉnh