@dotey: I remember saying half a year ago that I don't review PRs much anymore, and a lot of people in the comments disagreed, thinking that was irresponsible. Looking at it again now, more and more people aren't reviewing PRs. For instance, in the podcast I just listened to, Lauren Tan, who builds the Grok Bot at SpaceXAI, merges 2,500 PRs a month — and she also doesn't review them one by one: at night she lets the AI check and merge on its own, and she spot-checks in the morning.

X AI KOLs Timeline News
agentic-coding code-review ai-agents software-engineering skills cursor xai

Summary

Baoyu's commentary on the podcast interview with Lauren Tan and Matt Pocock: Lauren builds the Grok Bot at SpaceXAI and merges 2,500 PRs a month without reviewing each one, relying instead on AI-driven automated verification, code conventions, and an open-source Skill system called pstack to guarantee quality. The article cautions readers not to rush to copy her approach — first understand what makes it possible for her: models strong enough, token costs, the limits of AI verification, and having your own domain expertise to steer things.

I remember saying half a year ago that I don't review PRs much anymore, and a lot of people in the comments disagreed — they thought that was irresponsible. Looking at it again now, more and more people aren't reviewing PRs. Take the podcast I just listened to: Lauren Tan, who builds the Grok Bot at SpaceXAI, merges 2,500 PRs a month and also doesn't review them one by one — at night she lets the AI check and merge on its own, and the next morning she spot-checks. Not reviewing doesn't mean not caring about quality. She relies on two other things to guarantee it: First, she gives the AI a way to run the program the way a real human user would, so it discovers problems on its own; Second, she sets down a lot of rules for the code, making it very hard for the AI to write bad code. She turned this whole approach into a set of Skills and made it public — it's called pstack. By the way, the host of this podcast, Matt Pocock, was formerly a well-known programming course instructor whose public Skill library has over 200,000 stars on the code hosting site GitHub, one of the most popular Skill libraries around — so this episode is essentially a conversation between two peers. Lauren previously worked at Meta on the web framework React, and joined the AI coding tool company Cursor in March this year. Cursor was acquired by SpaceX this past August and folded into its AI division, SpaceXAI. Based on the podcast, here's a brief summary of Lauren's approach, with my own commentary at the end. 1. First, get the AI able to check its own work Lauren says that even if you don't use her pstack, the single most important skill everyone should have is "verification": giving the AI "hands and eyes" so it can run the program it just wrote and click through it like an ordinary user, seeing whether the results are right. She learned this the hard way. Back in April, while at Cursor fixing a window lag issue, she did everything by hand at first — digging through performance metrics herself, relaying what she found to the AI, then checking its fixes. She describes herself as a "human relay station" between the AI and the testing tools. The first Skill she ever wrote at Cursor was verification. Before that, the AI couldn't see the effect of its own changes and could only wait for her to pass messages back and forth. With verification, the AI could change the code, look at the results itself, and revise again if it wasn't happy — iterating round after round without her having to sit there. Today every product on her team ships with a Skill like this, and the whole team uses it. While building it she also arrived at a principle: some parts of your work require judgment, while others are just following procedure. The parts that follow procedure should be turned into fixed programs, and only the parts requiring judgment should be left to the AI. The impetus was noticing that every AI, before checking anything, had to write its own small test program from scratch — each one different, some working and some not, all of them thrown away afterward, slow and wasteful. She packaged that part into a ready-made tool that all the AIs simply call. 2. When the AI keeps making the same mistake, change the rules — not the AI Lauren dislikes the fashionable term "software factory." She prefers comparing her work to running the back kitchen of a Michelin-starred restaurant. The head chef doesn't cook every dish by hand, but has to arrange the entire kitchen: when ingredients arrive and how they're stored, what tools each person uses, the order dishes go out. Engineers today are the same — no longer writing code by hand, but still responsible for the outcome. She believes the most important job engineers have now is setting up this "kitchen" properly. People who never spend time on it can't trust what the AI produces and end up having to watch it step by step, too busy to improve anything — like always cutting vegetables with a blunt knife. She gives her own example. The earliest versions of Grok Bot were crammed into eight giant files, each at least 10,000 lines; whenever the AI added a feature it just shoved it in, and the mess kept growing. So she set rules: every feature must live in its own dedicated folder, there's only one way to do each thing, and code that violates the rules gets caught by automated checks. Now the AI doesn't have to think hard when adding features — it just follows the rules. Her habit is to keep watching where the AI goes wrong, and each time she asks herself: can I add a rule that makes this kind of mistake impossible to write in the first place? The "don't check everything one by one" approach rides on the same system. She says a restaurant owner with several restaurants can't taste every dish — they can only spot-check. Each day she picks some changes to examine closely; if something went wrong by chance, so be it. But if several AIs are all taking the same shortcut, that means the rules and tools are what need fixing. Her pstack has a fully automated mode: every change dispatches a batch of AIs dedicated to checking, opening the app and clicking around everywhere; they find problems and fix them themselves, repeating until there's nothing left, then merge. Each morning she reviews the change log, reverts anything that looks off, and adds a new rule. She says she was terrified the first time she let the AI merge code overnight, worrying about breaking the live product in the middle of the night — now she actually sleeps better. She also cautions that getting to this point is hard and takes a huge amount of time observing and tuning; installing pstack alone won't get you there. Matt asks what happens when changes can't be undone — say, if they'd lose data, or in fields like healthcare or finance. She says it depends on whether the output can be automatically checked by a program. Most software can; areas where that's hard to do are hard to do this way, and she doesn't have the answer herself. 3. Where the 2,500 changes come from: she stopped being the messenger Those 2,500 changes are not 2,500 conversations she initiated. User feedback is scattered across chat tools, email and social media; it used to be on her to find it and relay it to the AI. Now she has the Grok Bot keep watch over those channels. The Grok Bot, launched by SpaceXAI this past August, is an AI agent that can log into email, chat tools and other apps and do things on people's behalf. As soon as it spots a new piece of feedback, it forwards it to a coordinating AI. This coordinator doesn't write code itself — it only breaks down tasks, assigns them to other AIs, and tracks progress. It's effectively her kitchen supervisor. Why not just assign one AI per problem? She says a batch of feedback often stems from a single root cause; fixing them separately means duplicate labor and you can't see what the real problem is — you only see it when you look at them together. She currently runs more than ten of these coordinators at once, each covering its own area. She keeps asking herself one question: where does the flow still bottleneck on me, and why does the AI have to come ask me? Then she figures out how to teach the AI to go get the real information itself. She also points out that of the 2,500 changes, new features aren't the majority — many are maintenance work like cleaning up code. 4. Domain experts are more valued than ever, even if they can't code Matt asks: now that everyone relies on AI, is technical knowledge no longer worth anything? Lauren's view is the opposite. As models get stronger, what increasingly holds people back is whether they can clearly articulate what they want. So she believes that doctors, lawyers — people who know their field deeply — can build great products as long as they know a little about technology and can use AI agents. Both of them believe there's nothing mysterious about a Skill: it's just writing down your own workflow. Lauren suggests going back through your chat history with the AI to find the places where you repeatedly corrected or repeatedly intervened, and writing those down as Skills or rules. You can borrow other people's Skills and piece them together, but in the end everyone should have their own — just as a chef moving to a new restaurant still brings their own knives. 5. Closing After watching this interview, many people will think they can stop reviewing PRs like Lauren from now on — just install her Skills and let the model verify things. My own practice is pretty similar to hers; I also have a huge number of PRs every day and don't review them either. But my advice is: don't rush to copy what she does. First understand what makes it possible for her to do it. 1. Can you use the best models, and can you afford the tokens? Before I started using Fable and Opus 5.5, I wasn't very comfortable trusting code written by the AI. It was only after using them that I really dared to let the AI write code without reviewing much. Model capability matters enormously — if the capability isn't there yet, don't think about this for now. There's also cost. Someone like me, with no big company to lean on, has to pay out of pocket for two Claude Max 20x accounts and use them sparingly. Lauren is at a large company; she doesn't have to think about token consumption at all and can use the best models in the fastest mode throughout. But don't give up hope either. A model at the Fable tier might be as cheap half a year from now as DeepSeek V4.1 Flash is today, affordable to everyone. Keep it up, Liang Sheng. 2. You can't rely entirely on AI verification Even if the level at which GPT-6 operates a computer now exceeds that of real humans, having it do verification can only replace part of the work. You can't truly hand everything over to it — you still need to look yourself. What you can do is gradually turn all those repetitive manual tasks into Skills and automated scripts, freeing up the grunt work. 3. The direction has to come from your own expertise No matter how smart the AI is, it can't decide which direction you should go. It's like strapping a rocket engine onto a car — you still have to tell it where to drive, and if it veers off course you have to correct it promptly; otherwise, however fast it goes, it's heading in exactly the wrong direction. Software is the same. You can't expect a single prompt to produce a Taobao. You first need to build a small site where products can be listed and browsed, then add user registration, and you have to distinguish buyers from sellers, then payments and security, and after the features are built it has to hold up when a lot of people use it at once. Any software even slightly complex can't rely entirely on AI — a person has to break it down, plan it, split it into small versions and small milestones, verify each one, and re-point the direction when it deviates. Sometimes, as you go, your own idea changes — the AI can't possibly know what you really want. So as the podcast puts it: models keep getting stronger, and what increasingly holds people back is whether you can clearly articulate what you want. 4. You don't have to use their Skills, but you should learn to hand work off to agents Matt's and Lauren's Skills are both very popular, but you don't necessarily have to use them. For one, today's models have already learned the fundamentals of software engineering very well. Lauren said on the podcast as well that last year's Skills still had to spell out exactly which command to type; now those can all be deleted, leaving only the workflow steps, and Skills will keep getting shorter. For another, their development process and environment are probably quite different from yours. Lauren's Skills were all distilled from her own work: the verification Skill came from her days as a "human relay station," and another Skill called recall came from the fact that every time she opened a new chat she had to explain the background from the previous one all over again. So what matters more is starting from your own daily development process. Those steps that still require manual operation — hand them off to an agent as much as possible. Once the agent does them smoothly, distill its operations into a Skill and iterate and refine it over and over. If you don't know where to start, you can follow Lauren's approach: go through your chat history with the AI and find the places where you repeatedly corrected or intervened. That way the Skills you iterate toward will genuinely fit you — and in her words, every chef should have their own set of knives.
Original Article
View Cached Full Text

