Contents
  1. Lauren Tan, Software Engineer at SpaceXAI
  2. Her GitHub Contribution Graph: 3,000+ Merged PRs in 5 Months
  3. 1. The Trust Curve
  4. Her Hand-Drawn Trust Curve
  5. How to Build Trust: Verification, High-Quality Skills, Agent-Friendly Architecture
  6. 2. Pillar 1: Autonomous Agent Verification
  7. The SKILL.md for the control glass Skill
  8. The Real Secret: A Feature Map
  9. Feature Map: Mapping How to Reach Every Feature from the User’s POV
  10. 3. Pillar 2: Codifying Engineering Experience into Skills
  11. Skills Need Tests Too: The Eval Playbook
  12. 4. Moving from Local to Cloud
  13. Benny’s Autonomous Verification: Reproducible on Release, Already Fixed on Main
  14. 5. Pillar 3: Agent-Friendly Architecture
  15. Accommodating Agent Habits
  16. The Dune Architecture Doc: Designed Around Observed Agent Behaviors
  17. Concrete Engineering Bans in Dune
  18. 6. Five Layers of Constraints: Only the First Two Truly Count
  19. Dune’s Rules & The Five Constraint Tiers
  20. Keep PRs Focused
  21. Lauren’s Live PR Feed: CI Failures, Merged, and Closed
  22. 7. The Token Economics
  23. 8. The Ultimate Payoff
  24. Four Steps to Start Tomorrow

Huge credit to Lauren Tan for laying this entire playbook out without holding anything back. Five months of hard-earned lessons, custom skills built one by one, rewriting Grok Bot across 600+ PRs—she unpacked it all in 50 minutes, right down to how to prevent agents from realizing they’re being evaluated during tests. It’s rare to see a breakdown this honest and practical.

Shoutout to @akarixbt for sharing the full recording on X. It’s packed with pure substance.

Quoted tweet: https://x.com/i/status/2114389035388989873

Lauren opened with a telling anecdote: she woke up this morning to find 20 new pull requests merged into main. Her agents wrote the code, ran the verifications, and merged them overnight. She reviewed main over morning coffee and couldn’t find a single flaw.

Lauren Tan, Software Engineer at SpaceXAI

She knows how that sounds: like someone generating AI slop and bragging about PR volume. So she immediately grounded it with numbers. When she joined Cursor five months ago, her output in month one was minimal. Five months in, she has merged over 3,000 PRs. Last month alone saw 1,000 merges, and this month was already pacing close to 800 by the 12th. Today she works on Grok Bot at SpaceXAI, and previously spent years at Meta.

Her GitHub Contribution Graph: 3,000+ Merged PRs in 5 Months

Over the 50-minute talk, she skipped prompt tricks entirely. The entire presentation tackled one core question: how do you actually trust your agents?

Here is the complete methodology, broken down from her presentation and live demos.

1. The Trust Curve

She drew a simple diagram on the whiteboard. The X-axis represents concurrent running agents: 1, 1–5, 5–10, 10–20, hundreds, thousands. The Y-axis represents trust.

The curve rises steeply before leveling off. As she put it, the graph isn’t scientifically formal, but it captures her exact lived journey over the past five months.

Her Hand-Drawn Trust Curve

She framed it through management: if you are an engineering manager who doesn’t trust anyone on your team, you’re forced into micromanagement. You hover over screens, inspect every line of diff, and constantly worry about someone pushing bugs to production. In that state, scaling team headcount is useless because you are the bottleneck.

Working with agents is identical. A year ago, most people operated like this: spin up one or two agents, scrutinize every token of output, and constantly interrogate what it’s doing. If you don’t even trust the output of a single agent, you will never run a hundred in parallel.

You cannot scale to 100 concurrent agents when you don’t trust one.

She breaks the climb up the trust curve into three pillars: autonomous verification, high-quality skills, and agent-friendly architecture.

How to Build Trust: Verification, High-Quality Skills, Agent-Friendly Architecture

2. Pillar 1: Autonomous Agent Verification

The single most critical capability in your agent toolkit is verification.

Verification means the agent can launch and exercise the app just like an end-user: booting the interface, clicking elements, taking screenshots, collecting CPU traces, capturing memory snapshots, or spinning up an iOS simulator. Whatever surface your product exposes to users, your agent must be able to operate and inspect in the exact same manner.

Verification doesn’t guarantee an agent writes elegant code, but it guarantees the code actually works. That is step zero for building trust.

