Vì sao nhà máy phần mềm thất bại: Chỉ kỹ thuật harness là chưa đủ

 (github.com/humanlayer)
1 điểm bởi GN⁺ 2 giờ trước | 1 bình luận | Chia sẻ qua WhatsApp
  • Nhà máy phần mềm không người vận hành (lights-off), nơi con người không đọc hay viết code, có thể tăng tốc độ sinh code, nhưng cũng loại bỏ cả con người — những người đánh giá khả năng bảo trì dài hạn — nên khó hoạt động trong các codebase production phức tạp
  • Reinforcement learning của các mô hình lập trình tối ưu các phần thưởng nhanh và rõ ràng như vượt qua test, nhưng không thể phạt chi phí thiết kế kém chỉ lộ ra sau nhiều tháng
  • Các họ benchmark như SWE-bench đánh giá việc sửa lỗi và giữ nguyên test hiện có, nhưng không lọc được những thay đổi làm chất lượng code xấu đi từ từ như try/catch bừa bãi, ép kiểu tùy tiện, hay shotgun surgery
  • Hiện tại, con người cần đảm nhiệm code review và phải xem xét yêu cầu sản phẩm, kiến trúc hệ thống, thiết kế chương trình, vertical slice trước khi triển khai để giảm làm lại và giảm khối lượng review code do AI sinh ra
  • Nếu thừa nhận các giới hạn của mô hình, thay vì tự động hóa quá mức 10–100 lần, ta có thể phát triển nhanh hơn 2–3 lần trong khi vẫn giữ chất lượng gần mức con người; các phán đoán cốt lõi và việc đọc code hiện vẫn chưa thể thuê ngoài

Lời hứa và thực tế của nhà máy phần mềm xoay quanh vòng lặp

  • Trong cuộc đua đưa AI coding vào production, quan điểm rằng chỉ cần tăng thêm harness và vòng lặp agent đang lan rộng
  • Cách tiếp cận này dựa trên giả định rằng con người là nút thắt cổ chai, mô hình đã đủ tốt, và chi phí sinh code thực tế thấp nên cứ phát hành nhiều hơn là được
  • Mục tiêu là đồng thời đạt tốc độ 10–100 lần, chất lượng cao, và loại bỏ code review bởi con người
    • Họ cho rằng nếu cấu hình thêm linter và yêu cầu bot review PR kiểm tra theo hướng đối kháng, phần mềm có thể tự khiến mình an toàn
  • Trong thực tế, đã xuất hiện các trường hợp agent lập trình gây sự cố và codebase nhanh chóng sụp đổ
  • Báo cáo của Faros AI quan sát thấy các thay đổi sau khi áp dụng công cụ AI coding
    • Số lượng và độ dài bình luận review tăng, nhưng số PR được merge mà không review cũng nhiều hơn
    • Incident và số bug trên mỗi developer tăng
    • Tuy nhiên đây gần với tín hiệu tương quan hơn là quan hệ nhân quả đã được kiểm chứng
  • Khó tìm thấy dữ liệu kết luận cho thấy kết quả của StrongDM, và các cập nhật công khai từ tháng 2 đến tháng 6 cũng khá hiếm

Codebase phức tạp là một vấn đề khác với vibe coding

  • Một side project chỉ có vài người dùng và một hệ thống enterprise 10 năm tuổi gần như không có chung nhiều ràng buộc
  • Chủ đề thảo luận không phải bản thân vibe coding, mà là những vấn đề khó của codebase phức tạp và bảo trì production
  • Trước đây brownfield thường chỉ các hệ thống Java cũ, nhưng codebase do agent tạo ra cũng có thể trở nên khó thay đổi sau khoảng 3–6 tháng vì tốc độ phát triển nhanh
  • Khi kết quả tệ, có nhiều lời khuyên đổ lỗi cho thiếu token hoặc thiếu công nghệ, nhưng vấn đề cốt lõi nằm ở cách huấn luyện mô hình hơn là harness