Cached at: 10/04/26, 03:18 PM

I remember saying about half a year ago that I don’t really review PRs anymore, and many people in the comments disagreed, saying it was irresponsible. Looking back now, more and more people are skipping PR reviews. For example, on a podcast I just listened to, Lauren Tan, who works on the Grok Bot at SpaceXAI, merges 2,500 PRs a month and also doesn’t review them one by one: at night she lets the AI check and merge on its own, and in the morning she spot-checks.

Not reviewing doesn’t mean ignoring quality. She relies on two other things to keep quality up:

First, letting the AI use the program end-to-end like a real user, so it finds problems itself; Second, setting a lot of rules for the code, so the AI can hardly write bad code.

She turned this approach into a set of Skills and released them publicly under the name pstack.

By the way, the host of this podcast, Matt Pocock, is a well-known programming course instructor, and his publicly available skill library on GitHub has over 200,000 stars — one of the most popular skill libraries out there. So this was really a conversation between two peers. Lauren previously worked on the web framework React at Meta, and joined the AI coding tool company Cursor in March of this year; Cursor was acquired by SpaceX in August of this year and merged into its AI division, SpaceXAI.

Based on the podcast, here’s a brief summary of Lauren’s approach, with my own commentary at the end.

1. First, let the AI be able to check its own work