She shared her experience from week one at Cursor. She was drafted to help optimize performance for the Cursor agents window (internally codenamed Glass), slated to launch one week later. Unfamiliar with the codebase, she had to open Chrome DevTools, capture traces, and stare at flame graphs. She’d screenshot a profile, feed it to an agent, and the agent would confidently claim it found the root cause—only for her to implement the fix and find zero improvement.

In that setup, you are the human verifier and the ultimate bottleneck. The agent writes code, you trigger a local build, spot a bug, screenshot the console, and paste logs back. You’re trapped in an endless manual loop with zero concurrency.

So she built her first custom skill: control glass. It teaches the agent to drive a running development build of Cursor via the Chrome DevTools Protocol: inspecting DOM elements, taking screenshots, clicking, typing, reading the accessibility tree, capturing JS profiles, throttling CPU and network, tailing console and network logs, and launching isolated instances across multiple git worktrees in parallel.

The SKILL.md for the control glass Skill

The code for the skill itself isn’t rocket science—Electron, Web, and iOS all have programmatic hooks ready to wire up.

The Real Secret: A Feature Map

Once the skill existed, the agent could boot the app, but it had no conceptual map of what was inside. When someone reported that the left sidebar stuttered or the PR tab was broken, the agent would wander aimlessly across thousands of files, unable to locate the feature or figure out how to click to it in the UI.

The fix was pairing the verification skill with a Feature Map. One file per feature, written strictly from a user perspective: what the feature is, how to navigate to it in the interface, its sub-features, keyboard shortcuts, and the exact DOM attributes used to target elements. It also defines prerequisites: development build running, at least one agent in the sidebar, no modal dialogs blocking the screen.

Feature Map: Mapping How to Reach Every Feature from the User’s POV

With the feature map in place, even the vaguest bug reports became actionable. Cursor’s internal feedback Slack channel is filled with posts that are just a screenshot and three question marks (???). Without a map, an agent is completely lost. With the map, it correlates the screenshot to the feature, navigates to it, and reproduces the bug autonomously.

She packaged this into her open-source plugin pstack. It includes a create verification skill that explores your repository to generate an initial feature map, and a maintain verification skill that updates the map as the product evolves.

3. Pillar 2: Codifying Engineering Experience into Skills

The name pstack has an amusing origin. YC CEO Garry Tan previously released a plugin called gstack. Sharing the same last name with zero relation, Lauren created “potato stack” (pstack) as an inside joke, tailored to her personal engineering preferences.

She never planned to build an overarching plugin. It grew organically, one skill at a time, where every skill addressed a specific failure mode she observed.

Early on, she noticed agents frequently declaring, “The issue is definitely right here.” When she checked the tool call history, she discovered the agent hadn’t even read the relevant source file. Her trust in the agent dropped to zero.

Instead of throwing up her hands, she returned to the management analogy: imagine hiring a brilliant engineer with zero institutional context on their very first day. How do you make them productive? You transfer your playbook.

For an AI agent, your playbook is a skill. A skill is fundamentally a markdown document, but it encapsulates hard-won experience and explicit operating rules. Because LLMs predict the next token, feeding them high-quality context up front steers their generation toward smarter, disciplined paths.

Her rule is dead simple: every time you discover a recurring failure mode, codify it into a skill. Stop guessing. Read the code first. Delegate to subagents.

To discover these failure modes, she recommends acting as an active co-pilot. Treat it like pair-programming with a colleague: expand every tool call, inspect the chain of thought, pinpoint exactly where the agent went off track, and write a skill for that specific gap. When building your initial skill library, you need to sit in the driver’s seat.

Skills Need Tests Too: The Eval Playbook

Once a skill is written, how do you verify it actually works? Her answer: evals. An eval is simply a unit test for your agent. You don’t need a heavy framework; you just need a disciplined benchmark.

The pstack eval playbook runs like this:

  1. The controller agent writes an explicit evaluation rubric for the skill.
  2. The controller agent dispatches a cohort of subagents to execute the task, each in its own isolated directory.
  3. Directory names are intentionally made generic so subagents don’t realize they’re being tested—agents alter their behavior when they detect an evaluation harness.
  4. Run the benchmark across multiple frontier models to measure cross-model robustness.
  5. Bring in a judge agent using a different model to score outputs, preventing a model from grading its own homework too generously.

Once you have a baseline score, you can climb the ladder. In Cursor, she uses /loop to have the agent iterate on the skill repeatedly until it scores 10/10 across all rubric dimensions. The CLI tooling for control glass was refined almost entirely this way with minimal human intervention.

