Lauren Tan nói về trust ladder, môi trường cho agent và ship hàng nghìn PR mỗi tháng

1. Mở đầu: hai tác giả của hai thư viện skill ngồi nói chuyện

Matt Pocock mở buổi live bằng câu "hôm nay mình có thêm một món quà cho mọi người". Lần trước, trong kiểu buổi trò chuyện giống podcast này, anh mời Uncle Bob; hai người nói về chất lượng phần mềm, về agent và nhiều chuyện hay khác. Lần này khách mời là Lauren Tan, người mà Matt giới thiệu là đã "nổ tung" trên Twitter gần đây với những bài viết về software factory, về cách nâng chất lượng công việc, về cách tăng velocity, và về việc leo "trust ladder" (nấc thang niềm tin) với agent để ship ngày càng nhiều hơn. Lauren là tác giả của pstack, một bộ skill dùng cho coding agent. Matt nói tên cô theo cách phát âm nickname trên mạng, rồi chào mừng và cảm ơn cô đã tham gia. Lauren đáp lại rằng cô rất vui được có mặt, và cô là fan của Matt. Matt nói lại đúng như vậy: anh cũng là fan của cô.

Matt kể rằng người ta đang bàn chuyện này như một cuộc gặp của "các bộ óc skill": một kiểu đỉnh Olympus của skill, vì cả hai đều có một thư viện skill rất nổi tiếng. Anh nói thẳng, như đã nói với Lauren trước khi lên sóng, là bản thân anh chưa dùng nhiều skill của cô, và anh muốn "vắt hết nước ép" trong đầu cô để quay lại dùng chúng cho đúng và dùng tốt hơn.

Điểm xuất phát của cuộc trò chuyện là một bài talk Lauren vừa đưa lên X khoảng 10 ngày trước buổi live. Theo lời Matt, bài đó nói về việc cô đã ship 2.500 PR lên production trong một tháng, và bài đăng đạt khoảng 3 triệu lượt xem trên X (theo video, đăng 03/10/2026). Matt đã xem, rất thích và đã giới thiệu bài đó cho người khác. Anh quyết định chạy buổi live này gần như thành một buổi hỏi đáp về chính bài talk ấy, vì anh có rất nhiều câu hỏi muốn đào sâu.

Câu hỏi đầu tiên: trong bài talk có một khái niệm là trust ladder với agent. Càng tin agent hơn, bạn càng có thể giao cho nó những việc khó hơn, hoặc nhân lên nhiều agent hơn. Matt hỏi Lauren câu chuyện của cô: cô đã leo nấc thang đó thế nào, và khi vào SpaceX thì việc leo ngày càng cao diễn ra ra sao.

Cách Matt dựng buổi live cũng đáng ghi lại: anh coi đây là kiểu cuộc nói chuyện "podcasty", nghĩa là không có slide, không có demo, chỉ có hai người nói và trả lời nhau. Vì vậy mọi ý trong trang này đều đến từ lời nói của hai người. Matt nói rõ mục đích của mình là lấy cho được những gì Lauren biết để quay về dùng skill của cô cho đúng, còn Lauren thì mở đầu bằng việc nói cô cũng rất hâm mộ Matt, nên cả hai đều vào cuộc trò chuyện với tâm thế học từ nhau.

2. Hành trình trust ladder: từ dự án phụ noodle đến Agents window của Cursor

Lauren nói hành trình của cô bắt đầu từ trước cả khi cô vào Cursor, hiện là SpaceX AI. Câu chuyện đi từ Meta: cô từng làm ở Meta trong team React, rồi nghỉ một tháng vì kiệt sức (burnt out). Và khi bị kiệt sức thì cô làm đúng điều ai cũng làm: bắt đầu một side project mới. Dĩ nhiên cô dùng AI để viết code.

Nhưng rồi cô nhận ra mình đang mất rất nhiều giờ chỉ để micromanage một agent duy nhất. Lúc đó là khoảng tháng Hai, hoặc đầu tháng Hai hay tháng Giêng. Cộng đồng lúc ấy mê một ý tưởng gọi là orchestration. Đó là thời điểm trước khi những thứ như cửa sổ Agents của Cursor trở nên phổ biến, nên mọi người vẫn còn "ở xứ TUI", tức làm việc trong terminal, và ai cũng bảo nhau "tôi vừa build một orchestrator tùy biến". Cô cũng bị "nerd snipe" bởi chuyện đó: trong lúc làm dự án đồ chơi, cô bị cuốn vào câu hỏi làm sao để bộ setup AI coding của mình hiệu quả hơn.

Lauren nói cô lùi một bước và thấy mình đang dành tất cả thời gian để micromanage một agent. Cô tạo skill, nhưng thấy khá khó để đo output hay tác động của từng skill, nên về cơ bản là "bay mù". Dù vậy cô iterate rất nhanh, và dự án đó cuối cùng trở thành nền tảng của pstack, dù lúc ấy cô không biết. Nhiều mẹo cô học được khi build bộ skill đầu tiên đó vẫn còn dùng đến bây giờ.

Dự án ấy vẫn open source: ai muốn xem thì nó nằm trên GitHub của cô, tên repo là noodle (đánh vần n-o-o-d-l-e). Trong đó có một số skill và một thư mục tên brain. Cô nói thêm rằng lúc ấy cô rất quan tâm đến ý tưởng "làm sao rút ra khả năng của chính mình rồi trao nó cho agent". Vì tất cả những gì cô đang cố làm là dạy agent viết code giống mình hơn, làm workflow giống mình hơn. Skill là một cửa ngõ để làm việc đó.