Lauren says that even without her pstack, the single most important skill anyone can have is “verification”: giving the AI “hands and eyes” so it can run the program it just wrote, click through it like an ordinary user, and see whether the results are correct.

This is a conclusion she arrived at after getting burned. In April of this year she was fixing a window stuttering issue at Cursor, and at first she did everything by hand: she looked at all the performance data herself, relayed what she saw to the AI, and then went back to check after the AI made its changes. She described herself as a “human relay station” between the AI and the debugging tools. The first Skill she ever wrote at Cursor was verification. Before that, the AI couldn’t see the effect of its own changes and could only wait for her to pass messages back and forth; with verification, the AI can make a change, look at the result itself, and change again if it’s not satisfied, iterating round after round without her babysitting it. Today, on her team, every product ships with this kind of verification Skill, and the whole team uses it.

While building this Skill she also came up with a principle: some parts of your work require judgment, and some parts are just following procedure. The procedural parts should be written as fixed tooling, and only the judgment parts should be left to the AI. The trigger for this was noticing that every AI, before it ran a check, would have to write the little checking program from scratch, each one differently — some worked, some didn’t, and they were thrown away after each use. Slow and wasteful. She turned that part into a ready-made tool that all the AIs call directly.

2. When the AI keeps making the same mistake, change the rules, not the AI