Maintaining skills takes genuine taste and continuous observation. Every time she modifies a skill, she re-runs the entire eval suite.

4. Moving from Local to Cloud

When asked where someone should begin building their own verification setup, her answer was unequivocal: start locally. On your local machine, you can see how the agent boots the app, executes commands, and interacts with the UI. You need that direct visibility before you can build trust.

Today, she runs almost entirely on cloud agents. Once verification skills are dialed into cloud environments, the leverage stops being personal—it benefits the entire engineering organization.

She highlighted an example: an internal Cursor agent named Benny. When a user bug report lands, Benny spins up a cloud desktop, launches Cursor, and runs the same control skills to reproduce the issue. In one case she showcased, Benny replied that the issue was reproducible on the release build, but already fixed on latest main. The team knew immediately that the fix was queued for the next release—no engineer had to spend an hour triaging.

Benny’s Autonomous Verification: Reproducible on Release, Already Fixed on Main

A crucial warning: don’t skip steps. If you’re currently at the bottom-left of the trust curve, running only two or three agents at a time, don’t try to jump straight to hundreds of headless cloud agents. You will burn through enormous token budgets with very little to show for it.

She compares modern engineers to executive head chefs. An executive chef isn’t prepping every ingredient on the line; they design the kitchen, organize workstations, and set quality standards.

5. Pillar 3: Agent-Friendly Architecture

This was the topic Lauren was most passionate about.

She opened with an age-old industry debate: should you rewrite? When a new engineer joins a company and opens the repository, the instinct is almost always, “Who wrote this? Let’s burn it down and rewrite.” Traditionally, experienced engineers advise against rewrites. But Lauren defended rewrites in the AI era—provided you understand what kind of project you’re dealing with.

Her core observation: problems that used to plague only big tech now affect every development team.

At Meta, tens of thousands of engineers committed to a massive monorepo. As she noted, the code quality in large monorepos isn’t inherently pristine—humans were writing terrible code long before AI arrived.

Large-company infrastructure is intentionally engineered around the team’s least experienced contributor: rigid frameworks, strict conventions, automated guardrails, and sandboxed permissions to keep an intern from accidentally dropping production databases. If your repo already has those guardrails, coding agents actually perform quite well because the guardrails hold them in check.

The real danger lies in brand-new greenfield projects. Grok Bot started as a rapid vibe-coded prototype where nobody was reading the code diffs line-by-line. She calls this an organic architecture: lacking hard guardrails, the agent always picks the path of least resistance. Over time, the codebase spirals out of control. Humans can no longer comprehend it; the agent kind of understands it, but every module is optimized for corner-cutting.

So she spent 600+ PRs refactoring the entirety of Grok Bot onto an architecture internally dubbed Dune—essentially Next.js for Electron apps, purpose-built for agent authoring.

Accommodating Agent Habits

The Dune architecture document opens with a foundational contract that acknowledges coding agents optimize strictly for “whatever fits in context.” As a result, agents routinely:

  • Copy whatever working snippet is closest in the file.
  • Edit the file currently open in context rather than creating proper abstractions.
  • Take the shortest compilation path that clears type checking.
  • Hesitate to delete dead code when callers aren’t immediately visible in context.
  • Follow your requested implementation pattern even if it violates system invariants.

The Dune Architecture Doc: Designed Around Observed Agent Behaviors

Because these behaviors are entirely predictable, they serve as core design constraints for the framework. Dune establishes five structural rules:

  1. The conventional path must require fewer decisions than cutting corners.
  2. Forbidden dependencies must be rejected automatically by machines.
  3. Every persisted value must have exactly one designated writer.
  4. New product capabilities are added via isolated new files, never by adding branches to shared root files.
  5. Exceptions must be tightly scoped, explicitly documented, and reviewed as architectural changes.

Her guiding principle: the shortest path must be the right path. Agents naturally seek shortcuts, so you make the correct architectural pattern the easiest shortcut to take.

Concrete Engineering Bans in Dune

A few rigid constraints enforced by CI in Dune:

  • Banned useEffect: Anyone who has written React knows this is a primary source of state desynchronization.
  • Banned code comments: This surprises many developers. In 99% of cases, agent-generated comments describe irrelevant historical trivia (e.g. “Lauren said never do this” from a single PR review applied as a misplaced universal rule).
  • Hard boundary between Electron Main and Renderer: Code is split strictly into electron-main and electron-renderer directories. CI validates the dependency graph and forbids cross-imports. If heavy computation or filesystem IO gets pulled into the rendering thread, frame rates crater below 60fps. Those hard lessons are now automated CI failures.
  • One directory per feature: All code for a feature lives inside its own dedicated folder. An agent assigned a task works inside that folder—80% of its work never touches external modules.