Sau khi vào Cursor, cô bắt đầu làm việc với cửa sổ Agents (agent's window), và cửa sổ này có nhiều vấn đề hiệu năng: khá giật (laggy). Vì cô có kinh nghiệm làm React, người ta hỏi cô có muốn vào giúp phần Agents window không. Giai đoạn đầu ở Cursor rất thủ công: cô chìm trong flame graph và heap snapshot, cố tìm xem vì sao app chậm đến thế. Rồi cô lại quay về cùng một nhận ra: chính cô là nút cổ chai, cô làm mọi thứ bằng tay, cô là một "meat proxy" (cái ống trung chuyển bằng thịt) giữa agent của mình và Chrome DevTools. Cô thấy rất khó chịu về chuyện đó.

Matt hỏi mốc thời gian lúc đó là tháng nào. Lauren trả lời: cô vào Cursor hồi tháng Ba, nên đây là khoảng đầu tháng Tư. Khi mới vào, cô không có skill nào. Cô đã bỏ bộ skill cá nhân của mình, vì nghĩ chúng sẽ không còn liên quan. Nhưng sau đó, khi làm việc trên Agents window và giờ là GrokBot, cô nhận ra rất nhiều bài học từ thời xây bộ skill đầu tiên vẫn rất đúng, nhất là quanh verification (kiểm chứng) và chuyện làm việc thật nghiêm ngặt. Theo kinh nghiệm của cô, ngay cả các model frontier cũng có xu hướng đi đường tắt, làm cái dễ làm. Cho nên rất nhiều skill cô build xoay quanh một câu hỏi: làm sao để "việc dễ làm" cũng chính là "việc đúng".

Matt nói ý "chắt lọc chuyên môn của mình rồi biến những gì mình làm hằng ngày thành quy trình" nghe rất quen, vì đó chính xác là những gì anh làm với skill của mình. Từ đó anh chuyển sang một câu hỏi "vibe check" trước khi đi tiếp.

Điều Lauren nhấn mạnh trong đoạn này là nhịp độ: cô iterate rất nhanh dù không đo được tác động của skill. Cô cũng nói rõ rằng cô đã bỏ bộ skill cá nhân khi vào Cursor vì tưởng chúng không còn liên quan, rồi mới nhận ra các bài học bên trong chúng vẫn đúng. Hai điều cô giữ lại từ giai đoạn noodle là verification và sự nghiêm ngặt, vì theo cô, agent kể cả loại frontier vẫn hay chọn đường dễ. Cách cô diễn đạt mục tiêu: không chỉ cấm đường tắt, mà làm cho đường dễ nhất trùng với đường đúng nhất.

Matt xác nhận rằng ý "chắt lọc chuyên môn và biến việc mình làm mỗi ngày thành quy trình" chính là việc anh đang làm với skill của mình, nên anh thấy hai người đi cùng một hướng dù xuất phát từ hai nơi khác nhau.

3. Chuyên môn lĩnh vực quan trọng hơn bao giờ hết, và chuyện ngôn ngữ

Matt đặt câu hỏi: nhiều người cho rằng khi dựa nhiều hơn vào AI thì domain expertise (chuyên môn lĩnh vực) ngày càng ít hữu ích. Lauren nghĩ sao? Lauren trả lời rằng cô thấy domain expertise quan trọng hơn bao giờ hết. Cô nhớ mình đã viết điều này trên X. Khi model ngày càng thông minh và có năng lực hơn, khi các model frontier ngày càng giỏi (cô nói thêm là cô rất thích Opus 5.5), thì nút cổ chai không còn là agent nữa. Nút cổ chai trở thành khả năng của bạn trong việc diễn đạt ý định và mục tiêu của mình đủ rõ để agent hiểu và thực hiện được.

Vì thế, theo Lauren, những người có nhiều domain expertise có lợi thế rất lớn, nhất là nếu họ hơi "tò mò về công nghệ" (techno curious). Cô lấy ví dụ một bác sĩ, một luật sư, hay bất kỳ ai có chuyên môn sâu ở một lĩnh vực không phải kỹ thuật phần mềm. Nếu họ chỉ cần biết dùng công nghệ ở mức vừa phải và tìm ra cách dùng agent, họ có thể build ra những sản phẩm rất tuyệt, miễn là trong đầu họ có một tầm nhìn đủ rõ và họ diễn đạt được để agent dựng lên. Cô nói đó mới thực sự là nút cổ chai ngày nay: việc chuyển giao ý định và tầm nhìn của bạn cho agent.

Matt đồng ý và kể rằng từ khi agent xuất hiện, anh bị ám ảnh bởi ngôn ngữ. Anh liên tục nghĩ về cách ghép các từ với nhau, làm sao để câu chữ sắc hơn, có gì ẩn trong những cụm từ anh dùng. Điều anh thích nhất là khi tìm được một từ mà agent "bám vào" rồi nói "được rồi, mình sẽ củng cố từ này", rồi dùng lại từ đó trong các thinking trace của nó. Anh thấy điều ấy rõ với TDD, ví dụ sớm nhất. Dạo này người ta bàn nhiều về chuyện có nên dùng TDD với agent hay không. Matt nói điều đó không quan trọng: việc bạn đang làm là khiến agent nghĩ về TDD, khiến nó viết test, khiến nó ưu tiên mọi thứ theo cách khác với trước đây. Và đó cũng là lý do "grilling" (kỹ thuật bắt agent chất vấn mình) hoạt động hiệu quả: grilling kéo những từ đó ra khỏi bạn, hoặc ít nhất giúp agent hiểu cách bạn nghĩ để nó đề xuất những từ ấy cho bạn, và bạn nhặt lấy và nói "đúng rồi, chính xác là thế".

Lauren nói cô đã copy một số mẹo Matt chia sẻ. Một mẹo cô thích nhất, mới đây thôi, hoặc trong vài tuần qua, là giảm hoặc loại bỏ các tautological test (test lặp vòng, kiểm chứng điều hiển nhiên). Một trong những thứ cô ghét nhất ở agent là vô số test vô dụng chúng viết ra. Từ "tautology" không phải ai cũng biết, nhất là khi tiếng Anh không phải tiếng mẹ đẻ, nhưng từ này mang nhiều nghĩa: nó giống như được nén lại, bạn nén rất nhiều ý định và ý nghĩa vào một từ.

Cô cũng nói mình luôn quan tâm đến ngôn ngữ, cả ngôn ngữ lập trình lẫn ngôn ngữ tự nhiên của con người, và chúng hình thành thế nào. Điều thú vị là giờ với agent, hai thứ gặp nhau: ngôn ngữ tự nhiên gặp ngôn ngữ lập trình, nhưng bên dưới tất cả vẫn là ngôn ngữ, vẫn là giao tiếp. Matt hùa theo: anh học ngành kịch (drama degree), nên đã nghĩ về ngôn ngữ, về Shakespeare và những thứ như thế từ rất lâu, và chuyện này với anh nghe rất quen.

Matt nói trước khi đi tiếp, thứ anh muốn từ Lauren là chuyện software factory. Software factory là buzzword lớn hiện nay, và anh cũng đang nghĩ về nó, thậm chí sắp ra một khóa học theo hướng đó. Đó là việc "nâng bản thân lên" tới những con số PR khó tin, những con số nghe có vẻ vô lý với người không hiểu cách chuyện này vận hành.

Một ý nữa trong đoạn này: Matt nhắc rằng với agent, điều quan trọng không phải là bạn có theo đúng TDD hay không, mà là từ "TDD" đã kéo agent sang một cách nghĩ khác, ưu tiên khác. Còn Lauren dùng ví dụ "tautology" để cho thấy một từ có thể mang theo cả một khái niệm mà bạn không phải giải thích dài dòng. Cả hai đều coi việc chọn từ là một kỹ năng thực sự của người làm việc với agent, không chỉ là chuyện văn phong.

4. Ẩn dụ Michelin kitchen thay cho "software factory"

Matt nói điểm anh muốn đi tới: từ những người đang làm việc với khoảng một đến năm agent hôm nay, lên tới hàng trăm agent chạy cùng lúc, và cách chuyện đó vận hành. Vì thế anh muốn nghe ẩn dụ "Michelin kitchen" của Lauren, dùng thay cho software factory, vì theo anh nó nói lên nhiều điều về cách cô nghĩ.

Lauren nói cô chưa bao giờ thích thuật ngữ software factory. Không phải vì nó không chính xác, mà vì khi nghe "factory" (nhà máy), nhiều người không nghĩ ngay tới việc tạo ra sản phẩm có chất lượng và có sự tinh xảo (craft). Đó là những điều rất quan trọng với cô và với nhiều người làm sản phẩm: họ quan tâm đến trải nghiệm người dùng, quan tâm đến thứ mình đang xây. Nên dù cô nghĩ software factory là thuật ngữ phù hợp, nó cũng gợi lên những liên tưởng đôi khi tiêu cực. Michelin kitchen là cái cô chọn cuối cùng, vì nó mang tính khao khát (aspirational) hơn nhiều.

Cô thích ẩn dụ này vì cô thích đồ ăn, biệt danh của cô là poteto, đọc gần như "potato" (khoai tây), và cô thích nấu ăn, nên thấy nhiều điểm tương đồng. Khi bạn nấu một bữa cho chính mình, nó vừa mang tính thực dụng (bạn chỉ cố nuôi sống bản thân) vừa có thể biến thành nghệ thuật. Đó là điều một đầu bếp sao Michelin, hay chỉ một đầu bếp hay một người nấu ăn, làm được: lấy một thứ rất bình thường và biến thành một bữa ăn ngon đưa bạn về những ngày thơ ấu. Điều này phản chiếu trust ladder cô nói: hãy hình dung hành trình của một người nấu ăn tại gia. Ở nhà, bạn làm hết mọi thứ: bạn cắt rau, bạn sơ chế, bạn dọn dẹp. Bạn là show một người, một ông hoặc một bà.

Lauren đưa ra một thí nghiệm tưởng tượng: bạn đang nấu một bữa, rồi thêm người vào. Bạn đời của bạn vào cùng, rồi anh chị em, và đột nhiên cả gia đình ở trong bếp. Cô cho rằng đa số mọi người sẽ rất căng thẳng: nghĩ đến việc bao nhiêu người đang "lục lọi" trong bếp của mình, họ không biết dụng cụ ở đâu cả. Matt nói thẳng "công suất tối đa của tôi là một người", và Lauren xác nhận "chính xác".

Cô thấy ẩn dụ này rất sát vì nó đặt ra câu hỏi: làm sao đi từ một đầu bếp solo tới có cả một đội, hay thậm chí không cần là cả một đội quân, chỉ cần vài sous chef (bếp phó) giúp trong bếp? Làm sao chia việc sao cho hợp lý, không phải chia chỉ vì muốn chia, mà chia để tổng lớn hơn tổng của các phần. Khi bạn trở thành bếp trưởng, bạn ở vị trí không còn tự nấu mọi món nữa, mà đang suy nghĩ, gần như là tech lead của nhà bếp. Đầu bếp phải nghĩ không chỉ về nấu ăn mà về việc tổ chức cả căn bếp. Họ giống CEO của nhà bếp: khi nào đặt nguyên liệu, bảo quản thế nào, chuẩn bị thế nào, chuẩn bị khi nào. Đó là cả một công việc, không chỉ là nấu.

Cô nói điều này phản chiếu cách kỹ sư viết code hôm nay: bạn không còn tự viết code nữa, bạn có agent. Nhưng với tư cách con người, bạn vẫn chịu trách nhiệm về kết quả cuối cùng: tên bạn vẫn gắn với công việc bạn làm, và uy tín của bạn cũng vậy. Vì thế cách bạn dựng bếp của mình, cách bạn dựng skill, môi trường và codebase, rốt cuộc là những nguyên liệu mới đi vào việc làm ra sản phẩm.

Lauren dùng ẩn dụ này để trả lời một câu hỏi cụ thể của Matt về việc đi từ vài agent lên hàng trăm agent. Câu trả lời của cô không bắt đầu từ công cụ mà từ cách chia việc: không chia chỉ vì có thể chia, mà chia sao cho đội làm ra nhiều hơn tổng sức của từng người. Cô cũng nhắc rằng người đứng bếp vẫn là người chịu trách nhiệm về món ăn cuối cùng, giống kỹ sư vẫn chịu trách nhiệm về code do agent viết, và vì thế cách dựng skill, môi trường và codebase mới là "nguyên liệu" thật sự của sản phẩm.

5. Verification: kỹ năng quan trọng nhất, cho agent "đôi tay và đôi mắt"

Matt tóm lại điều anh thích ở cách tiếp cận của Lauren: cô dồn rất nhiều sự chú ý vào môi trường (environment) mà agent vận hành trong đó. Theo anh, nhiều người nghĩ agent đã tốt rồi, mình khó mà làm nó tốt hơn, cứ tin vào những gì các "người làm model" đã đặt vào tổ hợp harness và model. Họ nghĩ mình không thể làm gì nhiều, không thể táy máy vào phần bên trong của Claude Code hay công cụ nào đang dùng. Nhưng điều anh yêu ở cách tiếp cận của cô, và cũng là điều anh ủng hộ, là bạn có thể thay đổi môi trường agent hoạt động: thay đổi trong codebase, và đưa cho nó công cụ để tự kiểm chứng công việc của chính nó.

Điều anh thích nhất khi xem bài talk là lượng sự chú ý Lauren dành cho verification, và anh nói đó chính là đòn bẩy để bắt đầu tạo ra niềm tin. Anh nhờ cô nói về việc đó và nó trông cụ thể ra sao, bắt đầu từ những cách thực tế người ta có thể cải thiện quy trình, tức "căn bếp" của chính họ.

Lauren nói cô đã nhắc điều này rất nhiều lần: kể cả khi bạn không dùng pstack hay skill của cô, kỹ năng quan trọng nhất cần có trong bộ công cụ của bạn là verification. Cô giải thích cho người xem chưa biết nghĩa là gì: đó là ý tưởng rằng bạn có thể cho agent "đôi tay và đôi mắt", đó là ví von cô thích. Agent có thể chạy code và tương tác với nó như một người dùng bình thường, đồng thời có thể debug, lấy trace và snapshot.

Cô kể rằng đó cũng chính là skill đầu tiên cô build khi vào Cursor. Skill đó bắt đầu giúp cô leo được thêm một chút trên trust ladder, theo cách mà những skill khác cô từng xem hay từng build chưa làm được. Vì dù các skill khác tốt tới đâu (cô kể tên skill "how", skill "why" và skill "unslop"), cô vẫn phải đóng vai proxy giữa agent và output. Nếu agent không nhìn thấy được kết quả công việc của chính nó, nó không có cách nào lặp lại và cải thiện (iterate).

Từ đây Lauren nói về loop: người ta nói nhiều về ý tưởng này, nhưng từ "loop" nghe khá trừu tượng; người ta hỏi vòng lặp là gì, agent loop là gì. Với cô, phần quan trọng nhất khiến nó thành một vòng lặp chính là phần verification, vì agent tự kiểm chứng được công việc của nó, và việc đó đưa bạn ra khỏi phương trình.

Một trong những use case đầu tiên của cô với verification là công việc hiệu năng cô làm cho Agents window của Cursor. Cô muốn đạt tới điểm có thể làm "hill climbing", một thuật ngữ cô nghĩ các lab nói rất nhiều: bạn có một rubric hay một cách để đánh giá hoặc chấm điểm thứ gì đó, và vì có loop, bạn để agent liên tục cố cải thiện nó. Cô nhắc tới việc Andrej Karpathy cũng nổi tiếng với việc phát hành một thứ gọi là auto research chứa nhiều ý tưởng như vậy. Nhưng cô nói verification có lẽ là skill quan trọng nhất trong pstack và trong nhiều bộ công cụ khác, và là điều quan trọng nhất cần tập trung vào. Cô đã dành rất nhiều thời gian tinh chỉnh skill verification (trong pstack đó là create-verification-skill, skill tạo ra skill verification cho từng app). Bên trong công ty họ giờ có rất nhiều skill verification: mọi app của Cursor hay của SpaceX AI đều có một skill verification được tự bảo trì. Nó đã thành hạ tầng thiết yếu của team vì ai cũng dùng.

Matt lặp lại ý chính của phần này bằng lời của anh: verification là đòn bẩy để bắt đầu tạo niềm tin vào agent. Lauren thì đưa ra cách nhớ đơn giản nhất: cho agent đôi tay và đôi mắt để nó chạm vào chương trình như một người dùng và nhìn thấy kết quả. Cô cũng kể rằng bên trong công ty, skill verification của mỗi app được tự bảo trì, nên không ai phải cập nhật bằng tay mỗi khi app đổi.

6. CLI trong skill: tách phần deterministic khỏi phần cần judgment

Matt nhận xét rằng Lauren đã đi khá xa với việc đó, vì trong bài talk anh thấy cô còn build một CLI tùy biến cho verification. Anh hỏi CLI đó làm gì, chạy các thứ thế nào, và vì sao cô làm vậy, vì đó là bằng chứng cho thấy cô đã đi sâu và đẩy chuyện này tới đâu.

Lauren nói đây là một mẹo cô học được từ sớm. Hồi tháng Một hoặc cuối năm trước, điều mọi người lo nhất là context window, chủ đề lớn lúc đó là làm sao quản lý context window, vì compaction (nén ngữ cảnh) và tóm tắt chưa tốt. Cộng đồng thậm chí có một meme: một khi agent đã tóm tắt hoặc compact một lần, nó sẽ trở nên "ngu" trong phần còn lại của phiên. Vì thế người ta suy nghĩ rất nhiều về việc dùng context thật tiết kiệm, và đó là nguồn cảm hứng cho một phần công việc CLI nằm trong các skill verification. Cô nói giờ thì điều đó bớt quan trọng hơn vì agent hay harness đã giỏi hơn nhiều ở việc tóm tắt, nhưng vẫn có lợi ích khi giữ context window sạch.

Vậy CLI thực chất là cách để cô lấy các phần deterministic của việc skill làm, mã hóa vào một script hay một CLI, để bỏ đi phần judgment mà nếu không sẽ bị dùng một cách không cần thiết. Cô nghĩ về agent và skill như một dải gradient: có những phần việc hoàn toàn dựa vào judgment, cần suy nghĩ, ghép nhiều mảnh ngữ cảnh lại và nghĩ; và có những phần deterministic. Ví dụ nếu muốn refactor code từ pattern này sang pattern kia thì rất cơ học: không cần agent nghĩ ra theo cách mới mỗi lần. Đó là cảm hứng cho CLI, và cô nói bạn sẽ thấy điều này trong nhiều skill khác của cô: cô cố rút phần deterministic ra, biến thành code, và chỉ để lại cho agent những phần thực sự cần judgment.

Vì vậy cô nghĩ skill giống một lớp "wrapper" kèm vài chỉ dẫn nhẹ về cách dùng các công cụ tùy biến nằm bên trong. Cô không thấy bản thân skill đó thú vị lắm, nó không phải một phần mềm mới lạ, chỉ là thứ tương tác với Playwright và Chrome DevTools Protocol và gọi một loạt API, "chỉ là một đống keo dán" (glue).

Matt nói điều đó hấp dẫn vì đó là cách giấu thông tin khỏi skill: giữ cho skill khá nhỏ, và đẩy phần deterministic phức tạp vào một script bên trong skill. Anh mô tả đó là nén thông tin và khiến agent làm những việc nhất quán hơn, một cách nhất quán hơn. Lauren bổ sung rằng nó cũng giúp nếu bạn quan tâm đến context window, vì agent không cần "phát minh lại" mọi thứ. Cô nhớ lúc đầu khi chưa có CLI, agent cố verify công việc của nó nhưng về cơ bản là "dựng lại cả thế giới" mỗi lần, và mỗi agent làm một kiểu. Cô thấy điều đó rất kém hiệu quả: không chỉ về context mà về cả tốc độ, vì giờ agent phải đi viết script hoặc CLI, rồi thử, rồi nó không chạy; agent trước làm được rồi nhưng đã vứt đi. Nên đến lúc đó rất rõ là cô nên biến nó thành CLI và đặt vào trong skill, để mọi agent dùng skill đều hưởng cùng một phần đó.

Cô cũng thấy đây là điều đáng để mọi người nghĩ: bao nhiêu phần trong skill và rule của bạn thực ra có thể là deterministic. Đó là một trong những nguyên tắc cốt lõi của cô: làm sao dùng determinism và non-determinism thật hiệu quả, để agent tỏa sáng ở các phần non-deterministic, vì đó là thứ chúng được huấn luyện để làm, còn phần cơ học hoặc đơn giản hơn thì để thuần determinism.

Cô lấy ví dụ migration, một chủ đề lớn khác cô từng nói: chuyển từ công nghệ này sang công nghệ khác, nhất là sang công nghệ tốt hơn cho agent. Phần lớn cách làm migration đó, theo cô, là qua script và CLI cho các phần deterministic, như code mod: duyệt AST (abstract syntax tree) và biến đổi code một cách hoàn toàn cơ học, để script làm thay agent.

Matt nói điều đó hợp lý, và còn một ý nữa: bạn lấy bớt thứ khỏi agent và đặt nó vào môi trường. Giả sử có thứ agent luôn làm sai, bạn muốn khiến nó đơn giản là không thể xảy ra trong môi trường. Chuyện này dẫn tới chất lượng code. Anh nói nhiều về một codebase tốt nghĩa là gì, và định nghĩa anh thích là: codebase tốt là codebase dễ thay đổi, dễ sửa mà không làm hỏng thứ khác. Điều đó có nghĩa là có nhiều guardrail, và agent hay con người bị giới hạn vào những lối rất hẹp. Anh nhắc rằng Lauren cũng nói điều này trong bài talk, không chỉ ở phía kiểm tra tự động như linting và type checking mà còn ở cách thiết kế abstraction, và đội cô thậm chí đã build cả một framework cho agent làm việc trong đó. Anh hỏi tầm quan trọng của việc đó so với những việc khác như build feature hay ship công việc.

Điểm đáng giữ lại ở đoạn này là cách Lauren phân loại việc cho agent: một dải liên tục từ phần cần suy nghĩ (judgment) tới phần cơ học (deterministic). Phần cơ học viết thành code thì mọi agent dùng chung, nhất quán và nhanh hơn; phần cần suy nghĩ để lại cho agent vì đó là chỗ chúng được huấn luyện để làm tốt. Cô đưa hai ví dụ: CLI cho verification và code mod cho migration. Matt thì tóm lại từ góc nhìn của anh: lấy bớt việc khỏi agent và đặt vào môi trường, để thứ agent hay làm sai trở thành thứ không thể làm sai.

7. Việc mới của kỹ sư là dành thời gian cho môi trường: mài dao trước khi nấu

Lauren trả lời rằng cô gần như thấy công việc mới của kỹ sư thực sự là dành thời gian cho môi trường. Cô suýt viết một tweet về chuyện này hôm trước nhưng rồi không viết. Cô nói nếu bạn chưa thực sự dành thời gian xây dựng niềm tin vào agent, xây skill và công cụ, bạn có thể bị kẹt trong một chế độ mà bạn nằm rất thấp trên trust ladder. Bạn không tin nhiều vào công việc của agent, và cách duy nhất để đối phó trong tình huống đó là "khóa chặt" và micromanage các agent. Việc đó rất tốn thời gian, và khi bị kẹt ở chế độ đó, bạn không còn xa xỉ để nghĩ tới những việc cao hơn như làm cho bản thân năng suất hơn.

Cô dùng một phép so sánh: nếu bạn chưa bao giờ dành thời gian học công cụ của mình khi viết code bằng tay, chưa từng nghe tới VS Code, chưa từng nghe tới Vim, chỉ biết Notepad và thậm chí chưa nghe tới Git, thì đó là điều tương tự. Bạn chưa dành thời gian mài dao của chính mình. Và nếu bạn có con dao cùn, mọi thứ sẽ mất rất lâu, nhất là khi deadline đang đến gần, thì bạn không có cơ hội thoát ra. Bạn bị kẹt trong cái rãnh đó: không có dao sắc, không có công cụ tốt, nhưng lại chịu mọi áp lực phải ship, nên tất cả những gì bạn làm được là cắm đầu vào làm.

Nhưng cô nói nếu bạn tìm được thời gian để nghĩ về setup của mình, thì quay lại phép ví von nấu ăn: nếu việc cắt tỏi rất chậm thì có dụng cụ nghiền tỏi, bạn mua về, bỏ vào rồi bóp ra, nhanh hơn nhiều. Máy móc và công cụ được phát minh có lý do. Nếu bạn điều hành một Michelin kitchen mà các đầu bếp không có công cụ nào, mọi thứ chắc chắn cực kỳ kém hiệu quả: mỗi đầu bếp sẽ tự nghĩ ra một kiểu riêng. Cô kết luận rằng công cụ và tính deterministic với cô chính là thứ lấy đi phần đó.

Matt đặt câu hỏi này ngay sau khi nói về guardrail và framework nội bộ: anh muốn biết việc đầu tư cho môi trường quan trọng thế nào so với việc build feature hay ship công việc. Câu trả lời của Lauren là một lập luận về thứ tự: nếu bạn chưa đầu tư cho công cụ thì bạn luôn ở trong chế độ khẩn cấp, và chế độ khẩn cấp chính là thứ ngăn bạn đầu tư. Vì vậy cô coi việc dành thời gian cho môi trường như công việc chính của kỹ sư ngày nay, không phải việc phụ làm khi rảnh.

8. Type narrowing, Dune và các lint rule: làm cho việc viết code xấu trở nên khó

Cô nói thêm một đoạn lạc đề liên quan tới ràng buộc (constraints), và nói rằng hai người nên bàn về TypeScript, vì cả hai có chung nền tảng TypeScript. Matt đã làm rất nhiều với TypeScript và Total TypeScript, và là người dẫn đầu mảng đó. Lauren dùng TypeScript từ khá sớm, và đã có một hai bài nói tại TypeScript Conf nhiều năm trước. Một trong những bài của cô là về type system và việc ràng buộc kiểu (constraining types).

Một trong những điều cô thích nhất ở TypeScript là type narrowing: bạn đi từ một kiểu rất rộng, có thể là bất cứ gì, rồi qua type guard, type narrowing và các kiểm tra lúc runtime, bạn thu hẹp không gian lại và nói "cái này không chỉ là một string, nó là một loại string rất đặc biệt, một hằng số", và bạn xác định điều đó qua type system. Cô thấy có nhiều điểm tương đồng với ràng buộc trong codebase: bạn đang thu hẹp không gian. Nếu nghĩ theo category theory, bạn đang giới hạn số kiểu có thể tồn tại và nói rằng chỉ có một kiểu.

Với team của cô, framework cô đang build tên là Dune. Đó không phải framework open source. Cô mô tả cho mọi người là "Next.js nội bộ của chúng tôi cho các app Electron". Nó đi kèm rất nhiều lint rule rất chặt, và codebase được thiết kế sao cho thực sự chỉ có một cách để làm một việc. Họ dùng nhiều pattern theo quy ước: tính năng nào cũng nằm trong một thư mục chỉ định, mỗi feature có thư mục riêng; có một thứ phát hiện feature thông qua một registry và quét codebase, v.v. Quy ước đó cùng các lint rule tạo ra một môi trường mà thực sự rất khó viết code xấu. Nó vừa giải phóng năng lực tâm trí của chính cô vừa giúp agent không phải nghĩ về chuyện đó nữa. Nếu muốn thêm feature mới thì nó chỉ việc đi vào thư mục feature mới, mọi code nằm trong đó, và agent sẽ không nối thêm vào một "God file".

Cô kể đó thực ra là cảm hứng cho các thư mục feature: vài phiên bản đầu của GrokBot được cấu tạo từ khoảng tám God file, mỗi file ít nhất 10.000 dòng, nếu không muốn nói là dài hơn. Cô buộc phải chia nhỏ ra. Nhưng việc quan trọng khác là quan sát cách agent thất bại: mỗi khi bạn thấy một lỗi, hay thấy điều gì đó có thể làm tốt hơn, bạn lùi lại và nghĩ "làm sao biến chuyện này thành một lint rule", "làm sao để codebase khiến điều này không thể xảy ra". Cô nói chuyện đó quay về nền tảng cô học TypeScript và type system: làm sao thu hẹp không gian để biết chính xác mình đang làm việc với cái gì. Có nhiều điểm tương đồng ở đó.

Matt cười và nói thật buồn cười khi cô nhắc TypeScript và God file trong cùng một câu, vì TypeScript nổi tiếng là có một file kiểu dài 25.000 dòng. Lauren nói cô biết điều trớ trêu đó; không biết họ đã viết lại nó trong Go chưa, và rồi bổ sung "chắc là chưa".

Matt tóm lại phần này: môi trường quan trọng. Bạn nên nhìn agent như diều hâu để đảm bảo mọi lỗi nó mắc đều được bạn biến thành thứ nằm trong môi trường. Lợi ích của môi trường là bạn không làm quá tải agent với quá nhiều rule, quá nhiều thứ phải nhớ: mọi thứ nằm trong môi trường nên agent tự "vấp" vào các luật, bật ra và chạm đúng chúng vào đúng thời điểm.

Phần này cho thấy hai người có cùng nền tảng TypeScript và dùng nó làm ngôn ngữ chung để nói về ràng buộc. Với Lauren, mỗi lỗi của agent là một cơ hội viết thêm một lint rule hoặc một quy ước, để lần sau agent không thể mắc lại. Với Matt, điều đó có nghĩa là bạn không nhồi vào agent hàng đống luật cần nhớ: luật nằm trong môi trường, agent chạm vào chúng đúng lúc cần.

9. 2.500 PR đến từ đâu: inner loop, outer loop và nhà hàng chuỗi

Matt nói họ vẫn chưa nói tới 2.500 PR. Nguồn của chúng là gì? Cô đã xây trust ladder, làm việc với môi trường và hiểu rằng giờ cô muốn scale lên. Vậy cơ chế của việc scale là gì? Chẳng lẽ cô khởi tạo 2.500 chat mỗi tháng, điều đó nghe không đúng. Chắc phải có trigger tự động nào đó kích hoạt công việc trong repo, vậy làm sao software factory tự kích hoạt công việc?

Lauren trả lời rằng điều kiện tiên quyết cho một lượng PR rất lớn là môi trường, những thứ vừa nói: cô chắc chắn sẽ không làm được nếu không dành thời gian nghĩ về căn bếp, những con dao và công cụ cho agent. Cô nghĩ về điều này như thế này: cô đã bỏ thời gian xây một căn bếp và một nhà hàng, và giờ cô ở vị trí không cần phải có mặt ở đó nữa vì môi trường đã làm việc. Matt nói ẩn dụ này hợp: "bạn đã mở một chuỗi nhà hàng". Lauren đồng ý và nói tiếp hình ảnh đó: giống như bạn là Gordon Ramsay, đã dạy cho bếp trưởng điều hành mọi mánh để nghĩ ra một thực đơn tuyệt vời; căn bếp được sắp đặt hoàn hảo và giờ bạn có thể mở nhà hàng thứ hai, thứ ba. Cô coi mỗi dự án mình làm, mỗi chat lớn, như một nhà hàng, và cô có nhiều nhà hàng hoạt động cùng lúc, "bay trực thăng" qua lại giữa chúng, nhiều hơn hay ít hơn tùy mức độ cô ở trong vòng lặp.

Cô nói chắc chắn có những trigger và ngữ cảnh bên ngoài mà các dự án đó không có, và trong một thời gian dài cô là proxy cho chuyện đó. Ví dụ rõ nhất: bạn có một dự án đang làm một feature, hay đang sửa một bug, và bạn nhận bug report, nhưng bug report đi tới Slack, Linear hay X. Đó là những hệ thống bên ngoài không nối với inner loop của bạn. Cô thích nói về outer loop (vòng ngoài) và inner loop (vòng trong); cô không chắc mình dùng định nghĩa đúng, nhưng với cô inner loop là các kỹ sư agent của cô làm việc trên code để xây dựng hướng tới một ý định, hay một bản chụp (snapshot) ý định của cô.

Cô nói vấn đề là bản chụp ý định đó có thể bị cũ (stale): thông tin mới xuất hiện và cô phải làm proxy chuyển ngữ cảnh đó cho agent. Nếu bạn không có các trigger kéo thông tin trở lại inner loop, bạn phải đóng vai đó: chạy qua Slack, X hay đâu đó, thu thập ngữ cảnh về bug report, về yêu cầu feature, về điều ai đó nói về giới hạn của hạ tầng backend, rồi phải "chở" tất cả sang cho agent. Đó là chỗ các công cụ như GrokBot rất tốt, vì chúng giúp tự động hóa cả outer loop. Khi nối hai vòng lại, nó rất mạnh vì đột nhiên agent của bạn có khả năng tự lấy ngữ cảnh cho mình.

Ví dụ đơn giản: bạn có Slack MCP, hoặc harness riêng của bạn có sẵn một subscription vào một kênh Slack nhất định. Giờ bạn có thể bảo agent: "hãy subscribe kênh Slack đó, mỗi khi có báo cáo bug về một thứ gì, hãy đi triage nó, tái hiện vấn đề", dùng các skill verification đã dành thời gian build, cùng mọi skill khác đã dựng, để cô tin rằng agent thực sự có thể hiểu bug, và xác minh bug vẫn còn trên main. Việc đó cũng phân biệt được trường hợp lỗi nằm ở thiết lập hay dữ liệu của người dùng, chẳng hạn họ không cài một dependency. Cô nói tạo ra hai vòng lặp và nối chúng lại là phần rất quan trọng của công việc hiện nay, đặc biệt nếu bạn nghĩ về chuyện scale bản thân.

Một chủ đề lớn ở đây là liên tục hỏi "tôi đang là nút cổ chai ở đâu trong quy trình này?" và "vì sao các agent của mình cần tôi để trả lời câu hỏi này?". Cô luôn thích nghĩ như vậy, và cố làm sao để agent tự trả lời câu hỏi của nó, không phải bằng cách bịa hay đoán mà bằng dữ liệu thật. Cô nói nhiều người bàn về "company brain" hay "context graph", nhưng cô cảm thấy những thuật ngữ đó phức tạp hay trừu tượng một cách không cần thiết. Với cô chỉ là: lấy thông tin agent cần mà nếu không bạn phải đi lấy rồi đưa cho nó, và dạy nó cách tự làm. Việc đó đưa bạn ra khỏi phương trình. Vì vậy cô tới được con số 2.000 hay bao nhiêu PR là nhờ có tất cả các vòng lặp đã dựng, và nó cho phép cô mở chuỗi nhà hàng, tự "song song hóa" bản thân. Cô nói rõ cô không ngồi tạo 2.500 chat.

Tóm lại cách Lauren trả lời câu hỏi về 2.500 PR: không phải 2.500 chat khởi tạo bằng tay, mà là môi trường tốt, nhiều "nhà hàng" cùng chạy, hai vòng lặp nối với nhau, và một mục tiêu đi ngược từ cuối là để agent tự merge được code của nó. Cô cũng gọi tên câu hỏi mà cô tự hỏi mình mỗi ngày: tôi đang là nút cổ chai ở đâu, và vì sao agent cần tôi để trả lời câu này. Con số 2.500 là con số Matt nêu từ bài talk, theo video đăng ngày 03/10/2026; trong lúc nói, chính Lauren dùng cách nói "2.000 hay bao nhiêu PR".

10. Cursor Projects, GrokBot và các coordinator agent làm "chief of staff"

Lauren giải thích thêm: Cursor có một tính năng mới tên là Projects, đó là những coordinator agent (agent điều phối). Coordinator agent rất giỏi trong việc phân việc và không tự làm việc: chúng quản lý và giám sát một danh sách tác vụ và các phản hồi của agent đi làm. Vì vậy cô liên tục "nạp" ngữ cảnh, hoặc dạy các agent cách tự lấy ngữ cảnh, rồi chúng đi làm việc thay cô.

Điều cuối cùng cô nói về chủ đề này: "mở khóa" lớn nhất để đạt tới 2.000 PR là bắt đầu từ câu hỏi rồi đi ngược lại, "làm sao để tới được điểm mà agent của tôi có thể tự merge code của nó". Điều hiển nhiên mà người ta hỏi, khi cô kể đã ship 2.500 pull request tháng trước, là "bạn review kiểu gì", vì đó là rất nhiều PR phải review, và "team của bạn chắc ghét bạn lắm". Matt xin phép đi tới câu hỏi đó sau một lát, vì đó là câu hỏi hay. Trước hết anh muốn đào sâu ẩn dụ này: trước đây nếu bạn tự tay khởi tạo từng chat thì giống như bạn tự mang từng đơn hàng tới các đầu bếp. Còn nếu có một agent làm vai "expo" (người điều phối đưa món ra) thì bạn không cần tự chạy. Anh hỏi cụ thể trông thế nào: có các GrokBot đăng ký theo dõi kênh, kéo tin nhắn Slack về, còn cô nghe có vài coordinator agent hay chief of staff agent giám sát chuyện đó; khi nhìn vào máy tính để quản lý agent, cô thấy gì.

Lauren nói đây có hơi khó hiểu, nhưng họ đang làm việc để đơn giản hóa và thống nhất nó. Có GrokBot, hoặc dĩ nhiên bạn có thể dùng công cụ khác, nhưng cô chủ yếu nghĩ các công cụ này là outer loop. Đó là các công cụ như GrokBot có connector, nhiều người gọi là personal agent, kết nối tới email, lịch, Slack, Plaid và nhiều dịch vụ khác. Chúng là nguồn tuyệt vời để kéo ngữ cảnh vào công việc.

Cô so sánh với một người quản lý dẫn một team kỹ sư. Hồi cô làm ở Netflix, một trong những điều các manager nói nhiều nhất là "context, not control" (cung cấp ngữ cảnh, không điều khiển), và điều này, cô nói, có rất nhiều điểm giao với thế giới agent. Bạn có thể dẫn tới kết quả mình muốn bằng cách kiểm soát (micromanage), nhưng điều bạn thực sự muốn là cung cấp ngữ cảnh: dạy agent, dạy kỹ sư của bạn cách tự lập, và rồi bạn không cần micromanage. Cụ thể, cô có vài GrokBot theo dõi các kênh Slack, X, email hay Linear của cô, và chúng có các routine đăng ký nên luôn quan sát. Cô bảo chúng ví dụ "hãy để ý các vấn đề bug ở ứng dụng desktop GrokBot, và khi thấy thì gửi sang project Cursor của tôi". GrokBot có một điểm hay là nó kết nối được với Cursor.

Cô giải thích Projects: một project cho bạn một coordinator agent ở trên cloud, có máy tính riêng, và việc duy nhất nó làm là quản lý các agent. Nó giống bếp trưởng điều hành, chief of staff của bạn. Nó không tự làm việc: nó giao việc, điều phối và quản lý công việc của các sub-agent báo cáo cho "chief of staff", và nó chịu trách nhiệm thúc đẩy công việc và chuyển ngữ cảnh. Matt hỏi ví dụ: nếu đột nhiên có một đợt 30 issue cùng lúc, trong một payload hay rất nhanh, thì coordinator agent có thể tự tìm ra cách và giao việc? Lauren trả lời đúng vậy: nó nhận khoảng 30 payload và spawn một sub-agent hoặc một coordinator agent. Nó có thể dùng nhiều topology khác nhau của agent và tự tìm cách phân phối tác vụ hiệu quả nhất cho "đội agent" của cô.

Cô dùng Cursor Projects rất nhiều và cũng dùng GrokBot rất nhiều: Cursor Projects là inner loop của cô, còn GrokBot là outer loop. GrokBot lấy mọi ngữ cảnh bên ngoài đưa cho các project vì nó có thể gửi tin nhắn tới chúng. Bạn không cần mở Cursor, chỉ cần nói với GrokBot "hãy tạo một project cho chuỗi tác vụ này vì chúng liên quan nhau". Ví dụ có một loạt issue đều nói về hiệu năng: app chậm, và tất cả liên quan tới nhau, thậm chí vài cái có cách sửa giống nhau.

Cô giải thích vì sao không nên chỉ spawn mỗi agent cho một tác vụ: bạn có thể làm vậy, nhưng khi đó bạn mất sợi dây liên kết giữa chúng. Bạn có thể bị lặp việc, hoặc không nghĩ tới vấn đề ở mức cao hơn. Đôi khi khi sửa bug, có nhiều báo cáo hơi khác nhau giúp bạn "zoom out" và thấy rõ: khi nhìn một báo cáo cô tưởng bug ở chỗ này, nhưng khi thấy nhiều báo cáo khác thì hóa ra nó nằm ở chỗ trên kia. Matt tóm lại: đó là lý do có nhiều agent trong vòng lặp. Nếu một bug report đến và bạn spawn một agent đơn lẻ, agent đó có thể làm trùng với các agent khác, vì nhiều bug report có thể đến từ cùng một nguyên nhân. Anh nói điều đó rất thú vị và kết luận rằng chuỗi trigger bất tận từ người dùng thật báo lỗi thật giúp gia tốc nhà máy, "thêm đơn hàng vào".

Điều cần giữ ở phần này là sự phân vai: GrokBot là outer loop, có connector tới email, lịch, Slack và các dịch vụ khác; Cursor Projects là inner loop, với coordinator agent chạy trên cloud và có máy riêng. Lauren cũng nói họ đang làm việc để đơn giản hóa và thống nhất hai thứ này, vì hiện tại cách dùng còn hơi khó hiểu. Nguyên tắc nền là "context, not control", nghĩa là cho agent ngữ cảnh để nó tự lập, thay vì kiểm soát từng bước.

11. Gardening, buffer và chief of staff nhìn thấy cả khu rừng

Matt hỏi: ngoài bug report, còn nguồn nào khác dùng để tăng tốc và đẩy các PR không? Lauren cười và nói thật ra một phần đến từ việc đọc code. Cô làm rõ: 2.500 PR rõ ràng không phải 2.500 feature. Rất nhiều công việc là gardening (làm vườn, chăm sóc codebase), một thuật ngữ cô rất thích. Điều đó quan trọng hơn khi bạn có một team lớn các kỹ sư là con người, và nó cũng quay về chuyện môi trường: thiết lập môi trường thật tốt không chỉ giúp bạn và agent của bạn mà giúp cả mọi người trong team. Cô bảo hãy nghĩ tới một người mới vào, chưa có nhiều ngữ cảnh về các thông lệ kỹ thuật của bạn. Nếu môi trường tốt thì họ có thể làm việc hiệu quả từ ngày đầu, không phải mở một loạt PR chất lượng thấp, mà có thể bắt đầu tạo ra code thật tốt. Rồi cô nói mình "hơi lạc mạch".

Matt dẫn cô quay lại bằng câu hỏi về cơ chế kích hoạt: khi nào bạn kích hoạt một agent đi nhìn vào code? Có người sẽ nói cứ làm mỗi giờ hay theo cron job. Lauren nói cô đã thấy vài tweet gần đây của Matt về việc thiết lập routine, rất hay, và cô cũng có vài routine như vậy. Một ví dụ đơn giản: React có rất nhiều "foot gun" (cái bẫy tự bắn vào chân) như Matt chắc biết. Cô có một agent liên tục đi tìm các pattern xấu. Điều thú vị là cô không bảo nó sửa ngay. Cô bảo nó ghi nối vào một tài liệu, và cứ vài ngày cô xem lại rồi nói "thực ra những cái này đều là cùng một thứ".

Cô nói như vậy bạn gần như muốn có một buffer hay một hàng đợi: đôi khi cách này hiệu quả hơn nhiều so với spawn ngay hàng loạt sub-agent để sửa từng thứ. Khi bạn ở chế độ thuần thực thi và chỉ cố thực hiện các "đơn hàng" đến rất nhanh, bạn đôi khi bỏ lỡ bức tranh lớn. Có một buffer buộc bạn nghĩ về bức tranh lớn vì bạn có các artifact để nhìn như con người, và dùng phán đoán của chính mình, hoặc dùng cả agent, để nhận ra các pattern mà bạn có thể bỏ sót nếu chỉ giải từng bug một. Cô nói đó cũng chính là lợi ích của một chief of staff agent: nó thấy được cả khu rừng, ngoài việc làm phần thực thi.

Matt nói "đầu óc tôi hơi nổ tung" với ý tưởng chief of staff trong software factory, và anh có thể phải đổi một phần khóa học anh sẽ quay vào tuần sau. Rồi anh chuyển sang chủ đề review.

Ý chính của phần này là lý do Lauren không cho agent sửa ngay mọi thứ nó tìm thấy: một hàng đợi dạng tài liệu giúp cả người lẫn agent nhìn ra mẫu chung của nhiều lỗi nhỏ, điều mà chế độ thuần thực thi dễ bỏ lỡ. Cô nối nó với gardening, tức công việc chăm codebase, vốn chiếm một phần lớn trong số PR. Matt nhận xét rằng ý tưởng về chief of staff trong software factory khiến anh phải nghĩ lại một phần khóa học anh sắp quay.

12. Review thế nào: lấy mẫu thay vì nếm từng món, và "dark factory"

Matt nêu câu phản bác người ta hay đưa ra: "bạn có đọc, có nếm cả 2.500 món ăn đó khi chúng lướt qua không?". Anh đoán câu trả lời là một biến thể của "không".

Lauren nói đúng: bạn không muốn ở vị trí không bao giờ nếm món ăn của mình nữa, nhưng để scale thì bạn cũng không thể nếm từng món ra khỏi bếp, nhất là khi có nhiều nhà hàng. Nên nó trở thành chuyện lấy mẫu (sampling) và nghĩ về quy trình. Có lẽ đây là chỗ ẩn dụ nhà máy hợp hơn: là một người giám sát chất lượng trong nhà máy, bạn không thể nhìn từng sản phẩm, bạn lấy mẫu. Mỗi ngày bạn vào xem chất lượng các pull request, xem code agent viết, và soi thật nghiêm ngặt, nghĩ về mọi sự kém hiệu quả và các pattern xấu agent đang tạo ra. Rồi bạn nghĩ về cách chỉnh môi trường, chứ không phải chỉnh một agent đơn lẻ. Nếu đó chỉ là sự cố một lần thì có lẽ không có gì phải sửa. Nhưng nếu bạn thấy nhiều agent mắc cùng một vấn đề, cùng đi đường tắt, cùng lan truyền một cách lách giống nhau, đó là dấu hiệu bạn nên nghĩ cách sửa căn bếp hay nhà máy: nghĩ về skill, ràng buộc, lint, type system, và chỉnh để vấn đề đó không xảy ra nữa.

Cô nói khi làm vậy đủ nhiều lần thì bạn tới chỗ mà codebase, tức môi trường, bị ràng buộc chặt đến mức nó dẫn dắt bạn rất tốt và bạn có thể bước ra. Đó là giấc mơ. Cô nhấn mạnh rằng rất khó tới được điểm này: cô không muốn quảng cáo đó là thứ bạn làm dễ dàng chỉ bằng cách dùng pstack. Cần rất nhiều thời gian và công sức để nghĩ về code của bạn, nơi bạn thấy agent thất bại, và suy nghĩ thật cẩn trọng, có chủ ý, để dựng guardrail và ràng buộc sao cho chúng làm đúng theo mặc định. Và quay lại phép so sánh software factory, cô nói đây không phải "dark factory" (nhà máy tắt đèn), "đèn vẫn bật".

Một người trong hai nói "thật ra nó cũng có phần như vậy". Lauren hỏi lại "vậy sao?" rồi nói: nó "tối" theo nghĩa rằng nếu các agent tự merge pull request của chúng thì nó đã thành "tối": cô đi ngủ cạnh các agent và chúng làm việc 24/7. Cô có tương đương hơn 10 chief of staff, mỗi cái làm một mảng khác nhau. Một cái làm hiệu năng của ứng dụng desktop GrokBot, một cái sửa các bug do người dùng báo, một cái khám phá chuyện viết lại bằng một ngôn ngữ khác cho vui, kiểu "nếu như làm lại thành app native thì sao", chỉ là đồ chơi. Khi bạn đã dành thời gian thiết lập môi trường, cô đạt tới điểm mà cô review pull request sau khi nó đã land. Cô nói với agent rằng "full autopilot" là thứ có thể dùng trong pstack.

Chế độ đó kích hoạt một vòng kiểm chứng rất nghiêm ngặt: nó spawn một loạt verifier agent cho mỗi pull request và nó "fuzz", nghĩa là thực sự chạy ứng dụng, bấm quanh và cố dùng như một người thật, tìm regression và bug trong phần implement. Nó cố tìm lỗi của thứ đó rồi tự sửa, rồi làm lại, cho tới khi PR ở trạng thái có thể land. Cô thừa nhận chế độ này tốn khá nhiều token. Có thể tinh chỉnh: thay vì 10 verifier agent thì chỉ dùng một, hoặc chỉ bảo agent tự verify công việc của mình. Nhưng phần verification là mảnh chủ chốt cho cô sự tự tin: verification cộng với môi trường, tổ hợp hai thứ này cho phép cô bước ra và nói "agent, đi merge đi, sáng mai tôi xem lại bằng lịch sử commit". Nếu thấy vấn đề thì cô vào chỉnh hướng: revert, sửa, thêm lint rule mới. Cô nói mất thời gian để tới điểm đó nhưng khi tới thì cảm giác kỳ diệu, và cô nói với mọi người là giờ cô ngủ ngon hơn nhiều.

Cô kể ngày đầu tiên bật "dark factory" rất đáng sợ vì cô nghĩ "nếu mình gây ra một sev (sự cố nghiêm trọng) thì sao, nếu mình làm hỏng thứ gì đó qua đêm". Cô cần rất nhiều can đảm, nhưng cô đã làm, và giờ các agent của cô merge code trong lúc cô ngủ. Matt nói theo nghĩa đó thì nó đúng là "tối". Anh liên hệ với định nghĩa gốc của vibe coding theo Karpathy, khi code gần như không tồn tại, bạn quên rằng code có thể là một thứ. Anh thấy cách tiếp cận của Lauren hoàn toàn khác: code và môi trường là thiết yếu, nếu code và môi trường tệ thì kết quả sẽ tệ, "garbage in, garbage out". Anh nghĩ có thể có một "công tắc điều chỉnh độ sáng" (dimmer switch): có phần tối, có phần không. Đó cũng là lý do nhà hàng có thể là ẩn dụ tốt hơn: dù là chủ nhà hàng bạn vẫn thỉnh thoảng ghé nhà hàng của mình, ngó vào và nếm đồ ăn. Anh nói ý tưởng "lấy mẫu thay vì chặn" (sampling instead of blocking) là rất quan trọng.

Điều Lauren muốn người nghe không hiểu nhầm: cô không bán đây như một thứ dễ có chỉ bằng cách cài pstack. Con đường là quan sát nơi agent thất bại, rồi dựng guardrail và ràng buộc một cách có chủ ý, nhiều lần, cho tới khi môi trường đủ chặt để cô bước ra. Cô cũng cho biết chế độ kiểm chứng nặng tốn nhiều token và có thể chỉnh xuống, ví dụ dùng một verifier thay vì mười. Còn Matt thì giữ lại hình ảnh công tắc điều chỉnh độ sáng, thay cho hai trạng thái sáng và tối.

13. Cửa một chiều, cửa hai chiều và vai trò của khả năng kiểm chứng

Matt hỏi tiếp về những môi trường nhạy cảm. Lauren đang làm việc trong một môi trường khá chú trọng bảo mật, nhưng có những người làm ứng dụng y tế, luật hay tài chính. Anh nghĩ về chuyện đó như sau: có những PR giống "cửa hai chiều" (two-way door), nghĩa là bạn merge rồi revert được, quay lại rẻ. Nhưng có những PR là "cửa một chiều" (one-way door), có thể gây mất dữ liệu hoặc làm điều gì đó không dễ rút lại. Nếu phần lớn PR của ai đó là cửa một chiều thì sao: cô có khuyên làm vậy không, hay cô nghĩ sao.

Lauren nói đó là câu hỏi rất hay, và với cô tất cả quay về chất lượng của verification mà bạn lấy được từ agent. Với các lĩnh vực mà công việc có thể kiểm chứng được, việc này dễ hơn, và các cánh cửa một chiều theo một nghĩa nào đó trở thành cửa hai chiều. Nhưng nếu bạn làm một thứ cực kỳ khó kiểm chứng bằng chương trình thì bạn thực sự ở vị thế rất khó để đạt tới điểm đó. Nên cô nghĩ khả năng kiểm chứng của lĩnh vực là một yếu tố quan trọng. Kỹ thuật phần mềm là một trong những thứ khá dễ kiểm chứng trong nhiều trường hợp, dù không hoàn toàn. Các lĩnh vực khác như toán học là một ví dụ khác: không phải toàn bộ, nhưng một số mặt của toán có thể kiểm chứng được nếu bạn viết một chứng minh.

Lauren thừa nhận cô không có câu trả lời cho đoạn còn lại: đó là việc ngành và chính các kỹ sư sẽ phải tìm ra. Hy vọng và dự đoán của cô về tương lai là chúng ta sẽ thấy ngày càng nhiều ngôn ngữ lập trình mới theo hướng "định hướng cho agent". Một trong những cái cô thấy hấp dẫn nhất tên là Bend (B-E-N-D). Đó là ngôn ngữ kết hợp lập trình với chứng minh (proof). Ngày trước bạn phải viết chứng minh bằng một ngôn ngữ khác.

Cô giải thích cho người chưa quen: chứng minh nghĩa là bạn có thể kiểm chứng hình thức (formally verify) rằng một đoạn code đúng về mặt toán học, nhất là nếu bạn viết code theo kiểu lập trình hàm. Nhưng trong một thời gian rất dài bạn phải làm việc đó bằng một ngôn ngữ riêng như Lean hay TLA+ (cô nói cô đang quên vài ví dụ khác), nơi bạn dựng chứng minh toán học rồi dùng một solver để kiểm tra rằng bạn đã bao phủ mọi trường hợp, không có race condition chẳng hạn.

Để tóm lại câu hỏi: nếu bạn ở vị trí có thể tìm ra cách để agent thực sự kiểm chứng công việc theo cách cho bạn sự tự tin, thì bạn có thể để các PR được merge. Vì nếu nó biên dịch được, và nếu các chứng minh cho bạn thấy nó đúng, thì sao lại không merge? Nhưng cô nhắc rằng, dĩ nhiên, không phải chuyện nào cũng kiểm chứng được. Matt nhận xét "đây là một câu hỏi khó".

Lauren không giả vờ có câu trả lời đầy đủ cho các lĩnh vực mà phần lớn thay đổi là cửa một chiều. Cô đưa ra điều kiện: khi lĩnh vực kiểm chứng được bằng chương trình thì merge tự động hợp lý hơn; khi không thì rất khó. Hướng cô hy vọng cho tương lai là các ngôn ngữ lập trình mới gần với agent hơn và gộp phần chứng minh vào ngôn ngữ, như Bend mà cô nhắc tới.

14. pstack và skill của Matt: mỗi người nên có bộ dao riêng, và skill chỉ là ngôn ngữ

Matt nói họ phải nghĩ tới chuyện kết thúc vì sắp tròn một tiếng, rồi hỏi Lauren có việc gì sau buổi này không. Lauren nói cô sẽ cho con trai ăn tối, nhưng có thể nói thêm một chút sau đó. Matt nói vậy thì thêm năm phút nữa, và anh muốn hỏi một câu cuối: cô nhìn pstack và skill nói chung thế nào, họ đã nói về chuyện này trước khi lên sóng. Người ta hay coi đó là "skill của tôi so với skill của cô". Vậy làm sao kết hợp các framework với nhau, làm sao dùng pstack cùng đồ của anh, nên lấy gì từ mỗi bên? Anh thấy skill về cơ bản chỉ là quy trình chuyển thành chữ, và anh muốn biết cô khuyên mọi người lấy pstack và đồ của anh thế nào để biến thành quy trình của riêng họ.

Lauren nói Matt đã chia sẻ hôm nay một mẹo cô thấy rất liên quan: đi xem lại các bản ghi chat trước đó, "đào" thông tin từ chính các prompt của mình gửi cho agent, những chỗ bạn phải sửa agent, chỗ bạn phải liên tục can thiệp, rồi lấy bài học ở mức cao hơn và biến nó thành một skill tái sử dụng, để agent thôi lặp lại lỗi đó. Cô thấy pstack và skill của Matt bổ sung cho nhau, và cô hoàn toàn đồng ý rằng skill chủ yếu là quy trình: cuối cùng skill chỉ là tiếng Anh, tức ngôn ngữ, viết dưới dạng markdown. Bạn có thể kết hợp chúng theo cách hợp lý với bạn.

Nhưng cô nghĩ mọi người nên có bộ dao riêng của mình. Cô nói mình cứ quay về ẩn dụ nấu ăn, nhưng nó rất đúng: mỗi đầu bếp khi chuyển sang một nhà hàng khác đều mang theo dao của mình, công cụ đi cùng họ. Với cô, niềm tin thật ra là niềm tin vào chính công cụ của mình, và khi bạn dành thời gian mài chúng và hiểu chúng thật kỹ, bạn có thể làm những điều tuyệt vời. Bộ skill và công cụ của mỗi người sẽ trông khác nhau. Có người thấy hiệu quả khi kết hợp skill grill me của Matt với skill docs, hay skill wayfinder với một số skill thực thi trong pstack; có người dùng nhiều skill của Matt hơn, có người dùng nhiều skill của cô hơn. Cuối cùng, theo cô, tất cả quy về việc bạn tin cô và Matt tới đâu. Nếu bạn tin cả hai thì dĩ nhiên dùng skill của cả hai, nhưng cô cũng khuyến khích nhìn vào các bản ghi chat của chính bạn: bảo agent xem lại tất cả các pattern bạn đã dùng, những lần bạn phải can thiệp, và gợi ý biến chúng thành lint rule hay skill mới.

Cô thường nói lịch sử chat trong quá khứ là "kho báu ngữ cảnh", vì đó là quy trình được hiện thực hóa: đó là quy trình thật, không phải một ý tưởng trừu tượng trong đầu, mà là thứ thực sự xảy ra, và bạn thấy nó diễn ra trong thực tế, nên có thể rút ra rất nhiều thông tin. Đến mức cô có một skill trong pstack tên là recall, chính xác làm việc đó. Chuyện bắt đầu khi cô làm một vấn đề tương tự, cụ thể là virtualization cho ứng dụng Cursor, có rất nhiều bug. Mỗi lần mở một chat mới cô lại nghĩ "chat trước có nhiều ngữ cảnh tốt, mình muốn đưa bạn sang chat mới thì làm sao". Đó là chỗ việc nhìn lại các bản ghi chat cũ xuất hiện, và recall là cách cô nén workflow đó thành một skill, để không phải viết một bài luận dài mỗi lần bảo "hãy đi xem tất cả các chat này".

Cô nói mình nhìn skill, nhất là khi agent ngày càng giỏi, như việc mã hóa workflow. Skill của năm ngoái nghiêng nhiều hơn về chi tiết thực hiện, kiểu "đây là chính xác các lệnh script bạn nên dùng". Với các model mới nhất, cô nghĩ bạn có thể xóa những phần đó và chỉ tập trung vào workflow: skill trở thành một loạt bước, một loạt quy trình của bạn. Theo thời gian cô nghĩ skill sẽ ngày càng nhỏ và gọn hơn. Chúng rất tương thích với nhau; nếu muốn, cứ đọc skill của nhau rồi kết hợp theo cách của mình: kết hợp wayfinder với poteto-mode và làm thành một chế độ riêng. Điều cô thích ở skill là chúng rất dẻo (malleable), bạn có thể làm bất cứ gì bạn muốn: nó chỉ là ngôn ngữ.

Matt đồng ý: không có gì kỳ diệu trong chúng, chỉ là chữ. Nếu có phép màu nào thì đó chỉ là những từ được chọn, những cụm từ được dùng, và sự suy nghĩ đã được bỏ ra để biến một quy trình trừu tượng thành ngôn ngữ. Một khi sự suy nghĩ đó đã được thực hiện thì nó có sẵn, nằm ngay trên bề mặt, và bạn chỉ việc "nẫng" lấy. Về số liệu: số star của repo skill của Matt (mattpocock/skills) khoảng 295 nghìn vào ngày 17/10/2026; pstack nằm trong một thư mục của repo cursor/plugins nên không đo được số star riêng.

Matt cảm ơn Lauren rất nhiều, gọi buổi trò chuyện là tuyệt vời. Lauren nói buổi này rất vui, cô rất thích và hy vọng họ có thể làm lại. Hai người hẹn gặp lại vào thứ Hai, rồi Matt nói anh sẽ đóng stream; anh và Lauren sẽ nói chuyện thêm một chút ở lại đó, và cảm ơn mọi người đã xem.

Cả hai kết thúc ở cùng một ý: skill là ngôn ngữ, quy trình của bạn nằm trong lịch sử làm việc của bạn, và việc cần làm là tự rút nó ra. Lauren khuyến khích mỗi người có bộ công cụ riêng thay vì chọn một bên; Matt khép lại bằng ý rằng một khi sự suy nghĩ đã được viết thành chữ thì ai cũng lấy dùng được. Hai người hẹn nói chuyện lại vào thứ Hai.