pstack: cách Lauren Tan làm cho agent đáng tin

Phần lớn chúng ta dùng agent viết code theo cùng một kiểu: mở một con, rồi thêm con nữa, rồi thêm năm con, và cả buổi tối ngồi đọc những pull request mà mình không thật sự yên tâm. Lauren Tan đi theo hướng ngược lại. Chị làm cho một agent đáng tin trước đã, rồi mới cho nó nhân lên. Theo vài bài tường thuật về buổi livestream của chị hồi tháng 10, chị đã merge khoảng 2.500 PR chỉ trong tháng 8/2026, và chị nói rõ con số đó chưa bao giờ là mục tiêu.

Cách làm của chị được gói vào pstack, một plugin gồm nhiều skill, nay chạy được cả trong Grok Bot, đội agent lúc nào cũng trực của xAI. Mình đã đọc repo, các file skill và bài hướng dẫn chính chị viết. Dưới đây là những gì mình rút ra, và mình tách rõ đâu là điều kiểm chứng được, đâu là điều chưa.

Lauren Tan là ai

Trên mạng, Lauren Tan dùng tên poteto. README của pstack ghi chị từng làm với những codebase lớn ở Meta, Netflix và Cursor, và là thành viên nhóm lõi của React, nơi chị góp phần xây dựng và duy trì React Compiler; tên chị có trong các bài công bố React Compiler trên react.dev. Các nguồn thứ cấp cho biết thêm: chị làm ở Meta khoảng sáu năm, nghỉ vào tháng 3/2026, về Cursor ngay mùa xuân năm đó (tháng 3 hay tháng 4 tùy nguồn), và hiện làm phần kỹ thuật của Grok Bot. Có một bài giới thiệu nói chị tự học lập trình, khởi đầu từ macro Excel. Mình chưa tìm được nguồn gốc nào xác nhận chi tiết này, nên bạn cứ coi đó là một câu chuyện dễ thương hơn là một dữ kiện.

Ba ý tưởng

1. Tin được một agent rồi hãy nhân lên. Trong bài nói của mình, chị cho rằng năng suất đến từ sự tin cậy, chứ không phải từ việc mở thêm agent. Chị cũng bắt đầu như mọi người, với một đến năm agent, đọc từng cuộc hội thoại và sửa liên tục. Chạy song song mà chưa tin được thì chỉ ra nhiều PR tệ hơn, nhanh hơn.

2. Sửa tận gốc. Khi agent làm sai, nhắc thêm một câu trong prompt là cách sửa yếu nhất. Skill /correct của pstack leo theo từng bậc: sửa kiến trúc trước, rồi đến kiểu dữ liệu (type), rồi một luật lint hay một bước kiểm tra trong CI, rồi một bài test, và chỉ khi hết cách mới ghi vào tài liệu. Mỗi bước kiểm tra mới phải bắt được đúng cái lỗi đã xảy ra. Nguyên tắc đứng sau có tên encode lessons in structure: điều gì phải dặn đi dặn lại thì nên biến thành lint, script hoặc một kiểm tra lúc chạy. Theo lời chị kể, buổi sáng của chị thường có việc đọc lại lịch sử commit, revert những gì trông không ổn, rồi thêm một luật lint để lỗi đó không lặp lại.

3. Kiểm chứng là hạ tầng. Trong The Complete Guide to pstack, chị viết rằng kiểm chứng đơn giản là agent tự kiểm tra được việc mình làm, và một skill kiểm chứng tốt là công cụ quan trọng nhất của cả nhóm. Chị khuyên nên đối xử với nó như hạ tầng sống còn, có cả lịch trực on-call.

pstack có gì

Plugin nằm trong repo cursor/plugins của Cursor, giấy phép MIT. Cửa vào là /poteto-mode: nó đưa mỗi yêu cầu vào một trong 23 playbook (sửa bug, làm tính năng, refactor, điều tra…), giao phần code cho subagent, và không chịu báo « xong » khi chưa có bằng chứng. Trang pstack trong Grok Bot hiện 54 skill; con số này thay đổi theo từng phiên bản. Theo những gì trang đó hiển thị:

Nhóm	Skill
Bắt đầu	/poteto-mode, /setup-pstack, /poteto-help
Xây dựng	/architect, /arena, /swarm, /figure-it-out, /sharpen, /tdd, /blast-radius, /benchmark-checklist
Review và kiểm chứng	/interrogate, /create-verification-skill, /maintain-verification-skill, /no-comments, /correct, /reflect
Viết và cá nhân hóa	/unslop, /technical-writing, /typescript-best-practices, /automate-me, /make-bot-ui
Hiểu và giải thích	/how, /why, /teach, /recall, /ketchup, /bro, /in-your-own-words, /show-me-your-work

Kèm theo là 24 nguyên tắc (prove it works, fix root causes, test behavior, not implementation, subtract before you add…). Cách chia model mặc định, đã được README xác nhận: phần code giao cho Grok (trên trang ghi grok-4.7), còn những thay đổi khó nhất, phần viết lách và phần cần phán đoán thì để cho Claude Opus 5.5.

Dựng một bot kỹ sư, từng bước

Đây là cách thiết lập theo mình hiểu, dựa trên trang pstack và trang giới thiệu Dr Eggbot:

1. Thêm plugin. Trong Grok Bot, thêm pstack qua mục Connect apps. Plugin áp dụng cho cả tài khoản, gõ / là thấy poteto-mode.
2. Cài Dr Eggbot. Đây là bot của Lauren trên Bot Marketplace, chuyên thiết kế các bot khác. Bot viết code thì theo chuẩn poteto-mode: một việc duy nhất, không viết thừa, làm xong phải kiểm chứng. Bot không viết code thì có một việc, một giọng, và một danh sách việc cấm rõ ràng.
3. Lần chạy đầu. Chạy /setup-pstack, rồi /create-verification-skill trên một repo thật.
4. Hai bài khám sức khỏe. Dr Eggbot cài hai routine: thứ Hai, rà xem routine nào đang đốt token vô ích; các ngày trong tuần, đọc lại các cuộc chat gần đây để tìm chỗ hiểu nhầm. Không có gì để đề xuất thì cả hai đều im lặng.
5. Nhờ tạo bot. Kết nối GitHub và Cursor, rồi mô tả người kỹ sư bạn cần. Viết lại theo cách của mình:

Tạo cho mình một bot kỹ sư cho repo này.
Việc duy nhất của nó: điều phối công việc kỹ thuật, không tự viết.
- Giao phần code nặng cho cloud agent của Cursor hoặc một Cursor Project, rồi theo sát.
- Chỉ bật /poteto-mode khi việc cần sự chặt chẽ: bug khó, refactor, vấn đề hiệu năng.
- Trước khi báo xong, phải có bằng chứng: một test fail trên code cũ
  và pass trên code mới, kèm video quay trước/sau.
Việc cấm:
- không tự viết những khối code lớn
- không merge pull request chưa được kiểm chứng
- không deploy
Không có gì đáng báo thì im lặng.

6. Kiểm tra xem bot hiểu chưa. Trước khi để nó chạy, bảo bot giải thích lại công việc của nó bằng lời của nó (skill /in-your-own-words sinh ra để làm việc này). Nếu bản tóm tắt bị lệch, sửa yêu cầu ngay bây giờ, đừng đợi đến PR thứ mười.

Vòng lặp « kiểm chứng trước »

Luật mà pstack áp đặt rất đơn giản: chưa có bằng chứng thì chưa được nói « xong ». Với một bug, bằng chứng là một test fail trên code cũ và pass trên code mới. Test nào pass cả hai lần thì chẳng chứng minh được gì. Với những gì nhìn thấy được, cloud agent của Cursor chạy trên máy ảo riêng, dùng app trong trình duyệt và đính kèm ảnh chụp, video vào pull request, nên agent có thể quay một video trước và sau. Sau đó một người thật xem bằng chứng, chứ không chỉ đọc diff, rồi mới quyết định có merge hay không.