Sự tiến hóa của nhà máy phần mềm

  • Từ năm 1968 đến trước khi AI được áp dụng

    • Thuật ngữ “nhà máy phần mềm” có thể truy ngược đến hội nghị NATO năm 1968, nơi cụm từ “software engineering” xuất hiện
    • Một nhà máy điển hình khoảng năm 2022 có vòng lặp như sau
      • Con người quyết định sẽ xây gì và đưa vào tracker như Linear hoặc Jira
      • Người phụ trách triển khai và kiểm thử
      • Qua kiểm tra tự động và code review bởi con người; nếu có vấn đề thì quay lại bước triển khai
      • Sau khi deploy lên production, hệ thống được monitor và incident cùng feedback người dùng được đưa ngược về tracker
    • Vì triển khai và review mỗi bước có thể mất vài giờ hoặc vài ngày, các team đặt planning, đề xuất kiến trúc và sprint planning lên trước để tạo đồng thuận trước
    • Đồng thuận trước khi triển khai giảm việc làm lại, và một PR hoàn thiện, gần với hướng đã quyết định, có thể được review nhanh ngay cả khi phải đọc mọi dòng

  • Nhà máy dạng agent

    • Ramp, Stripe, WorkOS, Brex, v.v. giới thiệu rằng nhà máy agent xuất xưởng khoảng 75% code
    • Trong nhà máy hiện có, bước do con người triển khai được thay bằng agent, kết hợp orchestration, harness, sandbox, model và computer use
    • Thời gian triển khai giảm từ vài giờ/vài ngày xuống vài phút/vài giờ, nhưng việc con người đọc code và kiểm thử vẫn còn nguyên nên review trở thành nút thắt
    • Để giảm nút thắt này, nhiều vòng lặp được thêm vào
      • Agent code review kiểm tra style, bug và bảo mật
      • Regression test dùng trình duyệt và computer use để xác nhận hành vi bên ngoài
      • Luồng tự động liên kết incident với PR để người phụ trách nhận ứng viên sửa lỗi
      • Luồng nối trực tiếp feedback người dùng vào hàng đợi công việc
    • Cuối cùng, vấn đề vận hành thu hẹp lại thành có thể đưa bao nhiêu việc vào hàng đợi, và có thể review, kiểm thử kết quả nhanh đến đâu

  • Nhà máy không người vận hành

    • Nhà máy không người vận hành, do Dan Shapiro đặt tên, loại bỏ bước con người đọc mọi thay đổi
    • Thay vì code review, nó đầu tư vào các lĩnh vực sau
      • Agent tự kiểm thử
      • Sandbox và orchestration
      • Review và monitoring tự động
      • Phát hành từng bước và thu thập tín hiệu feedback người dùng
    • Khi loại bỏ phán đoán của con người, điều còn lại chỉ là có thể giao bao nhiêu việc cho agent, nhưng cách này không hoạt động với codebase production phức tạp

Thất bại khi trực tiếp áp dụng mô hình không người vận hành

  • Từ tháng 7/2025, tác giả áp dụng mô hình hoàn toàn không người vận hành, chỉ đọc specification và ticket rồi giao các tác vụ nhỏ và vừa cho background agent
  • Sau vài tháng, các vấn đề phức tạp xuất hiện mà prompt và workflow nâng cao cũng không giải được
    • Thu thập context cần thiết và cung cấp cho mô hình
    • Agent thử tái hiện vấn đề theo khoảng 10 cách
    • Cuối cùng con người phải trực tiếp vào codebase đã không đọc trong 3 tháng để tìm nguyên nhân
  • Trong thời gian đó, site bị gián đoạn, người dùng gặp bất tiện, và con người phải đọc lượng code chất lượng thấp tích tụ
  • Ở lần thất bại đầu, tác giả cho rằng có thể chấp nhận rủi ro để đổi lấy tốc độ, nhưng đến tháng 11, khi khoảng vấn đề thứ ba xảy ra, viết lại từ đầu đã dễ hơn
    • Đồng sáng lập tự triển khai lại các pattern trong VS Code trong 2 tuần

Vì sao mô hình làm giảm chất lượng codebase

  • Các mô hình hiện nay không thể duy trì và cải thiện chất lượng codebase lâu dài nếu thiếu sự định hướng đáng kể từ con người
  • Ở đây, khả năng bảo trì là năng lực tránh trạng thái shotgun surgery, nơi thay đổi một phần làm hỏng phần khác và cùng một thay đổi phải được áp dụng ở nhiều vị trí
  • Mô hình đã tiến bộ mạnh trong giải quyết vấn đề một lần hoặc tạo site marketing mới, nhưng năng lực cải thiện chất lượng code theo thời gian khó có thể nói là đã cải thiện rõ rệt
  • Vì không có benchmark tốt để đo năng lực bảo trì, cũng khó chứng minh hoặc bác bỏ khác biệt này
  • Ngay cả khi một mô hình như GPT-5.5 xhigh thực hiện refactor xuất sắc, nếu con người vẫn phải hiểu codebase và chỉ định cụ thể việc cần làm, vấn đề của nhà máy không người vận hành vẫn chưa được giải quyết

Claude Code và reinforcement learning bên trong harness

  • Trước Claude Code, các CLI agent như aider, cline, codebuff đã cung cấp công cụ đọc, viết, chỉnh sửa, tìm kiếm, shell và context engineering
  • Các agent trước đây đôi khi thiếu độ ổn định khi dùng công cụ, chẳng hạn lặp lại cùng một chỉnh sửa rồi tiếp tục thất bại
  • Bài báo SWE-Agent phân tích rằng những khác biệt nhỏ trong thiết kế công cụ, như thêm số dòng vào kết quả ReadFile hoặc đổi Edit từ tìm/thay thế sang chỉnh sửa theo khoảng dòng, cũng ảnh hưởng đến hiệu năng
  • Một lý do cốt lõi khiến Claude Code tăng trưởng nhanh là Anthropic đã reinforcement learning mô hình ngay trong harness sẽ được phát hành thực tế
    • Trọng số được điều chỉnh để mô hình gọi đúng tập công cụ trong vòng lặp agent
    • Khác với developer bên ngoài phải điều chỉnh định nghĩa công cụ và đánh giá theo sở thích của mô hình, chủ sở hữu mô hình có thể thay đổi chính mô hình để phù hợp với công cụ
  • Team sở hữu cả harness lẫn trọng số mô hình có lợi thế hơn team chỉ tạo harness mà không thể điều chỉnh trọng số