Writing code in Grok Bot can feel restrictive because CI and lint constraints are everywhere. But those guardrails are absorbed entirely by the agents, freeing humans from babysitting.

6. Five Layers of Constraints: Only the First Two Truly Count

She groups codebase constraints into five distinct tiers:

  1. Repository Structure & Conventions (Hard)
  2. Static Analysis: Linting, Compiler, CI (Hard)
  3. Rule files & Bugbot automated review (Soft)
  4. Skills (Soft)
  5. Style guides (Soft)

Dune’s Rules & The Five Constraint Tiers

The first two tiers are hard constraints: if code violates them, CI turns red and merging is blocked. The bottom three tiers are soft constraints: agents can overlook them, hallucinate, or follow them inconsistently. Lauren stacks all five, but never relies solely on the soft tiers. As she bluntly put it: if your quality strategy relies only on rules, Bugbot, skills, and style guides, your codebase will degrade into chaos—it’s only a matter of time.

This is also why modern tech stacks matter. Rust’s recent resurgence is partly driven by compiler strictness: ban unsafe, and if the code compiles, it almost certainly works, eliminating line-by-line human verification.

The worst possible engineering setup is relying on humans to police code standards via manual code reviews. Treat every review comment as an architectural code smell. Every time you find yourself writing “don’t do it this way” in a PR review, ask yourself:

  • Can this be turned into a custom lint rule?
  • Can this become an automated CI check?
  • Can the underlying architecture make this class of error impossible?

Keep PRs Focused

When asked about PR sizing, she noted there’s no arbitrary line limit (they range from 50 to 1,000 lines), but she strictly requires agents to decompose complex tasks into multiple sequential PRs. Git history is vital context: each PR should describe one atomic change. When regressions appear, pinpointing and reverting a small PR is trivial compared to untangling a 40,000-line monster.

Lauren’s Live PR Feed: CI Failures, Merged, and Closed

7. The Token Economics

The most frequent audience question: without an unlimited lab token budget, is this practical for normal developers?

She acknowledged working at an AI lab gives her access to unconstrained compute, but maintained that the economics work out in any commercial context.

Calculate the return on investment: yes, burning tokens to refactor architectures, build automated verifications, and evaluate skills is an upfront cost. But what is the alternative? Hiring another senior engineer. Before agents existed, building this entire framework, executing hundreds of refactors, writing test fixtures, and setting up verifications would have taken a senior engineer years of high-salary time.

Furthermore, once rigid architectural constraints are locked in, even lighter, cheaper models produce exceptional code—you don’t need to run top-tier frontier models for every single task. Keep teams lean rather than ballooning into massive engineering orgs. Penny-pinching tokens on foundational tooling misses the point.

8. The Ultimate Payoff

What excited Lauren most is that this architecture democratizes code contribution for non-technical teammates.

On the Grok Bot team, product managers, designers, and go-to-market colleagues regularly submit bug fixes. A PM will ping her with a PR: “There was a UI bug, I fixed it, take a look.” She reviews the diff and merges it cleanly. That is the real test of Dune: rigid guardrails and automated verification allow non-engineers to ship production-ready code with confidence.

She noted that Grok Bot aims to be for non-coders what Cursor became for software engineers. With an iMessage-like interface and persistent identities, you can assign an agent to monitor a specific account or have an agent summarize overnight activity every morning.

Four Steps to Start Tomorrow

If you want to apply Lauren’s playbook right now:

  1. Build a verification skill for your app. Let your agent boot the service, click buttons, capture screenshots, and read logs. Start locally and watch it execute.
  2. Write a feature map. Create one file per feature documenting how to navigate to it from a user’s perspective.
  3. Turn every correction into a skill. Whenever you correct an agent, codify the fix into a skill and evaluate it.
  4. Turn every review comment into an automated check. Convert manual feedback into linter rules, CI failures, or architectural invariants.

Only after these guardrails are solid should you consider moving agents to the cloud and scaling concurrency.

Throughout the talk, Lauren kept returning to one word: trust. Every developer has their own quality bar and idiosyncratic repo needs. Codify those standards into skills and hard constraints, verify that your agents adhere to them, and you can steadily climb the trust curve.

Models will change every few months, but the verification harnesses, skills, and architectural guardrails you build will outlast every model generation.