Making AI Agents Trustworthy: Verification, Hard Constraints, and Convention-Based Architecture
TL;DR: To safely let AI agents write code, first make them able to verify their own work, then replace manual review with hard constraints like CI and lint plus a convention-based architecture, so trust can build step by step until agents auto-merge PRs.
Key ideas
- Trust is the central theme: without enough trust you can only watch a few agents closely, can't parallelize, and shouldn't spin up many cloud agents at once, which just wastes tokens; she climbed the trust curve over 5 months until agents auto-merged and she woke up to 20 PRs already in main.
- Verification is where trust starts: without verification skills the human is the bottleneck, so she first taught agents to actually operate the app (the control glass skill and a feature map), then used evals as unit tests to keep improving the skills, and only then expanded to the cloud, where Benny automatically reproduces bug reports.
- The engineer's role is like a head chef: you no longer cook every dish yourself but design the environment and assign work; start locally because you can watch how the agent operates, and scale to the cloud and auto-merging only once trust is established.
- Constraints are reliable only if they are enforced hard: Dune bans useEffect and code comments, uses CI to check import boundaries between main and renderer, and guides agents with a convention-based architecture where the shortest path is the best path; rules, skills and bugbot are only soft supplements, and every issue found only through manual review should become a lint or CI rule.
- Token spending is a return-on-investment question: the upfront refactor (over 600 PRs) cost a lot of tokens but means even the dumbest agent can do well and even PMs and designers can contribute safely; however, her lab has no token limits, so she can't ask everyone to do the same.
Section summaries
0:25AI Pressure and a First Spec-First Experiment
She believes the best way to use AI is as a partner you code with, not as a replacement for coding or a way to outsource thinking. Many engineers feel pressure to ship 100 PRs a week because they want to be seen as good at using AI; in her own experience, AI saved coding time but she spent more time reviewing and fixing. She also tried the popular approach of having AI write a spec first, reviewing the spec, and then building.
▶ Watch from here1:25Trust, Accumulated Opinions, and the Curve
The central theme is trust: senior engineers have built up many opinions, and when they see an agent guess wildly, hallucinate, and confidently claim to have found the root cause, trust drains away; without enough trust you can't get the agent's value, like a manager who doesn't trust their reports and can only micromanage. About 1 year ago, when hardly anyone was coding with agents, you could only watch a few agents closely and couldn't parallelize; over the past 5 months she climbed the trust curve, and now agents auto-merge PRs, so she wakes up to 20 PRs already in main with decent quality. Her contribution graph mirrors this curve: output was low in month 1, last month's merged PR count was striking, and this month it was already close to 800 by the 12th.
▶ Watch from here
5:55Verification Is the Most Important Capability
In an agent workflow, she thinks the most important skill is verification: the agent must be able to actually run the code, capture CPU traces or heap snapshots, open an iOS simulator, and operate and test the app like a user. This closes the loop; it doesn't guarantee good code, but at least the code is correct, which is a big step toward building trust.
▶ Watch from here
7:25Her Time at Cursor and Teaching the Agent to See the Screen
She joined Cursor 5 months ago, originally for the cloud agents team, but because of her React experience she was sent to support the agents window, which is also a React app. In week 1 she couldn't make sense of a Chrome DevTools flame graph, and neither could the agent, which just confidently pointed at wrong causes; without verification skills the human becomes the bottleneck, copying screenshots and error messages to the agent by hand. So she built the control glass skill (Glass is the internal codename for the agents window), teaching the agent to control the app through the Chrome DevTools Protocol or Apple's simulator tools. But the agent could operate the app without knowing what features were in the window, so an extra feature map was needed.
▶ Watch from here
11:40Feature Map, Pstack, and Skill Evals
The feature map lists how to reach each feature, keyboard shortcuts, and the selector attributes used with CDP, so the agent can match even very poor reports (such as just a screenshot plus a question mark) to a feature; the Pstack plugin includes features for creating and maintaining verification skills. Pstack's name is a jab at GStack by Y Combinator CEO Gary Tan (the two share a surname but are unrelated); it wasn't planned in advance but built up by watching the agent's failure modes and writing each into a skill. A skill is essentially markdown, like teaching a new hire with no background. Skills are maintained through evals, which are unit tests for agents: an orchestrator agent sets a scoring rubric, dispatches multiple sub-agents (deliberately not telling them they're being evaluated), and judge agents from different models cross-check, looping until a perfect 10. But she admits maintaining skills is hard and takes taste and observation.
▶ Watch from here22:35The Head Chef Analogy: From Local to Cloud Agents
She uses a head chef analogy for the role shift: engineers no longer cook every dish themselves but design the kitchen environment and assign work to a team. Adoption starts locally, because you can watch the agent launch a CLI or desktop app and see how it calls interfaces to operate it; she herself mainly bets on cloud agents, where an agent named Benny takes over all bug reports, runs Cursor on a cloud desktop, and reproduces issues with the same control skills, for example reporting that a displayed bug is reproducible but already fixed on main, so only a new release is needed. This benefits the whole team, but you must build trust first rather than spinning up lots of cloud agents at once and wasting tokens.
▶ Watch from here27:15Recap and Not Trusting Blindly
The interviewer recaps the path: first build verification skills to confirm the code is at least correct, build trust locally, then expand to the cloud where agents take over reports and submit PRs themselves, and only last auto-merge and then review on main. She agrees and says there is no shortcut on this path, because trust depends on personal standards, and she doesn't want anyone to trust her blindly; the plugin can speed up getting started, but she encourages everyone to adapt it into their own skill set, writing their own engineering standards into skills and verifying that the agent really follows them.
▶ Watch from here
29:35The Rewrite Debate and Code Drift
She argues rewrites are worth considering: existing projects that already have frameworks, conventions and guardrails let agents do quite well, because large companies built these limits long ago to look after their least capable engineers; new projects are the biggest risk and also the biggest opportunity. Take the brand-new Grockbot: when it was built purely by vibe coding and no human had read the code, there were no guardrails, the agent solved tasks in the most convenient way, and the code eventually spiraled out of control. She therefore spent over 600 PRs refactoring Grockbot into a new architecture and now almost never reads the code; this cost a lot of tokens, but designers, PMs and other non-engineers can now add features with confidence, because CI has many constraints and the agent absorbs the hassle of coding.
▶ Watch from here35:25Enforcement at Scale and PR Size
Asked about CI and PR size, she says there is no hard limit; size starts at around 50 lines and can be much larger depending on content, for example a PR that deletes many files is almost all deletions. She still requires agents to split work into multiple PRs so each PR describes only a simple, small change; git history then becomes rich context and rollbacks are easy, and you never get a 40000-line PR where nobody knows what's inside. Incidentally, virtualization in Grockbot and Cursor is powered by a new library, Pretext.
▶ Watch from here
38:15Dune and Convention-Based Architecture
Dune is the internal codename for Grockbot's architecture, which you can think of as Next.js for Electron apps, designed for agents to code in. Its CI checks are annoyingly numerous: useEffect is banned, and so are code comments, because she found that 99% of the time the comments agents write are historical narration unrelated to the code. An Electron renderer must hold 60 fps, so each frame must finish within 16 milliseconds, and accidentally pulling heavy computation into the renderer causes stutter; so she wrote these lessons into the framework as hard failures: separate electron main and electron renderer directories, CI checks the dependency graph, and cross-directory imports are forbidden. She believes the strongest enforcement layer is a convention-based architecture, because agents love copying existing patterns; for example, all code for a single feature lives in one directory, which encapsulates roughly 80% of the work.
▶ Watch from here
43:35Shortest Path, Boundaries, and Soft Rules
Her first principle is that the shortest path is the best path: since agents love shortcuts, make the fastest way also the best way; the framework is just a set of ideas and principles and won't be open sourced. Enforcement comes in layers: CI checks, lint rules written for observed bad patterns, and compiler diagnostics all turn CI red and are hard constraints; rules, skills and bugbot are softer, since the agent can still forget them, so they can only be layered on top and can't be relied on alone, or the code will eventually turn to garbage. Technology choice matters too: for example, the Rust compiler is strict, and if you ban unsafe blocks, a passing build gives some confidence. If humans have to point out a constraint in code review every time, that is a bad smell, and it should become a lint rule, a CI failure, or have the problem eliminated at the root.
▶ Watch from here49:45Token ROI and Keeping Product in Sync
For engineering leaders, tokens are a return-on-investment question: refactoring code and building constraints upfront takes a lot of tokens, but if agents do the coding you don't need to grow into a 10000-person engineering organization; this work would have taken her years alone before the agent era, so the trade-off is hiring people versus spending tokens so even the dumbest agent does well. She also admits the AI lab she works at has no token limits, so she can't ask everyone to do the same. Asked how product and other teams keep up, she says Grockbot is the key: its interface is like iMessage, making agents easy for non-technical people, and PMs and designers even submit fixes directly, which she reviews and, when they look perfect, simply approves, showing that Dune's strict constraints let non-experts contribute at a high standard.
▶ Watch from here