Case study: kiểm chứng hình thức cho hệ thống thông báo

Test chỉ kiểm được những đường đi mà mình đã nghĩ tới. Có những bug nằm ở các thứ tự sự kiện mình không ngờ: hai thiết bị, một chiếc laptop đang ngủ, một tin nhắn đến không đúng lúc. Đó là lúc cần đến /create-formal-verification-skill. Skill này ra bản beta cùng pstack v0.15.27, và Lauren viết rằng việc mô hình hóa code của nhóm bằng TLA+ đã giúp tìm ra vài bug.

TLA+ trong một đoạn. TLA+ là ngôn ngữ do Leslie Lamport tạo ra để mô tả hệ thống, nhất là hệ thống chạy đồng thời và phân tán, bằng toán học đơn giản. Bạn mô tả các trạng thái (số trên badge, đã đọc hay chưa, chế độ Không làm phiền bật hay tắt, laptop đang ngủ hay đang thức), các hành động có thể xảy ra (tin nhắn đến, bạn mở ra, bạn trả lời, laptop thức dậy) và những luật lúc nào cũng phải đúng. Sau đó một trình kiểm tra mô hình (model checker) tên TLC sẽ đi qua mọi trạng thái có thể đạt tới và mọi thứ tự hành động có thể xảy ra, trong giới hạn bạn đặt ra. Khi một luật bị phá, nó đưa ra chuỗi bước ngắn nhất dẫn tới đó.

Ví dụ sử dụng được kể quanh skill này (mình chưa tìm được bài viết gốc, nên bạn đọc các chi tiết như một minh họa) diễn ra thế này. Đầu tiên agent vẽ statechart của hệ thống thông báo: badge, trạng thái chưa đọc, Không làm phiền, đồng bộ giữa laptop và điện thoại. Skill biến nó thành một bộ kiểm chứng TLA+, và trình kiểm tra thử hết mọi cách xen kẽ. Kết quả lộ ra ba trường hợp hiểm hóc:

• trả lời bị tính là đã đọc, dù tin nhắn chưa hề được mở;
• điện thoại vẫn rung khi đang bật Không làm phiền;
• laptop vẫn báo chưa đọc sau khi thức dậy, dù tin đã được đọc trên điện thoại.

Sửa từng bug, rồi cho kiểm tra lại mô hình. Skill còn để lại một skill riêng cho dự án để các agent sau chạy lại bước kiểm tra sau mỗi thay đổi, và /statechart dịch từng chỗ vi phạm ra lời lẽ dễ hiểu.

Điều mình rút ra

• Bắt đầu với một agent. Làm cho việc của nó kiểm chứng được rồi hãy thêm con thứ hai.
• Lỗi nào phải nhắc lại là đang thiếu một luật. Biến nó thành type, lint hay bước kiểm tra trong CI, thay vì thêm một dòng vào prompt.
• Coi kiểm chứng là một sản phẩm. Có skill kiểm chứng, bản đồ tính năng và video ghi lại, bạn được xét duyệt dựa trên bằng chứng thay vì phải đọc từng diff.
• Cho bot một danh sách việc cấm. Việc không được làm cũng quan trọng ngang việc phải làm.
• Dùng phương pháp hình thức ở nơi thứ tự sự kiện là chuyện sống còn. Thông báo, đồng bộ, mọi thứ dính tới hai thiết bị đều là ứng viên tốt, miễn là bạn chạy lại bug trên code thật.

Mình chưa chạy thử pstack trên dự án của mình. Ở bài sau, mình sẽ dựng bot kỹ sư trên một repo thật, thử skill kiểm chứng và, nếu hợp, cả một mô hình TLA+, rồi kể lại xem điều gì đứng vững khi đem ra dùng thật.

Bài tóm tắt độc lập, không liên kết với Cursor hay xAI. Số liệu và trích dẫn lấy từ các nguồn bên dưới.