Giới hạn phần thưởng của reinforcement learning cho coding agent

  • Reinforcement learning cho mô hình lập trình thường lặp lại quy trình sau hàng triệu lần
    1. Tạo execution trace của agent để giải một vấn đề như sửa test
    2. Đánh giá execution trace bằng verifier
    3. Cập nhật trọng số mô hình để tăng xác suất của execution trace tốt và giảm xác suất của execution trace xấu
  • Vấn đề là điểm đánh giá có thể quá một chiều

  • Trường hợp SWE-bench Multilingual

    • SWE-bench Multilingual dùng các tác vụ khoảng 15 phút lấy từ repository open source như Redis, jq, Django
    • Phần thưởng là 0 hoặc 1 và kiểm tra hai điều kiện
      • FAIL_TO_PASS: vấn đề được yêu cầu đã được sửa hay chưa
      • PASS_TO_PASS: hành vi hiện có có bị phá vỡ hay không
    • Tác vụ fastlane__fastlane-19304 là bug gọi .empty? trên nil khi không có tham số tùy chọn include, exclude
    • Bản sửa thật của con người là thay đổi hai dòng, đặt giá trị mặc định của nil thành mảng rỗng
    • Mô hình chỉ nhận commit cơ sở ngay trước khi sửa và bug report, không thấy patch đáp án hay patch test dùng để chấm
    • Việc đánh giá diễn ra theo thứ tự sau
      1. Giữ lại patch do mô hình tạo
      2. Loại bỏ các thay đổi mà mô hình áp dụng lên file test
      3. Áp dụng patch test riêng tư của benchmark
      4. Chạy cả test hiện có và test mới
    • Lý do loại bỏ thay đổi test là vì mô hình có thể comment test đang fail hoặc thêm mock vô nghĩa để làm test pass
    • Benchmark và verifier của reinforcement learning không giống nhau và nên tách biệt, nhưng cả hai đều cho thấy giới hạn cấu trúc trong cách đánh giá chất lượng execution trace lập trình

  • Thiết kế xuống cấp không bị phạt

    • Nếu test pass, quá trình đi đến lời giải và chất lượng cấu trúc không được phản ánh vào điểm
    • Bọc mọi nơi bằng try/catch hoặc ép kiểu lỏng lẻo làm sụp đổ lợi ích của type system cũng có thể trở thành đáp án đúng
    • Làm tổn hại khả năng bảo trì không bị phạt miễn là test hiện có và test mới đều pass

Kiểm chứng chất lượng khó hơn vượt qua test

  • Test cung cấp thành công/thất bại rõ ràng trong vài giây, nên reinforcement learning có thể lặp lại hàng triệu lần
  • Chi phí của kiến trúc tệ chỉ lộ ra sau vài tuần, vài tháng hoặc vài năm, khi một thay đổi nhỏ phải được áp dụng ở nhiều vị trí
  • Các benchmark hiện tại không đánh giá được chi phí thiết kế dài hạn như vậy
  • Reinforcement learning và benchmark không phải là một, nhưng nếu khả năng bảo trì đã được giải quyết trong reinforcement learning, năng lực đó có khả năng cũng sẽ xuất hiện trong thiết kế benchmark
  • Vì vậy, không thể xem điểm benchmark hiện có tăng lên là bằng chứng rằng mô hình đã không còn làm bẩn codebase

Những nỗ lực mới nhằm đánh giá khả năng bảo trì

  • Tuyến đầu của chất lượng mô hình đang cải thiện, nhưng kỳ vọng và quảng bá đang đi trước kỷ luật kỹ thuật
  • Các ví dụ cố gắng đánh giá gần hơn với khả năng bảo trì gồm
    • SWE-Marathon: sử dụng tác vụ quy mô khoảng 400 giờ, như sao chép toàn bộ chức năng của Excel, và các kênh phần thưởng phức hợp thay vì một thành công/thất bại đơn lẻ
    • DeepSWE: dùng các tác vụ open source quy mô lớn chưa được triển khai ngoài đời để giảm nhiễm dữ liệu huấn luyện, nhưng không tự giải quyết vấn đề chất lượng
    • Frontier Code: đánh giá công việc trải dài trên nhiều PR và phạt nếu viết test không fail trên code trước patch
      • Kiểm tra tính hữu hiệu của test một cách quyết định luận, tương tự mutation testing
      • Cũng chạy mô hình phán định để kiểm tra diff theo quy tắc chất lượng code
  • Có một giới hạn: nếu mô hình phán định có thể phân biệt chất lượng ổn định, lẽ ra ngay từ đầu nó cũng có thể tạo code tốt
  • Reinforcement learning cần oracle nhanh và đáng tin cậy, nhưng khả năng bảo trì không có oracle như vậy
  • Review agent và token bổ sung có thể bắt lỗi rõ ràng, nâng mức chất lượng tối thiểu, nhưng không nâng chất lượng tối đa vượt quá mức đã dạy cho mô hình bằng reinforcement learning
  • SWE-Marathon, DeepSWE, Frontier Code là các nỗ lực ban đầu nhằm đánh giá khả năng bảo trì vượt ra ngoài phán định thành công/thất bại, nhưng vẫn chưa đủ để giao cả codebase cho chúng