Lauren dislikes the trendy phrase “software factory.” She prefers to compare her work to running the back-of-house kitchen at a Michelin restaurant. The head chef doesn’t have to cook every dish by hand, but has to arrange the whole kitchen: when the ingredients come in and how they’re stored, which tools each person uses, the process the dishes follow. Engineers are in the same boat now — they no longer write the code by hand, yet they remain responsible for the outcome. She believes the most important job for engineers today is setting up this “kitchen” well. People who haven’t taken the time to set it up don’t trust the AI’s output, can only watch it work step by step, and are too busy to improve their tooling — like cutting everything with a blunt knife.

She gave her own example. The earliest versions of the Grok Bot code were crammed into eight enormous files, each with at least 10,000 lines. When the AI added new features it would just keep stuffing them in, and it got messier and messier. She later set a rule: every feature must live in its own folder, and for any given task only one way of writing it is allowed; code that violates the rules is automatically blocked by a checker. So when the AI adds a feature it doesn’t have to think — it just follows the rules. Her habit is to keep watching where the AI goes wrong, and every time she sees a mistake she asks herself: can I add a rule so that this mistake can never be written in the first place?

Not reviewing each PR individually relies on the same approach. She says the owner of several restaurants can’t taste every dish, so they can only spot-check. Every day she picks some changes to look at closely; if the error was just a one-off, she lets it go. But if multiple AIs are all taking the same shortcut, that means the rules and tooling are what need to change. Her pstack includes a fully automated mode: each change dispatches a batch of dedicated checker AIs, which open the program and click around everywhere, fix whatever problems they find, and keep iterating until there are no problems left — then merge. In the morning she reviews the change log, reverts anything that looks wrong, and adds a new rule.

She says the first time she let the AI merge code all night by itself she was terrified — worried it would break the live product in the middle of the night. Now she actually sleeps better. She also cautions that getting to this point is hard: it takes a huge amount of time observing and tuning, and installing pstack won’t get you there directly. Matt asked: what if a change is irreversible — for instance, something that could lose data, or work in medical or finance? She said it depends on whether the output can be checked automatically by a program. Most software can be, and fields where automatic checking is hard make this approach very difficult — she doesn’t have the answer either.

3. Where the 2,500 changes come from: she’s no longer the message runner

Those 2,500 changes are not 2,500 conversations she started herself. Problem reports from users are scattered across chat tools, email, and social media, and it used to be her job to read them herself and relay them to the AI. Now she has the Grok Bot monitor these channels. The Grok Bot is a product SpaceXAI launched in August — an AI agent that can log into email, chat tools, and other applications to do things on your behalf. The moment it spots a new piece of feedback, it forwards it to a “coordinator” AI. That coordinator doesn’t write any code; its job is to break the problem down, assign it to other AIs, and track progress — essentially her back-of-house manager.

Why not just assign one AI to fix each problem? She says a batch of feedback usually comes from the same root cause. Fixing them separately means redundant work, and you also can’t tell what the real bug is — you can only see it when you look at them together. Right now she has more than ten of these coordinators running at once, each handling its own area. She keeps asking herself one question: which step is still stuck on me, and why does the AI have to ask me? Then she figures out how to teach the AI to get the real information on its own.

She also clarified that new features don’t make up the majority of those 2,500 changes — a lot of it is maintenance work like code cleanup.

4. Domain expertise is more valuable than ever — even if you can’t code

Matt asked: if everyone is relying on AI, is deep expertise no longer worth anything? Lauren thinks the opposite. As models get stronger, what’s holding people back is whether you can clearly articulate what you want. So she believes that someone like a doctor or a lawyer who knows a particular field deeply, as long as they understand a little bit of technology and can use AI agents, can build something really good.

Both of them agreed that there’s nothing mystical about a Skill — it’s just writing down your own process in words. Lauren suggests going back through your chat history with the AI, finding the places where you keep correcting the AI or keep stepping in, and writing those down as Skills or rules. Other people’s Skills can be mixed and matched, but in the end everyone should have their own set — like a chef who carries their own knives even after changing restaurants.

5. Final thoughts

A lot of people will finish this interview and think: from now on I can stop reviewing PRs like Lauren does — just install her Skill and have the model do the verification. My own approach these days is similar to hers: I have a huge volume of PRs too, and I don’t review them either. But my advice is not to rush to copy how she does it — first understand what makes it possible for her to do it.

1. Can you use the best models, and do you have enough tokens?

Before I started using Fable and Opus 5.5, I wasn’t very confident in the code the AI wrote. After using them, I finally dared to let the AI write without much review. Model capability matters a lot — if the capability isn’t there yet, don’t even think about this.

