- Bài phỏng vấn nói về quy trình làm việc của Peter Steinberger, người đã ghi nhận hơn 6.600 commit chỉ riêng trong tháng 1 khi tận dụng AI agent để làm việc một mình
- Moltbot (trước đây là Clawdbot) hiện đang ghi nhận mức tăng sao nhanh nhất lịch sử GitHub, đồng thời vượt qua Claude Code và Codex về lượng tìm kiếm trên Google
- Peter phát triển theo cách vận hành đồng thời 5~10 agent, tập trung vào thảo luận kiến trúc thay vì review code
- Để cộng tác hiệu quả với AI, bắt buộc phải thiết kế một vòng lặp cho phép agent tự biên dịch, lint, kiểm thử và tự xác minh
- Những kỹ sư thiên về tư duy tập trung vào kết quả và thiết kế hệ thống hơn là chi tiết triển khai sẽ thích nghi tốt hơn với phát triển AI-native
Peter Steinberger là ai
- Nhà sáng lập đã phát triển PSPDFKit thành một doanh nghiệp công cụ dành cho lập trình viên ở quy mô toàn cầu
- Ông quay trở lại sau 3 năm nghỉ ngơi, và lần này đặt LLM và AI agent vào trung tâm quy trình làm việc
- Kinh nghiệm điều hành đội ngũ hơn 70 lập trình viên đã dạy ông cách từ bỏ chủ nghĩa hoàn hảo, và khả năng này hiện giúp nâng cao hiệu quả khi làm việc với AI agent
- Trong riêng tháng 1 năm 2026, ông ghi nhận hơn 6.600 commit, cho thấy mức năng suất hiếm thấy đối với một lập trình viên cá nhân
- Toàn bộ công việc đều diễn ra trong dự án cá nhân chứ không phải ở công ty, và ông đơn giản là đang tận hưởng việc phát triển phần mềm
Moltbot và đà tăng trưởng bùng nổ
- Ghi nhận tốc độ tăng sao nhanh nhất lịch sử trên GitHub; ngay cả khi so với Tailwind CSS, đường cong tăng trưởng này cũng ở mức chưa từng có
- Trong tuần qua, lượng tìm kiếm trên Google cao hơn cả Claude Code và Codex cộng lại
- Cách Peter mô tả: "Nhìn vào commit thì có thể tưởng là một công ty, nhưng thật ra chỉ là một người đang code vui ở nhà"
10 bài học cốt lõi từ quy trình làm việc dựa trên AI agent
- Từ bỏ chủ nghĩa hoàn hảo: nếu chấp nhận rằng code không phải lúc nào cũng hợp gu của mình, bạn sẽ làm việc với agent hiệu quả hơn
- Khép kín vòng lặp: cần thiết kế hệ thống để AI agent có thể tự biên dịch, lint, chạy và xác minh
- Pull Request đã chết, và "Prompt Request" đang nổi lên: việc xem prompt tạo ra code quan trọng hơn là xem bản thân đoạn code đó
- Code review dần biến mất và được thay bằng thảo luận kiến trúc: ngay cả trên Discord, ông cũng chỉ bàn với đội ngũ cốt lõi về kiến trúc và các quyết định lớn thay vì code
- Vận hành đồng thời 5~10 agent để duy trì trạng thái "flow"
- Mỗi agent xử lý song song một tính năng khác nhau
- Đầu tư đáng kể thời gian vào việc lập kế hoạch, và ưu tiên Codex
- Trao đổi lặp đi lặp lại với agent để xây dựng kế hoạch vững chắc
- Thách thức kế hoạch, chỉnh sửa, phản biện rồi chỉ khi hài lòng mới thực thi và chuyển sang việc tiếp theo
- Codex có thể tự làm việc độc lập trong thời gian dài, còn Claude Code thường quay lại để hỏi làm rõ nên dễ gây phân tâm
- Cố ý dùng prompt ít cụ thể hơn để đôi khi khám phá ra những lời giải bất ngờ
- CI cục bộ tốt hơn CI từ xa: thay vì chờ 10 phút cho CI từ xa, agent chạy test ngay trên máy cục bộ
- Phần lớn code chỉ là các phép biến đổi dữ liệu nhàm chán: không cần quá ám ảnh, hãy dồn năng lượng vào thiết kế hệ thống
- Những kỹ sư quan tâm đến kết quả hơn là chi tiết triển khai sẽ cộng tác với AI tốt hơn
- Những kỹ sư thích giải câu đố thuật toán thường gặp khó khi chuyển sang kiểu làm việc "AI-native"
- Người thích đưa sản phẩm ra mắt sẽ thích nghi tốt hơn
Góc nhìn về tương lai của kỹ nghệ phần mềm
- AI không giết chết kỹ nghệ phần mềm, mà thực tế còn là điều ngược lại
- Peter là kiểu kiến trúc sư phần mềm luôn giữ cấu trúc cấp cao của dự án trong đầu
- Ông quan tâm sâu đến kiến trúc, nợ kỹ thuật, khả năng mở rộng, tính mô-đun
- Một trong những lý do Moltbot thành công là khả năng mở rộng rất tốt
- Ông đầu tư năng lượng để việc thêm tính năng mới trở nên dễ dàng
- Với vai trò "nhà độc tài nhân từ" của dự án, ông duy trì sự nhất quán về định hướng và phong cách
Bối cảnh và giới hạn
- Moltbot là một dự án mang tính thử nghiệm, giả định các vòng lặp nhanh, và hiện vẫn đang tiếp tục được phát triển
- "Di chuyển thật nhanh và phá vỡ mọi thứ" là cách duy nhất để kiểu dự án này thành công
- Rất khó áp dụng nguyên xi cho mọi đội ngũ hay mọi sản phẩm
- Dù vậy, đây vẫn được xem là một trường hợp phát hiện ra nhu cầu mà ngay cả các phòng thí nghiệm AI lớn cũng chưa lường trước
26 bình luận
Không hiểu vì sao người ta cứ nhầm một cỗ máy dự đoán với một cỗ máy biết suy nghĩ.
Vì máy tính bỏ túi hoạt động dựa trên thuật toán tất định, nên tôi cho rằng phép ví von đó không phù hợp.
Và tôi không phản đối việc sử dụng AI, mà tôi cho rằng có vấn đề ở cách sử dụng AI được giới thiệu trong bài viết này.
Vì nó được tạo theo cấu trúc mà chúng ta hình dung.
Nền tảng là mang nguyên cách các tế bào não kết nối với nhau, nên không thể nhìn rõ chính xác nó suy nghĩ qua quá trình nào.
"Suy nghĩ" cũng vậy, vì ta không biết trong não nó xuất hiện qua quá trình nào nên hình dạng cơ bản và hiện tượng là giống nhau.
Vì thế mới có quan điểm cho rằng não người cũng giống như một cỗ máy dự đoán.
Cũng có những lĩnh vực xem thứ mà ta gọi là suy nghĩ là một hiện tượng mang tính cơ học, và cho rằng việc hack não cũng là điều có thể.
Cả hai đều là hộp đen, và cấu trúc cơ bản thì giống nhau, nhưng không vì thế mà có thể khẳng định chúng tương tự nhau.
Không hoàn toàn giống hệt nhau, nhưng cũng không hoàn toàn khác nhau cùng một lúc.
Nói là giống nhau nghĩa là có những phần chung,
rốt cuộc việc mọi người có ý kiến khác nhau có lẽ là do góc nhìn về mức độ giống nhau đến đâu.
Không thể xem là giống hệt nhau, nhưng tôi cho rằng là tương tự,
và tôi nghĩ như vậy từ góc độ về dự đoán và suy nghĩ trong bình luận của geek12356.
Đồng thời, tôi cũng có quan điểm rằng vì trí tuệ của nó cao hơn con người nên nó khác con người.
Đừng trở thành kiểu tiền bối mà trong khi người khác dùng hàm Excel để tính hàng trăm dòng chỉ trong 1 giây, mình thì lại tự bấm máy tính từng phép một rồi còn bảo: "Đừng dùng hàm."
Mình nghĩ phép so sánh với hàm Excel và máy tính có vẻ không đúng lắm.
Nếu LLM có độ chính xác 100% thì mình công nhận..
Không hiểu nổi tại sao lại phản đối việc không dùng máy tính nhưng vẫn gảy bàn tính.
Trước hết thì với một sản phẩm được phát triển theo kiểu này, tôi không muốn dùng chút nào.
Nếu là phần mềm cho xe cộ hay hàng không được phát triển theo kiểu này, thì tôi càng không dám dùng hơn.
Vì thế nên người Nhật đến giờ phần lớn vẫn dùng fax.
Nhìn bề ngoài thì có vẻ ngầu đấy, nhưng nếu sau này phát sinh vấn đề phải sửa, hoặc xuất hiện lỗ hổng bảo mật, thì chi phí chắc sẽ khổng lồ..
Có vẻ như đã có khá nhiều lỗ hổng được báo cáo rồi.
Rốt cuộc con người lại trở nên quan trọng hơn
Không biết nên nhìn nhận điều này theo hướng tích cực hay tiêu cực..
Có lẽ mọi người đã và đang dùng nó rồi mà không nhận ra.
Nếu đoạn mã bị viết cẩu thả như vậy mà phát sinh vấn đề, thì rốt cuộc ai sẽ là người phải đi dọn dẹp hậu quả... Nếu code cứ được tạo ra theo kiểu này... một ngày nào đó thứ địa ngục ấy chắc chắn sẽ tới.
Thật ngạc nhiên khi thay vì Pull Request lại là "Prompt Request".
Từ rất lâu trước đây tôi từng rất quan tâm đến MDA, nhưng vì quá phi thực tế nên đã từ bỏ; vậy mà giờ điều này lại được hiện thực hóa như thế này.
Sẽ thật tuyệt nếu đây được cung cấp như một tính năng ở những nơi như GitHub.
"Di chuyển nhanh và phá vỡ mọi thứ"
Câu này thật sự rất đồng cảm
Lỗi lớn là ở tôi vì đã cố đọc đoạn mã do AI viết.
Có vẻ như MoltBot đang đẩy lên một lượng PR tự sửa lỗi khổng lồ nên chắc chính tác giả cũng không thể tự mình rà soát hết được đâu lol. Việc số lượng issue và PR gần như ngang nhau có lẽ là vì đây là kiểu vấn đề mà thay vì viết issue rồi chờ đợi, chỉ cần bảo MoltBot tạo PR rồi push lên là xong lol.
Chỉ là việc AI phân biệt chó với mèo giờ đã tiến lại gần chúng ta hơn một chút thôi... Tôi không biết liệu nó có giá trị gì hơn thế không.
Nghe nói anh ấy thích Codex, nên tôi khá tò mò về phần thiết lập.
Dùng Codex trong 140 ngày, làm 115 dự án, và hình như tôi đã tiêu hơn 250 tỷ token - link
Chắc khoảng 75 triệu won. Lập trình viên AI native làm một mình thì trước hết phải exit và có kha khá tiền mới được..
250 tỷ token à, thật sự tôi không thể hình dung nổi...