4 bước đưa con người trở lại vòng lặp

  • Vì hiện tại người đánh giá chất lượng đáng tin cậy là con người, cần khôi phục code review
  • Áp dụng kế hoạch tiền kỳ vốn đã dùng từ trước AI để giảm review dài và khả năng làm lại
  • Đòn bẩy của AI được dùng ở bốn giai đoạn: yêu cầu sản phẩm, kiến trúc hệ thống, thiết kế chương trình, vertical slice

  • 1. Review sản phẩm

    • Biến câu ngắn hoặc voice memo dài thành tài liệu bán cấu trúc để cố định việc sẽ xây gì và vì sao
    • Trước hết, định nghĩa vấn đề cần giải quyết bằng ngôn ngữ của người dùng và đặt tiêu chí đánh giá thành công sau khi phát hành
      • Giảm thời gian thực hiện workflow
      • Đạt mốc onboarding sớm hơn
      • Cải thiện tỷ lệ lỗi hoặc độ trễ
      • Giảm một loại support ticket cụ thể
    • Tập trung vào trải nghiệm người dùng hơn là chi tiết kỹ thuật; nếu quyết định kỹ thuật chặn quyết định sản phẩm, hãy lưu tài liệu hiện tại rồi chuyển sang review kiến trúc hoặc feasibility prototype
    • Với hành vi trên màn hình, một mockup HTML thô thường hiệu quả hơn mô tả dài để đạt đồng thuận
    • Không áp dụng quy trình này cho sửa câu chữ, script dùng một lần, hay bug có cách tái hiện rõ ràng; giao thẳng cho agent
    • Chỉ đưa vào review sản phẩm những thay đổi mà chi phí sẽ lớn nếu agent hiểu sai ý định
    • Người review PR cũng được yêu cầu review trước specification sản phẩm/kỹ thuật; có thể dùng bình luận tài liệu bất đồng bộ hoặc GitHub, Notion, v.v.

  • 2. Kiến trúc hệ thống

    • Thống nhất cách service, endpoint, schema, queue, storage giao tiếp, nhưng không đi sâu đến triển khai bên trong chương trình
    • Để tăng băng thông giao tiếp giữa con người và agent, dùng các biểu diễn sau
      • Sequence diagram giữa UI, API, service và storage
      • API contract thể hiện request/response
      • Data model cho bảng mới và dạng query
    • Mermaid hữu ích, nhưng nếu dùng quá mức có thể tạo niềm tin sai rằng đồng thuận thực sự đã đạt được
    • Review kiến trúc hiệu quả trong việc chặn sớm thói quen xấu của mô hình, nhưng chưa đủ để đảm bảo code chất lượng cao

  • 3. Thiết kế chương trình

    • Trước khi triển khai, quyết định hình dạng của code ở mức thấp hơn kiến trúc một bậc
      • Type
      • Method signature
      • Bố trí chương trình
      • Call stack
    • Hình dung bằng pseudocode nhẹ dễ đọc hơn Mermaid phức tạp
    • Với thay đổi về orchestration hoặc control flow, dùng cây call stack; nếu phần thay đổi là quan trọng, áp dụng cú pháp diff
    • Dùng file tree diff để xác nhận vị trí và vai trò của file mới và file sửa đổi
    • Định trước type và method signature của các hàm cốt lõi để giảm khả năng agent chọn sai thiết kế bên trong
    • Mô hình có thể tạo bản nháp và con người điều chỉnh; đây là việc kéo những quyết định vốn sẽ đưa ra ngầm trong code review về thời điểm rẻ hơn

  • 4. Vertical slice

    • Mô hình ưa kế hoạch ngang, xây lần lượt database migration → service layer → API → frontend
    • Kế hoạch ngang khiến khó chạm và kiểm chứng giải pháp thực tế bằng trình duyệt hoặc curl trong lúc làm
    • Trước thời AI, developer thường không viết 500 hoặc 2.000 dòng cùng lúc, mà mở rộng từ giữa ra ngoài và liên tục kiểm tra
      1. Tạo API contract và mock data rồi kiểm tra bằng curl
      2. Cho frontend tiêu thụ mock data và tinh chỉnh trong trình duyệt
      3. Kết nối API với service layer
      4. Thêm database migration và kết nối storage
      5. Thêm business logic
      6. Thêm xử lý lỗi
    • Vertical slice hoặc tracer bullets cho phép kiểm thử và cải thiện hành vi thực tế ở mỗi bước
    • Ở những khu vực đặc biệt quan trọng về chất lượng, review 100–200 dòng ở mỗi bước và chỉnh hướng sẽ rẻ hơn sửa muộn hơn 2.000 dòng
    • Ngay cả mô hình mới nhất cũng khó tự lập kế hoạch như vậy nếu không có định hướng của con người, và cũng khó khái quát theo từng codebase và tác vụ, nên con người phải ở lại trong vòng lặp