There’s also the cost. For someone like me, without a big company to lean on, I have to pay out of pocket for 2 Claude Max 20x accounts, and use them sparingly. Lauren is at a big company, so she doesn’t have to worry about token consumption — she can use the best models and the fastest mode throughout without a problem.

But don’t rush either. A model at Fable’s level may in six months be as cheap as today’s DeepSeek V4.1 Flash — affordable for everyone. Hang in there, Liang Sheng.

2. You can’t rely entirely on AI for verification

Even if today’s GPT-6 is already better at operating a computer than a real person, having it do verification only replaces part of the job. You can’t hand it all off — you still need to look yourself.

What you can do is gradually turn those repetitive manual tasks into Skills and automation scripts, and free yourself up from the grunt work.

3. Your own expertise has to point the direction

No matter how smart the AI is, it can’t decide which direction you should go. It’s like strapping a rocket engine to a car — you still have to tell it where to drive, and course-correct when it drifts. Otherwise, the faster it goes, the further off target it ends up.

It’s the same with building software. You can’t expect one prompt to produce a Taobao. You first have to build a small site where people can list products and browse them, then add user registration, and you have to distinguish buyers from sellers; then payment and security. And after the features are built, it has to hold up when lots of people use it at once. Any software beyond a little bit of complexity can’t rely entirely on AI — a person has to break it down, plan it, split it into small versions and small milestones, verify as you go, and re-steer when you drift off course. Sometimes along the way your own idea even changes — the AI can’t know what you actually want.

So, as the podcast said: as models get stronger, what’s holding people back is whether you can clearly articulate what you want.

4. You don’t have to use their Skills, but you should learn to delegate work to Agents

Matt’s and Lauren’s Skills are both very popular, but you don’t have to use theirs.

For one thing, current models already learn the fundamentals of software engineering very well. Lauren mentioned in the podcast that Skills from last year had to spell out exactly which command to type; now all of that can be deleted and only the process steps kept — Skills will get shorter and shorter.

For another, their development workflow and environment are probably very different from yours. Lauren’s Skills all grew out of her own work: the verification Skill came from her days as a “human relay station,” and another one, called recall, came from the fact that every time she started a new conversation she had to re-explain all the context from the previous one.

So what matters more is starting from your own day-to-day development workflow. The steps you still have to do by hand — hand them off to an Agent wherever possible. Once the Agent has them working smoothly, distill its process into a Skill, and keep iterating and optimizing.

If you don’t know where to start, you can follow Lauren’s approach: go through your own chat history with the AI and find the places where you keep correcting it or keep stepping in. Skills built this way are the ones that will truly fit you — in her words, every chef should have their own set of knives.

lauren (@poteto): i had a lot of fun chatting with @mattpocockuk today about how i was able to land 2,500 PRs last month! Matt is a wonderful interviewer so i think the interview turned out really interesting

both of our skill plugins work great together, so i recommend giving both a try and

Similar Articles

@Michaelzsguo: https://x.com/Michaelzsguo/status/2106219013978140679

X AI KOLs Timeline

An hour-long conversation between Poteto (creator of pstack, SpaceX) and Matt Pocock revealing how they merge 2,500 PRs per month: from distilling repeated AI corrections into Skills, to giving Agents the ability to verify their own work, using tools and lint constraints to cut down repetitive effort, all the way to multi-Agent inner and outer loops plus spot-check reviews.

@vikingmute: Great workflow, now it's also my main workflow for developing new features and new ideas: Grill - let AI fiercely question every detail until clear -> Research - separately analyze difficult areas and create a research document (optional) -> PRD - gen...

X AI KOLs Timeline

VikingMute shares their main workflow for developing new features and ideas: using AI (Grill) to drill down on details, Research to analyze difficulties, generating a PRD, breaking it into independent Issues, step-by-step implementation, and finally Review. This is a supplement to Matt Pocock's seven-stage AI development method.

@thinkszyg: The AI Coding Speed Paradox: Coding 48% Faster, Review 6x Slower. How to Rebuild the Review Process? SD Times Analyzes Data from 250,000 Developers: AI Boosts Coding Speed by 48-58%, But AI-Generated PRs Get Stuck in Review for 4-6x Longer…

X AI KOLs Timeline

The article points out that AI coding increases coding speed by 48-58%, but code review time increases by 4-6x, and security vulnerabilities also rise. It proposes a three-step plan to rebuild the review process: AI pre-review, focusing on architectural decisions, and using Microsoft's open-source ASSERT framework for behavioral verification.