- Vận hành một quy trình "nhà máy AI" cá nhân để tự động hóa từ sinh mã đến kiểm chứng bằng cách tận dụng nhiều tác nhân AI (claude/o3/sonnet, v.v.)
- Điểm cốt lõi là khi phát sinh vấn đề, không sửa trực tiếp mã (Output) mà cải thiện đầu vào (Input) như kế hoạch, prompt, cấu hình tác nhân để nâng mức độ tự động hóa
- Bằng cách liên tục cải thiện đầu vào như vậy, các tác nhân sẽ không ngừng tiến bộ và tối đa hóa năng suất cho các công việc lặp lại
- Phân vai cho từng tác nhân: lập kế hoạch (o3/sonnet4), thực thi (sonnet3.7/4), kiểm chứng (o3/sonnet4), v.v. để triển khai xử lý song song và vòng phản hồi tự động
- Ngay cả lỗi mã hay vấn đề về style cũng được phản ánh vào mẫu kế hoạch để lần sinh tiếp theo được cải thiện, giúp chính nhà máy phát triển thông qua việc lặp đi lặp lại cải thiện đầu vào
Tổng quan về nhà máy AI và các nguyên tắc cốt lõi
- Mở nhiều cửa sổ claude code trên các git-worktree khác nhau để duy trì môi trường làm việc tách biệt
- o3 và sonnet 4 được dùng cho lập kế hoạch, sonnet 3.7 hoặc sonnet 4 cho thực thi, còn o3 đảm nhiệm đánh giá kết quả
- Lập kế hoạch, thực thi, kiểm chứng được phân chia song song theo từng tác nhân để tăng hiệu quả
Nguyên tắc cốt lõi – "Thay vì sửa kết quả (Output), hãy cải thiện chính đầu vào (Input)"
- Khi có vấn đề, không vá trực tiếp đoạn mã đã sinh ra mà điều chỉnh kế hoạch, prompt, tỷ lệ phối trộn tác nhân để theo đuổi cải tiến tự động
- Ý tưởng là tạo ra một mạng lưới tác nhân AI kiểu nhà máy có thể tự phát triển, giống như game Factorio
- Trong cấu trúc này, vòng lặp từ lập kế hoạch - viết mã - kiểm chứng - cải thiện vận hành tuần hoàn, hình thành môi trường nơi các tác nhân AI tự sản xuất/kiểm chứng/cải thiện mã
Quy trình làm việc hằng ngày – cấu trúc của nhà máy
- Giao diện chính là claude code; ở môi trường local sử dụng mcp, Goose (để kết nối mô hình Azure OpenAI), o3, v.v.
Bước 1: Lập kế hoạch (Planning)
- Nhập tác vụ (task) cấp cao vào claude code → o3 đặt thêm câu hỏi rồi tạo bản kế hoạch (
<task>-plan.md)
- Bản kế hoạch bao gồm yêu cầu gốc và kế hoạch triển khai
Bước 2: Thực thi (Execution)
- sonnet 4 xem lại kế hoạch rồi chuyển thành danh sách tác vụ
- claude code thực hiện công việc và dùng sonnet 3.7 hoặc 4 tùy theo độ phức tạp của bài toán
- claude để lại lịch sử commit ở từng bước công việc, nên có thể rollback dễ dàng khi phát sinh vấn đề
Bước 3: Kiểm chứng và phản hồi (Verification → Feedback)
- sonnet 4 thực hiện kiểm chứng ban đầu với mã đã sinh dựa trên kế hoạch
- Sau đó o3 kiểm chứng nghiêm ngặt hơn bằng cách đối chiếu với kế hoạch và yêu cầu ban đầu
- o3 chỉ ra rất gắt các đoạn mã không cần thiết (ví dụ: cờ lint ignore) hoặc cấu trúc đã lỗi thời
- Các vấn đề lộ ra trong quá trình kiểm chứng không được sửa trực tiếp trong mã mà được phản ánh thành cải tiến mẫu kế hoạch
- Tận dụng git worktree để chạy song song nhiều phiên bản claude code, cho phép xử lý đồng thời nhiều công việc
Vì sao "đầu vào" quan trọng hơn "đầu ra"
- Thành phẩm (Output) có thể bỏ đi, nhưng kế hoạch/prompt (Input) là tài sản tích lũy được liên tục lưu lại và cải thiện
- Nếu debug ở phần đầu vào (kế hoạch, prompt), hiệu quả có thể mở rộng sang mọi công việc về sau
- Điều này biến tác nhân từ một công cụ sinh đơn thuần thành thực thể có thể tự học và cộng tác
- Ví dụ: buộc mã vốn nạp toàn bộ CSV vào bộ nhớ phải chuyển sang xử lý stream, rồi phản ánh mẫu đó vào kế hoạch cho mọi CSV sau này để có thể tự động kiểm chứng về sau
Mở rộng nhà máy và cộng tác giữa các tác nhân
- Dùng MCP để phân công các tác nhân chuyên biệt cho các công việc khác nhau và song song hóa chúng
- Ví dụ: gom toàn bộ mã Clojure và vận hành một tác nhân chuyên áp dụng quy tắc style cục bộ, giúp claude hiệu chỉnh các vấn đề style phát sinh trong chu kỳ lint/test/debug
- Ngay cả trong mã thư viện nội bộ, cũng tăng năng suất và tính nhất quán bằng cách thay thế retry kiểu cũ và việc dùng
Thread/sleep bằng thư viện retry nội bộ
- Xây dựng nhiều tác nhân đơn vị nhỏ rồi kết hợp theo từng tiểu tác vụ cụ thể để có thể tự động hóa cả quy trình làm việc phức tạp
- Ví dụ: từ đặc tả API và business case, dùng tổ hợp tác nhân để tự động xử lý từ tích hợp, kiểm thử đến tài liệu hóa
- Điểm cốt lõi: liên tục sửa đầu vào rồi chạy lặp lại; khi thất bại/đình trệ/thiếu ngữ cảnh thì phản ánh feedback vào lần thử tiếp theo để cải thiện
- Bản thân mã nguồn là đồ tiêu hao, tài sản thực sự là chỉ thị đầu vào và cấu hình tác nhân
- Mọi bài học từ thất bại, đình trệ, thiếu ngữ cảnh, v.v. đều được phản ánh vào đầu vào tiếp theo để hoàn thiện vòng lặp nhà máy
Các bước tiếp theo và định hướng tương lai
- Tăng cường điều phối tổng thể giữa các tác nhân để theo dõi toàn bộ workflow và thúc đẩy đưa vào tự động hóa
- Kết nối tốt hơn tài liệu nghiệp vụ và thông tin của tác nhân, đồng thời cải thiện để có thể tận dụng hiệu quả hơn bằng cách chủ yếu nắm bắt thông tin trừu tượng ở cấp cao
- Hướng tới triển khai các workflow ngày càng phức tạp, đồng thời mở rộng hợp tác và tương tác phức tạp giữa các tác nhân
- Cũng đang tìm cách tận dụng tối đa hạn ngạch token của nhiều nhà cung cấp và chuyển đổi dễ dàng giữa họ (đặc biệt để ứng phó với giới hạn token của bedrock sonnet 4)
Kết luận
- Hiện tại, nhà máy AI đã đạt mức tự động hóa thường nhật cho việc sinh và kiểm chứng mã, đến mức mã có thể được triển khai ngay trong lúc uống một tách cà phê
- Dù chưa hoàn toàn tự động, nguyên tắc "cải thiện đầu vào thay vì sửa đầu ra" đã trở thành bản chất của nhà máy
1 bình luận
Ý kiến trên Hacker News
Tôi nghĩ bài này sẽ gần như không thể hiểu nổi với những ai chưa từng trải qua khoảnh khắc “aha” với Claude Code
Nếu gỡ bỏ giới hạn quyền bằng
claude --dangerously-skip-permissionsrồi giao cho nó một vấn đề phức tạp, bạn có thể thấy Claude tự do sử dụng nhiều công cụ khác nhau để giải quyết vấn đềHôm nay tôi còn cho nó tự biên dịch, chạy và debug một trình tạo fractal Mandelbrot viết bằng 486 assembly trong Docker
Nó xử lý cực kỳ xuất sắc
liên kết gist
Tôi nghĩ đây là một ví dụ cực kỳ dễ với kiểu IDE hay LLM như vậy
Assembly đã có rất nhiều trong tập dữ liệu huấn luyện, Docker cũng thế
Tôi cũng từng để Cursor tự do tung hoành trong codebase của mình
Tôi kỳ vọng các công cụ mới nhất rồi sẽ thật sự đạt tới mức đó, nhưng cảm giác là hiện tại vẫn chưa tới
Tôi cũng muốn giới thiệu thêm video này của Dagger (và nhà sáng lập Docker) tại hội nghị AI Engineer
Video này cũng có thể hơi khó hiểu
Tôi viết ra vì nghĩ biết đâu sẽ hữu ích
Tôi đã hạ từ Claude max xuống pro và với 20 USD/tháng thì giới hạn sử dụng vẫn đủ rộng
Có vẻ họ đang cạnh tranh với Gemini CLI nên giờ tôi vui vì phải trả ít tiền hơn
Tôi nghĩ gần như mọi LLM đều có thể xử lý loại ví dụ hay ngữ cảnh này mà không gặp khó khăn gì
Tôi từng lặp lại hơn 30 lần việc nâng cấp dependency Rust phức tạp hơn nhiều, xử lý bằng mã wasm tùy chỉnh
Claude sẽ kết nối nhiều công cụ như context7 hay mcp-lsp để thu thập chi tiết
Nhưng dùng lâu rồi sẽ đụng trần; nếu đẩy sang các bài khó và tinh vi hơn thì điểm yếu sẽ lộ ra
Về câu “giao cho
claude --dangerously-skip-permissionsmột vấn đề phức tạp thì nó sẽ dùng nhiều công cụ để giải quyết”Tôi từng ngồi nhìn Claude cố sửa code theo cách sai suốt hơn một tiếng
Cuối cùng tôi phải can thiệp và bảo: “hãy viết unit test trước, sau khi test pass thì viết code rồi báo lại cho tôi”
Claude Code đúng là một công cụ rất ấn tượng, nhưng thực tế là vẫn phải liên tục lặp lại cho nó bản đồ kiến trúc cơ bản
Tôi nghĩ rất khó đánh giá các thiết lập kiểu này nếu không biết đầu ra code thực sự được dùng như thế nào
Nếu chỉ là một ứng dụng vibe coding dùng cá nhân thì nghe rất dễ tin,
nhưng nói rằng nó viết được code chất lượng cao trong môi trường production phức tạp thì khó mà bị thuyết phục
Hoàn toàn đồng ý
Tôi tăng tốc độ lập trình lên đáng kể nhờ Claude Code, nhưng với mọi thay đổi trong code tôi luôn tự kiểm tra để xác nhận hệ thống tối ưu đang được tạo ra
Vài lần tôi chỉ để nó tự chạy thì cuối cùng lại giao bug cho người dùng
Thật ra tôi không hiểu rõ lắm workflow hay khái niệm mà bài này đang mô tả
Có lẽ vì giải thích hơi mơ hồ
Tôi thường xuyên xử lý các hệ thống production phức tạp bằng cấu trúc nhiều agent trò chuyện với nhau, agent bất đồng bộ, git work tree các kiểu
Không phải là tôi tuyệt đối không sửa đầu ra, nhưng nếu kết quả không như ý thì tôi xem đó là tín hiệu để cải thiện workflow của mình
Tôi cũng đang thử một workflow tương tự nên muốn chia sẻ trải nghiệm của mình
Codebase Go tôi xử lý có quy mô hàng trăm nghìn dòng và thực sự đang được hàng chục nghìn đến hàng trăm nghìn người dùng B2C sử dụng
Hiệu năng thì dư dả, nhưng độ chính xác và độ tin cậy cực kỳ quan trọng vì đây là lĩnh vực tài chính
Tôi ở trong môi trường chỉ dùng khóa OpenAI nên chỉ dùng codex-cli và vài script đơn giản để thiết lập cơ bản như clone repo, dựng agent, chạy prompt
Các instance codex báo đến lượt tôi bằng thông báo hệ thống, và tôi dùng fzf để attach vào phiên tmux khi cần
Tôi chưa dùng MCP nhưng đã đưa vào danh sách quan tâm
Cách này cực kỳ hữu ích khi xử lý các tác vụ nhỏ lẻ, và giờ tôi tạo được nhiều PR vụn hơn hẳn
Ẩn dụ “cattle not pets” vẫn rất đúng; với việc nhỏ tôi chỉ quăng prompt thật nhanh để giảm xao nhãng
Với công việc lớn hơn thì có vẻ vẫn chưa hợp, có lẽ vì tôi cũng chưa tạo được đủ context flywheel
Phần lớn thời gian tôi vẫn luôn tự đọc và chỉnh lại code kết quả rồi mới đưa vào review
Việc quản lý thay đổi cũng gần như làm thủ công hết, tự branch/commit/push
Tôi cũng đã thử vài công cụ tự động hóa nhưng vẫn chưa chuyển hẳn sang chúng
Tôi đồng ý 100% với tư duy “đừng sửa đầu ra, hãy sửa đầu vào”
Ngay cả khi không có AI thì đây cũng là một nguyên tắc cực kỳ mạnh, và ngành đang dần chấp nhận nó
Với các quy trình không quyết định như LLM thì áp dụng không dễ, và cảm giác gần với luyện tập hơn là khoa học
Cảm ơn vì bài viết hay
Tôi có giới thiệu một workflow tương tự nhưng đơn giản hơn đôi chút trong bài “Vibe Specs”
bài blog liên quan
Tôi áp dụng quy tắc này cho toàn bộ codebase, và khiến AI hành xử khác đi ở hai điểm
(1) trước hết phải đặt câu hỏi
(2) trước khi code thì phải tạo tài liệu
spec.mdTinh thần thì giống nhau, nhưng tôi chỉ giới hạn trong một LLM
Có vẻ đa số chúng ta đều đang thử theo hướng tương tự
Là nhà phát triển cá nhân, tôi thử nghiệm đủ kiểu tự động hóa năng suất theo cách nghĩ thiên về kỹ thuật
Với tôi, mục tiêu cuối cùng là để agent lấy được độ tin cậy với code từ các bài test e2e do nó tự sinh ra, bất kể phần triển khai ra sao
Tôi vẫn chưa hoàn toàn thành công
Giờ Claude Code cũng hỗ trợ luồng này một cách native bằng “plan mode”
Việc tự tay tạo file
.mdthực ra khá chậm và phiềnÝ tưởng cốt lõi là bạn có thể liên tục tài liệu hóa hệ thống phải làm gì (cả ở mức cao lẫn tính năng chi tiết), sẽ chứng minh hành vi đó như thế nào, và cả cách triển khai như kiến trúc hay style code
Lý do dùng nhiều model là để giảm thiên lệch và tăng lựa chọn tinh chỉnh phù hợp cho từng tác vụ
Đến một ngày nào đó, ngay cả những hệ thống lớn và phức tạp cũng có thể được tái tạo lại dựa trên một tập hợp yêu cầu, và khi đó phần mềm mới thực sự khớp với đặc tả yêu cầu
Lúc ấy, “legacy code” còn lại sẽ chỉ là tài liệu đặc tả legacy
Quan điểm ở đây là hãy sửa đặc tả yêu cầu thay vì sửa code được sinh ra
ảnh meme liên quan
Tôi rất muốn biết rốt cuộc người ta đang thực sự làm ra cái gì
Mỗi lần nói về workflow AI là lại khó biết liệu đó có phải chỉ là một luồng kiểu mơ mộng nửa vời, hay là đang được dùng thực sự hiệu quả
Khi LLM viết hết code thì tôi đơn giản là mất hứng
Trong khoảng 50 dự án, chỉ có 2 cái được làm bằng LLM, mà tôi vẫn phải tự sửa tay
Còn lại thì phần nhiều chỉ là cảm giác “có cái này thì hay nhỉ”, chứ thực ra tôi chẳng mấy quan tâm đến kết quả
Rốt cuộc tôi bị mắc kẹt trong vòng lặp vật lộn với đủ loại model và chi tiết triển khai, rồi khi hành vi mong muốn không xuất hiện thì lại ném vào tài liệu thiết kế, prompt, dữ liệu ví dụ để tiếp tục cãi nhau với máy tính
Cứ để nó hỗ trợ bổ sung code từng chút một thì nhanh hơn nhiều và đỡ căng thẳng hơn
Nhìn lại thì cảm giác chỉ tốn thời gian và tiền bạc, còn đầu ra là phần mềm chạy cầm chừng
Nếu có yêu cầu rõ ràng hoặc codebase sẵn có, và tôi chủ động dẫn dắt, thì agent khá hữu ích; nhưng mấy luồng kiểu vibe coding thì trừ script nhỏ hay app ngách ra, còn lại vừa không vui vừa khó đạt chất lượng mong muốn
Nó cũng đắt quá mức và code thì vẫn bừa bộn
Cuối cùng vẫn là cảm giác tốn thời gian tranh cãi bất tận với máy tính
Thà tự làm còn hơn nhiều
Vấn đề khi nhiều agent cùng làm việc trong các work tree riêng là mỗi agent lại nghĩ ra những ý tưởng hoàn toàn khác nhau ở mọi chi tiết, nên trải nghiệm người dùng không có chút thống nhất nào
Ví dụ, các agent làm dashboard Documents và dashboard Design sẽ thiết kế theo những góc nhìn hoàn toàn khác nhau
Không có sự thống nhất về thiết kế, cấu trúc, schema DB hay thiết kế API
Cùng một đầu vào mà đầu ra lại khác nhau
Rốt cuộc, để có tính nhất quán thì bạn cứ phải tăng thêm các file instruction, mà với dự án lớn thì mặc định đã lên tới vài nghìn dòng nên context window cũng không đủ
Kết luận của tôi là dùng một LLM nhỏ đã được huấn luyện trên các quy tắc và schema cụ thể sẽ phù hợp hơn
Có lẽ LLM nhỏ mới là đáp án, thay vì LLM lớn với không gian ý tưởng rộng như vũ trụ được điều khiển bằng prompt
Mỗi agent cho ra kết quả hoàn toàn khác nhau, thiết kế thiếu nhất quán
Cuối cùng vẫn cần một senior
Dù là AI hay con người, bạn vẫn phải tự cung cấp cấu trúc tối thiểu và độ linh hoạt để mọi thứ đi đúng hướng mong muốn
Nếu không có cấu trúc thì tự code còn tốt hơn nhiều
Tôi tự làm phiên bản đầu tiên, rồi sau đó bảo Claude Code “hãy làm theo ví dụ này”, như vậy giữ được sự nhất quán dễ hơn
Kiểu coding ADHD, cứ thử tạo sản phẩm bừa rồi lặp lại đến khi khớp à?
Có phải cứ tự viết code có thể mở rộng cho tương lai còn tốt hơn không
Quan điểm của tôi là đừng chỉ làm tăng dấu chân carbon một cách vô ích
Mục tiêu cuối cùng là loại nhà phát triển ra khỏi quy trình này
Chủ doanh nghiệp chỉ cần yêu cầu một ứng dụng CRUD mới là có thể đưa thẳng lên production
Tất nhiên kết quả sẽ đầy bug, chậm chạp, và lưu vào cơ sở dữ liệu chưa được xác thực, nhưng đó không phải việc của tôi
Kết lại bằng một cách diễn đạt gay gắt kiểu tu ừng ực một tách trà nóng
Lập trình đã thay đổi mãi mãi, và cần chấp nhận sự thay đổi đó càng sớm càng tốt
Nói “cứ tự viết code đi” giống như bảo mọi người tự chăm sóc xe ngựa vậy
Xe hơi cũng có hỏng, nhưng thế không có nghĩa là nên bám lấy cách cũ
Tôi không hiểu vì sao lúc nào cũng có người nói “cứ tự viết code có thể mở rộng cho tương lai đi”
Các trợ lý coding ngày nay cũng có thể viết code mở rộng được và dễ bảo trì theo kiểu zero-shot, nên tôi muốn hỏi là bạn đã thực sự thử yêu cầu như vậy chưa
Con người rốt cuộc cũng đi tìm đáp án bằng trial and error liên tục mà thôi
Khác biệt chỉ là người có nhiều kinh nghiệm thì mô phỏng được nhiều hơn trong đầu
Nếu xem dấu chân carbon là vấn đề, thì liệu các data center AI chạy bằng năng lượng tái tạo có được xem là ổn không
Tôi nghĩ ta cần tìm cách tích hợp AI vào workflow hiệu quả hơn
Những người đã chủ động áp dụng AI hẳn đều gặp các trăn trở tương tự, nhưng vẫn chưa có lời giải dứt khoát
Ở giai đoạn này, điều quan trọng là giao cho AI những vai trò tối thiểu nhưng thật chính xác
Ví dụ, với workflow agent dùng cho nghiên cứu cổ phiếu, tôi tạo hai AI là “Bullish Guy” và “Bearish Guy” để tranh luận ưu và nhược điểm của cùng một mã cổ phiếu
Khi cho chúng nghiên cứu từ hai lập trường đối lập như vậy, kết quả phân tích sẽ vừa toàn diện hơn vừa sâu hơn
Ý tưởng này thực ra lấy cảm hứng từ cách người ta tranh cãi trên mạng xã hội
Trong vibe-coding, đầu ra dường như hiếm khi vượt quá những thứ mang tính tự tham chiếu, và cuối cùng nó trông giống như một thú vui đắt đỏ kế thừa từ 3D printing: làm đồ chơi bất tận
Không biết có phải ví dụ kiểu “benchy” của vibe coding dạo này chỉ là app todo hay không
Ai tự thiết kế sản phẩm hay làm kỹ thuật đều dùng
Lý do duy nhất khiến người tiêu dùng phổ thông không dùng là vì gần như mọi món đồ nhựa họ cần đều có thể đặt ngay trên Amazon
Nếu là thời chưa có mua sắm trực tuyến thì nó đã hữu ích với người bình thường hơn rất nhiều
Có lẽ trong tương lai, đây sẽ là công nghệ thực sự cần thiết chủ yếu với những người có thể tự thiết kế file tùy chỉnh