Lauren Tan, known as “poteto,” is a Principal Engineer working on Grok Bot and Cursor. This article explains how she uses her personal collection of skills to work with coding agents. She says she can ship around 2,000 PRs per month to production with high reliability; in August alone, that number reached 2,462. In her view, PR counts and lines of code do not mean much on their own. But when agents increase output while maintaining quality, the scale of the work starts to matter. Part 1: To Move Fast, Agents First Need to Verify Their Own Work The central idea of the first part is verification: agents need to be able to run the application, check the results, and keep making fixes until the requirements are met. If agents cannot verify their own work, humans still have to supervise every step and become the bottleneck for the entire team. Lauren sees verification as essential infrastructure because it allows both engineers and non-engineers to contribute changes and validate them. She believes getting this right can increase a team’s productivity by 100–1,000 times. This is an assessment based on the author’s experience, rather than an independently benchmarked result. To help agents test an application, the team needs to provide tools suited to its tech stack. Web and Electron applications can use the Chrome DevTools Protocol; iOS applications can run in a simulator. If existing tools are insufficient, the team can build a CLI that lets agents start sessions, send commands, use the keyboard, take screenshots, read the accessibility tree, capture performance traces, and inspect logs. One of pstack’s principles is “Build the Lever”: instead of guiding agents only through documentation, create tools that let them perform repetitive tasks consistently. CLI commands should be easy to combine, have clear instructions, return machine-readable output such as JSON, and provide error messages that explain what to do next. Operations that could have consequences should support –dry-run . Another part of verification is the Feature Map, which tells agents what the application contains, what each feature is for, and how users reach it. For example, it might describe the settings screen, its tabs, the keyboard shortcut used to open it, and relevant states to watch for. Combined with an application-control CLI, the Feature Map becomes a form of “condensed memory,” helping agents understand the product without having to rediscover everything at the start of each session. Lauren recommends maintaining this skill regularly—for example, by running /maintain-verification-skill every day—because application interfaces and features are constantly changing. If the Feature Map and control tools become outdated, agents will also verify the application incorrectly. Once agents can bring changes to a nearly merge-ready state, the team can run multiple agents in parallel. Lauren does not recommend relying entirely on Git worktrees because they consume disk space and local computing resources. She prefers cloud agents with their own computers, where they can install dependencies, run the application, interact with it like users, and capture screenshots or videos as evidence. Cursor provides an initial cloud environment setup, then creates a snapshot so subsequent runs can start faster. Part 2: Don’t Give Agents Vague Requests and Expect Them to Understand Once agents can verify their own work, the next questions are: what should they build, and how should they choose a good design? Lauren commonly encounters two problems with agents: the initial request is not clear enough, or the agent lacks the context needed to work correctly within the codebase. As a result, output quality depends heavily on preparing the right context, rather than solely on the model. One technique she uses is indirect prompting: asking agents to explain the problem in their own words before making changes. For example, when receiving feedback in Slack, she asks the agent to read the entire thread and summarize the core issue. This helps catch misunderstandings or distractions early, while avoiding imposing her own initial hypothesis on the solution. The /how , /why , and /teach skills help build an understanding of the system: /how traces how a part of the application works. If it spans multiple directories or services, the agent can split the investigation into parallel tasks. /why investigates the reasoning behind a design by examining Git history, PR reviews, tickets, documentation, Slack, error data, and analytics. /teach explains what the agent intends to do, why it chose that approach, and the trade-offs involved. To preserve context across sessions, /recall retrieves previous conversations. According to Lauren, the history of past work can contain important information about problems encountered, decisions made, and how the codebase operates. Planning Through Prototypes and Code When Lauren says she “doesn’t believe in planning,” she means she does not want to start with a long, abstract plan. She still plans, but often begins by writing out the user experience, trying a prototype, and using actual results to make decisions. For libraries or packages intended for others to use, she prefers readme-driven development: writing the instructions or tutorial first to imagine what the API will look like to users, then working backward toward the architecture. She also uses the Diátaxis framework to divide documentation into four types: tutorials, how-to guides, reference, and explanation. When several approaches are available, pstack’s prototype playbook can ask agents to build a few trial versions, put them behind a simple selector, run the application, and capture screenshots or measure actual timings. This allows agents to gather evidence themselves instead of engaging in lengthy debates about hypothetical risks. The author says pstack version 0.15.0 includes 23 playbooks, which are selected automatically based on the task to conserve context. For larger changes, /architect breaks the design process into several steps: Investigate the codebase and previous decisions using /how and /why . Generate multiple independent design proposals, potentially using different models. Have other agents evaluate and compare the proposals. Select a design and implement it based on the outline. If implementation reveals that the design is wrong, discard it and start again. One practical sign that the architecture may be wrong is the same workaround appearing in multiple places, or types repeatedly requiring any and type assertions. Only after the design is agreed upon does pstack turn it into an implementation plan. Every task needs a way to demonstrate and verify its results. Automated tests alone are insufficient without running the application to confirm its actual behavior. Changes are split into small, independent PRs that are easy to review. Lauren’s examples include investigating timeouts using data and commit history, designing a webhook rate-limiting system through prototypes, and splitting a UI library migration into multiple PRs with visual checks. The Main Takeaway from Both Parts pstack is more than a collection of prompts. It combines skills, application-control tools, a Feature Map, historical context, prototypes, and a verification process so agents can complete a fuller cycle of work on their own. submitted by /u/dumpshoot
Originally posted by u/dumpshoot on r/ArtificialInteligence