Cách áp dụng theo kích thước công việc

  • 30 phút lập kế hoạch trước có thể giảm nhiều giờ review sau triển khai
  • Để duy trì chất lượng gần mức con người, con người phải tham gia vào thiết kế sản phẩm, kiến trúc hệ thống, thiết kế chương trình và vertical slice
  • Không áp dụng toàn bộ quy trình cho mọi tác vụ
    • Khoảng 40% được sinh một lần hoặc hoàn tất với 1–2 lượt feedback nhẹ
    • Tác vụ cỡ vừa gộp thiết kế sản phẩm và hệ thống vào một tài liệu kế hoạch, không chia nhỏ giai đoạn triển khai
    • Tác vụ lớn đi qua cả bốn bước, nhưng nếu review sản phẩm không phù hợp, như refactor quy mô lớn, thì bỏ qua bước đó
  • Thường giao cho mô hình 1–3 slice mỗi lần và review code đang diễn ra
  • Chỉnh cấu trúc bên trong hoặc chức năng từ sớm dễ hơn tìm xem điều gì sai sau khi đã sinh lượng lớn code

Nút thắt không phải số lượng PR mà là chất lượng PR

  • Nút thắt không phải là có quá nhiều PR, mà là có quá nhiều PR tệ
  • Một PR sạch, theo đúng thiết kế đã quyết định và quy ước của team, có thể được review nhanh ngay cả khi đọc mọi file
  • Chỉ cần 20% PR phải làm lại cũng tạo gánh nặng nhận thức và cảm xúc cho cả người gửi lẫn người review
  • PR do AI sinh một lần thường có tỷ lệ làm lại gần 50%
  • Dù người gửi là AI, vẫn phải có ai đó khởi động công việc, tinh chỉnh kết quả hoặc chịu trách nhiệm, nên chi phí làm lại không biến mất

Tốc độ phát triển khi chấp nhận giới hạn

  • Giới hạn cốt lõi hiện tại là mô hình có những việc làm tốt và những việc làm kém rất rõ, và trong tương lai gần con người vẫn phải đọc code
  • Thay vì giả định chất lượng code không quan trọng và đuổi theo tốc độ 10–100 lần, nếu tối ưu hệ thống trong các giới hạn này, ta có thể đạt tốc độ 2–3 lần một cách an toàn
  • Có bốn nguyên tắc thực hành
    1. Làm việc đủ nhiều với mô hình để xây trực giác về giới hạn của nó
    2. Tối ưu hệ thống phát triển trong các giới hạn đó
    3. Tìm các điểm có đòn bẩy cao
    4. Đọc code thật
  • Harness và vòng lặp là công cụ giảm lỗi rõ ràng, nhưng không thể thay thế phán đoán về khả năng bảo trì và tư duy thiết kế

Bài viết liên quan

1 bình luận

 
GN⁺ 2 giờ trước
Ý kiến trên Hacker News

  • Điều này được gọi là bài toán ý định-triển khai-chất lượng
    Các nhà máy phần mềm có thể hiện thực mọi thứ từ app, tính năng, sửa lỗi, thay đổi thiết kế đến refactor chỉ từ một yêu cầu một dòng, nhưng việc chúng có thể tái hiện chính xác ý định của con người và hướng phát triển của sản phẩm nằm phía sau yêu cầu đó hay không lại là một chuyện khác
    Cách triển khai bùng nổ theo tổ hợp, và cách làm ‘đúng’ sao cho nhất quán với hệ thống, có thể mở rộng, dễ hiểu và hỗ trợ an toàn cho hàng triệu người dùng là điều mang tính chủ quan tùy theo con người và bài toán. Có thể nâng một phần chất lượng bằng test và bằng chứng công việc, nhưng không có vòng phản hồi nào để kiểm chứng và hiệu chỉnh chất lượng mang tính chủ quan này

    • Dù khách hàng nói rằng họ “muốn X”, họ có thể thật ra muốn X, cũng có thể không cần X, hoặc có thể muốn Y nhưng chỉ là không diễn đạt được. Những khách hàng khác có thể không muốn X, hoặc cũng có thể chỉ quấy nhiễu nhà phát triển mà không vì lý do gì rõ ràng
    • Nhà máy phần mềm rất phù hợp với phần mềm cá nhân/sở thích có rất ít người dùng và doanh thu, nơi bug có thể được sửa chỉ bằng một prompt Claude, hoặc với startup trước khi đạt product-market fit
      Cũng có thể duy trì trạng thái không nhìn code chút nào mà chỉ dùng mức độ thành công của yêu cầu làm phản hồi, nhưng với các loại phần mềm khác thì bài toán ý định và chất lượng chủ quan vẫn chưa được giải quyết
    • Ngay giả định rằng chỉ có một cách duy nhất để chuyển yêu cầu thành triển khai đã không đúng sự thật

  • Bài viết có nhiều điểm hay, nhưng khó có thể khái quát thí nghiệm vận hành không người vào tháng 7/2025 thành giới hạn của các agent hiện tại
    Độ hữu dụng của model đã nhảy vọt đâu đó vào mùa thu 2025 hoặc mùa xuân 2026, và từ sau đó tôi cũng đã có thể giao cả một tính năng hoàn chỉnh cho agent. Bài viết có nhắc đến sự cải thiện của model nhưng thực tế gần như phớt lờ nó, điều này không khớp với cảm nhận của tôi

    • Cả bài viết lẫn website sản phẩm dường như đều đang dừng lại ở năm 2025. Đặc biệt, bài “ngữ cảnh dài không phải là câu trả lời” có vẻ như đã ngoại suy nguyên trạng hiệu năng trong quá khứ sang các model mới nhất
      Các model sau Opus 4.6 ổn định đến mức khó cảm nhận thấy suy giảm trí tuệ ngay cả ở 700.000~900.000 token; hiệu quả chi phí thì rất thấp, nhưng chúng hoạt động được
    • Tuần trước tôi nghe podcast có Dex Horthy tham gia, và công ty của anh ấy là Humanlayer vẫn đang liên tục đẩy giới hạn của agent và tích cực sử dụng chúng
      Họ hiểu rất rõ năng lực của model hiện tại, nên nếu họ đánh giá rằng nhà máy phần mềm không người hiện đã khả thi, hẳn họ sẽ thử lại
    • Opus 4.5 rõ ràng là một bước nhảy lớn. Đánh giá của người chưa thử các model sau đó thì kém giá trị hơn, nhưng ngay cả khi model chưa hoàn hảo thì chúng vẫn cực kỳ hữu ích
    • Nếu vậy, sẽ rõ ràng hơn nếu viết rằng “chúng tôi đã triển khai toàn diện vào năm 2025 và đến 2026 vẫn không có gì cải thiện về bản chất”
      Tôi cho rằng ngay cả các frontier model mới nhất cũng vẫn không xử lý tốt hơn việc lệch ngữ cảnh hay shotgun surgery. Nếu muốn phản bác thì không nên chỉ phớt lờ mà cần đưa ra bằng chứng cụ thể và trải nghiệm sử dụng khác biệt
    • Có thể gây tranh cãi, nhưng trong kỹ thuật phức tạp tôi cảm thấy Opus 4.1 thông minh hơn 4.5
      4.5 nhanh hơn và có lợi thế trong việc nhanh chóng thu hút người dùng mới nhờ xử lý tốt các prompt đơn giản và đọc được ý định ngầm

  • Tôi đã xây dựng và vận hành nhà máy phần mềm của mình trong 8 tháng, và dù vẫn chưa có thu thập công việc tự động hay gửi PR, sau khi xác định yêu cầu thì phần lớn quy trình tự đi đến cả bước triển khai. Sau khi đánh giá hệ thống, tôi đã ngừng review code trong 4 tháng qua
    Thay vì prompt một dòng, tôi dùng quy trình phỏng vấn để giải quyết trước các câu hỏi chưa có đáp án và điểm mơ hồ; các hàng rào an toàn gồm review kế hoạch, đảm bảo chất lượng dựa trên trình duyệt, review đối kháng, unit test, linter, type checker, hook sau commit và theo dõi formal methods
    Khi lỗi lặp lại xuất hiện, tôi có thể nhận ra khu vực đã trở nên bừa bộn ngay cả khi không nhìn code. Khi yêu cầu tăng lên và các biến trạng thái chồng chéo, tôi refactor chúng thành một sum type duy nhất; nếu phức tạp, tôi tạo model hình thức và trace bằng Quint rồi chạy chúng bằng unit test
    Codebase gồm frontend và backend đã hơn 1 năm tuổi. Agent có xu hướng sao chép nguyên xi các pattern hiện có, nên nguyên tắc rõ ràng là rất quan trọng; khi chia ranh giới hệ thống mới, model cỡ Sonnet thường phán đoán sai còn Opus thì tốt hơn

    • Dù chưa phải nhà máy hoàn chỉnh, tôi cũng cảm nhận tương tự ở vài dự án vibe coding đã trưởng thành
      Tôi hầu như luôn nhận ra được sự suy giảm chất lượng, và đến giờ vẫn chưa có lần nào tôi mở code ra, tìm được vấn đề rồi lại không thể dùng agent để dọn dẹp nó. Tôi cũng chưa thấy tình huống nào mà một kỹ sư trung bình không thể đảo ngược sự ô nhiễm của codebase
    • Điều tôi tò mò không phải là bản thân nhà máy code, mà là anh đã làm ra cái gì. Cần có một sản phẩm chứng minh rằng cũng có thể làm ra thứ gì đó ngoài công cụ coding AI
    • Nếu công bố cấu hình và quy trình làm việc cụ thể dưới dạng bài viết dài hoặc repository thì tôi rất muốn xem

  • Hoặc là bạn cần hiểu cách codebase vận hành, hoặc là bạn không cần
    Claude có thể viết code thay bạn, nhưng không thể hiểu thay bạn, và quá trình đó vẫn diễn ra với tốc độ của con người. Có những trường hợp không cần hiểu mọi thứ, nhưng cần phân biệt tinh tế hơn; ngay cả khi Claude viết code hoàn hảo thì thực tế này cũng không thay đổi

    • Claude có thể khám phá một codebase spaghetti nhanh hơn con người rất nhiều. Vấn đề thậm chí là nếu thuê ngoài việc hiểu dự án cho Claude, bạn có thể tiếp tục làm việc ngay cả sau khi nó đã trở nên không thể dùng được đối với con người từ lâu
    • Thay vì nhìn việc có hiểu hay không như một nhị phân, cũng có thể xem là trong một codebase cụ thể thì cần bao nhiêu mức độ hiểu biết để làm việc hiệu quả
      Ngay cả trước thời LLM cũng không ai biết toàn bộ một codebase lớn, nhưng ít nhất họ thường hiểu PR mình tạo ra và khu vực mình phụ trách
    • Trải nghiệm của tôi thì ngược lại. Tôi đã khiến Claude hiểu hai codebase lớn mà phần lớn do tôi tự viết và cũng tự thiết kế khái niệm, ở mức sâu hơn nhiều so với tôi; giờ đây Claude đang giải thích lại cho tôi những thứ tôi đã quên từ lâu

  • Trải nghiệm này quá giống với tôi nên thấy nhẹ nhõm. Nó làm tôi nhớ đến gu và năng lực phán đoán đang thường được nhắc tới gần đây
    Chất lượng kiến trúc có thể giống thời trang ở chỗ không có đáp án khách quan duy nhất, và sau khi giao lý trí cùng tính hợp lý cho máy móc, có lẽ con người sẽ phải học về thẩm mỹ
    Không còn khoảng nghỉ mà quá trình triển khai từng mang lại, nên phải liên tục phán đoán những sự đánh đổi giữa các lựa chọn gần như ngang nhau, rất dễ mệt; ngay cả với Fable hay các mô hình tầm cỡ GPT-5.6 thì việc review code vẫn cần thiết. Tôi thường ghi nhớ các lỗi nhỏ, rồi khi đủ nhiều vấn đề tương tự tích lại thì sửa một lượt
    Với agent cũng phải chọn giữa việc cộng tác chặt chẽ với một số ít nhân sự xuất sắc, hay vận hành một lượng lớn sub-agent rồi tự động sàng lọc ngọc đá. Gu của tôi là một đội ngũ ít người nhưng được phối hợp ở mức rất cao, nhưng liệu đó có phải đáp án đúng hay không thì thời gian sẽ trả lời

    • Jake Nations từng nói khi còn làm ở Netflix rằng: “Tôi biết pattern xấu ngay khi nhìn thấy nó vì tôi đã từng debug nó lúc 2 giờ sáng”
      Gu là trực giác được tôi luyện bằng khổ sở, có được từ mọi anti-pattern và bãi mìn mà ta đã tự tay kích nổ trong quá trình làm phần mềm
      https://www.youtube.com/watch?v=eIoohUmYpGI

  • Người này trước đây cũng từng thừa nhận đã bịa ra những nội dung không có căn cứ rồi phát tán, gây thiệt hại, mà lần này cũng không hề có bằng chứng cho thấy ý tưởng đó là tốt. Cần có lý do để tin lại anh ta

    • Rốt cuộc đây chỉ là một quảng cáo dài để PR cho sản phẩm Humanlayer của anh ta

  • Vấn đề nổi bật nhất lúc này là trải nghiệm người dùng khi review PR
    Tôi vốn luôn ghét màn hình PR của GitHub nên thường tải branch về và dùng $EDITOR để xem khác biệt, nhưng giờ thì không có lý do gì phải bất tiện như vậy nữa. Ngay cả Linear, vốn không phải công ty làm về code review, cũng dùng mô hình nhỏ để nhóm các thay đổi theo chủ đề, gắn mô tả và sắp xếp theo mức độ quan trọng, cung cấp tính năng cơ bản tốt hơn GitHub
    Không cần thêm việc cho người review hay người gửi request mà vẫn giảm tải nhận thức rất nhiều, và các tính năng tiếp theo như trực quan hóa cũng hoàn toàn khả thi. Tôi tò mò liệu cách tiếp cận này có sai không, hay đã có phương án thay thế nào được dùng rộng rãi rồi
    https://linear.app/docs/diffs#guides

    • Những đội ngũ giỏi nhất không review PR. Họ cùng thảo luận thiết kế và kiến trúc trong lúc thay đổi đang diễn ra, tự động hóa các kiểm tra vụn vặt như linting và formatting, đồng thời giữ kỷ luật nghiêm ngặt với quy tắc không làm hỏng build nhờ nhiều test và kiểm tra
      Nếu còn có cả quy trình rollback mạnh mẽ, thì cổng kiểm soát PR sẽ trở thành một bước thừa vì không bắt được vấn đề nào thực sự hữu ích, và các thành viên có thể merge thẳng cho nhau
    • Chính sách dùng code review như cổng tích hợp là vô nghĩa. Agent của tôi có thể thay tôi trả lời và review các yêu cầu review, thậm chí còn lách được cả chính sách công ty bắt buộc review bởi con người
      Cái cần review là phần mềm đang thực sự chạy, và cần có một hệ thống có thể trình diễn ngay phương án thay đổi. Tỷ trọng của code và spec sẽ giảm đi, còn việc sản xuất phần mềm trong tương lai sẽ gần với Replit hơn là GitHub
    • Ngay cả trước thời agent, review PR đã khó rồi, còn bây giờ số PR cần review lại tăng lên nên tình hình tệ hơn nhiều
    • Tôi cứ nghĩ việc nhóm thay đổi file theo chủ đề và giải thích chúng vốn là việc mà commit nên làm chứ?
    • Tôi không đánh giá cao khả năng của LLM trong việc xác định mức độ quan trọng hay tóm tắt code
      Tôi đã thử cách tiếp cận dựa trên Tree-sitter là https://github.com/0x007BA7/codebook và khá thích. Dù chưa đến mức dùng được trong production, nhưng vẫn có dư địa để sản phẩm hóa những cách làm tương tự

  • Tôi có cảm giác lẫn lộn về software factory
    Sản phẩm cốt lõi có quy mô lớn nên mọi thay đổi đều cần đầu vào từ con người, nhưng tự động hóa các việc như refactor nhẹ, viết test hay thay đổi UI thì lại hoạt động tốt. Ngược lại, trong các thử nghiệm nhỏ, dù code tạo ra chưa có gì đặc biệt, tôi vẫn thấy tiềm năng để mở rộng về sau, và tin rằng có thể thiết kế chiến lược và kiến trúc mới với tiền đề ngay từ đầu là agent sẽ viết chúng
    Tôi đã ghi lại các thử nghiệm công khai không can thiệp định hướng tại https://relentless.works/. Tôi cũng đang quan sát một trading agent mà không can thiệp; hiện lỗ khoảng 3% nhưng chưa mất sạch, và gần đây còn mở vị thế mới
    Software factory có vẻ khả thi, nhưng cần những khái niệm mới, sự thay đổi trong tư duy, và cả sự kiên nhẫn để chờ AI

  • Có một vấn đề mang tính nền tảng ngay từ việc “làm phần mềm” thực chất là gì
    Nếu chỉ giao ticket trên GitHub cho AI agent rồi ngồi nghỉ, thì rất có thể các lớp trừu tượng và tầng gián tiếp sẽ tiếp tục chồng chất. Trong lúc code, ta sẽ nảy ra những góc nhìn như “Dùng Redis ở đây thì sao?”, “API vốn đã trả về đúng dữ liệu cần mà?”, “Hãy loại khách hàng không hoạt động trong 1 năm qua khỏi báo cáo”, và đến một lúc nào đó con người phải tự đưa ra những phán đoán đó

    • Điều này nối với quan điểm lập trình là sự kiến tạo lý thuyết, vốn rất dễ bị đánh mất trong agent coding
      https://gwern.net/doc/cs/algorithm/1985-naur.pdf
    • Hoàn toàn đồng ý. Các workflow và bộ kỹ thuật dành cho coding agent đang được dùng rộng rãi đều được thiết kế để khơi ra insight và trực giác của con người trong quá trình lập kế hoạch hoặc viết code
      Chế độ plan của Claude Code, mattpocock/skills, obra/superpowers, và luồng nghiên cứu-lập kế hoạch-triển khai đều thuộc nhóm này
    • Điều đó đúng nếu bạn là lập trình viên top 1% suy nghĩ theo cách như vậy, nhưng so với phần lớn lập trình viên tôi đã gặp trong hàng chục năm qua thì các mô hình hiện tại giỏi hơn con người, trừ nhóm top đầu
    • Máy móc hiện vẫn có thể tạo ra cả những thứ chưa hề tồn tại, đúng theo những gì được yêu cầu. Quan trọng không phải là tự động hóa hoàn toàn, mà là năng lực yêu cầu cho đúng bằng cách vận dụng lý thuyết thông tin, lý thuyết quyết định và lý thuyết sáng tạo
      Trí nhớ của mô hình không được hợp nhất như cách con người đi ngủ rồi khắc nó vào trọng số của mình, mà giống như đưa ghi chú cho một người không nhớ nổi ngày hôm qua. Một hệ thống entropy cao theo thời gian lại làm tăng entropy của dự án thì cũng chẳng có gì đáng ngạc nhiên
    • Vấn đề “API vốn đã trả về dữ liệu cần thiết” là đặc biệt lớn. Tôi đã nhiều lần thấy các mô hình hàng đầu giải quyết một việc chỉ cần đổi đúng một dòng ở client bằng cách bắt chước pattern client-server sẵn có, rồi tiêu tốn một đống code và token
      Các dự án vibe coding đầy rẫy kiểu lãng phí này, nhưng người viết prompt có thể không nhận ra. Việc công cụ giúp tiết kiệm thời gian mỗi ngày là rất tốt, nhưng overengineering thì thực sự nghiêm trọng

  • Thật nực cười khi bàn về nhà máy phần mềm không người vận hành mà lại đo năng suất bằng số lượng PR hay commit. Nếu đi theo hướng đó thì chắc phải gọi đơn vị mã là bos (bunch of shit) từ lâu rồi

    • Họ đang lặp lại sai lầm cũ là tối ưu tỷ lệ vận hành thay vì toàn bộ thông lượng. Đây là vấn đề Eli Goldratt đã bàn từ thập niên 1970 mà đến giờ vẫn chưa học được
      https://en.wikipedia.org/wiki/The_Goal_(novel)
    • Nếu muốn vận hành nghiêm túc khái niệm này thì không thể chấp nhận các chỉ số phù phiếm hay sự thiếu hiểu biết về code. Càng nhiều tự động hóa thì tiêu chuẩn không hạ xuống mà càng phải cao hơn, đồng thời cần nhiều toán học và công sức hơn rất nhiều
      Nó gần giống một sự đánh đổi kiểu startup cực đoan: tiết kiệm vốn nhưng đổ vào đó nhiều năm cuộc đời