Prompt bigger: Theo on end-to-end agents

1. 018:16

   Let it own the job, not the keyboard

   Most engineers use the agent as a faster keyboard: it types in their editor. Theo treats it as a co-worker who owns the work until it's ready to hand back to a person.

   How
2. 024:35

   Most teams use AI in a few separate spots

   Writing the code, fixing review notes, maybe an AI reviewer. Everything before the ticket, and everything between those spots, is still people.

   How
3. 034:58

   The gaps are where the time goes

   Each hand-off waits for someone to get to it. Across time zones, a fix of under 100 lines can take weeks.

   How
4. 046:32

   Put more steps in one prompt

   Not “fix this file”. Fix the whole problem, test it in a browser, write a test that fails until the bug is gone, have helper agents review as it goes.

   How
5. 0511:05

   Say the goal, not the files

   Tell it what you want to be true, not which code you think should change. Tickets are often wrong about the code.

   How
6. 0611:41

   Give it a way to check

   Something it can run to prove the job is done the way you meant: a test, a browser, a list of languages to try.

   How
7. 0712:06

   Big prompts are scary. Ask what it touched.

   You can't know up front what a big prompt will change. That's fine: read what it did, and ask “What did you touch?”

   How
8. 086:23

   People still review

   He isn't saying drop code review or the product manager's check. The agent just gets much further before it needs you.

   How
9. 0913:05

   Coding went to zero. Review didn't.

   3 to 6 hours of coding is now minutes. The 30-minute review and 20-minute test per change stayed, and there are ten times as many changes.

   How
10. 1014:07

    Point agents at review and testing next

    Smaller, tidier changes. Agent reviewers that help you, not replace you. Sandboxes where agents test their own work.

    How

Agent

An AI that works in steps on its own: reads files, runs commands, edits code, checks its work. Claude Code and Codex are agents.

Prompt

What you type to the agent. On this page, the instructions for one piece of work.

Ticket

One piece of work written down in a tracker such as Jira or Linear: “fix the login bug”, with details.

Product manager (PM)

The person who decides what gets built and checks it solves the user's problem.

Designer

Draws what a change should look like before anyone writes code.

Tech lead

The senior engineer who turns the plan into tickets.

Engineer 1, Engineer 2

Theo's names for the person who writes the change and the person who reviews it.

Pull request (PR)

A proposed code change, waiting to be reviewed and merged.

Code review

A second person reads the change and asks for fixes before it goes in.

Merge, ship

Merge puts the change into the main code. Ship puts it in front of users.

End-to-end test

A test that uses the app the way a person would, start to finish: open the page, click, check what shows up.

Failing test first

Write a test that shows the bug (it fails), then fix until it passes. Proof the bug was real and is gone.

Subagent

A helper agent the main agent starts for part of the work, such as a reviewer.

Staging environment

A copy of the app that works like the real one but holds fake data, so tests can't hurt real users.

Mock data

Fake data made for testing.

Sandbox

A walled-off space where an agent can run and break things safely.

Repo

A project's code folder, tracked with Git. Bigger products are often split across several.

Localization

Making an app work in other languages.

Primitives

The basic shared building blocks everything else uses. In his prompt, the shared translation functions.

Surfaces

Every place users meet the app: pages, emails, the phone app, error messages.

Verify, validate

Check that a change does what you wanted by running it, not just by reading it.

Slop

AI output that looks finished but isn't: extra code, wrong fixes, padding.

Slop-ocalypse

Theo's word for the flood of AI-made pull requests people now have to review and test.

Wispr Flow

A voice-to-text app. Theo's arm was in a cast, so he dictated the big prompt.

Six examples, three basic and three advanced. The translation one is Theo's; the rest are ours, written the way he describes.

Update app.tsx to use the new localization primitives found in [link]

Centralize localization across all of our repos so that the same primitives are used consistently. I want to make sure that certain keywords are translated properly in all of the surfaces that are exposed to users. Make sure you validate this in multiple languages and make sure this set of keywords is translated consistently across all of the surfaces that matter.

His reason for the goal over the files: “I would never describe a Jira ticket to a coworker based on what files should be touched. I would describe it based on what problem it is discussing.” The technical notes on a ticket are often wrong; the goal usually isn't. 11:26

[What should be true when you're done, across everything it touches.]
I want to make sure [what users should see or be able to do].
Make sure you check this by [how to prove it: a test that fails first, a run in the browser, sample inputs].
When it's done, [where to stop: open a pull request, show me on my local copy], and tell me everything you touched.

1. If the change is something you'd see on screen

   A browser it can drive

   Reading code can't tell it a button is hidden behind a menu. Clicking can.

   named in the talk

   Add to the prompt · ours

   ⧉Copy

   Open it in a browser, click through it like a user would, and screenshot what you see.

2. If someone reported a bug

   A failing test first

   A test that fails while the bug exists proves the bug is real, and proves it's gone when it passes.

   named in the talk

   Add to the prompt · ours

   ⧉Copy

   Before fixing, write an end-to-end test that fails because of this bug. Keep working until it passes.

3. If it touches accounts, payments or saved data

   A staging copy with fake data

   Realistic enough to test properly, with nothing real to break.

   named in the talk

   Add to the prompt · ours

   ⧉Copy

   Test against the staging copy with mock data. Never touch the live database.

4. If it spans more than one project

   A map of where things live

   Without it the agent can't tell what lives in which repo, and stops halfway.

   named in the talk

   Add to the prompt · ours

   ⧉Copy

   Read PROJECTS.md first. Open one pull request per repo and link them to each other.

5. If it has to install or run things

   Its own computer or sandbox

   It can run, install and break things without getting in your way.

   named in the talk

   Add to the prompt · ours

   ⧉Copy

   Work in the sandbox. Don't install anything on my machine.

6. If you don't know what it needs

   Ask it

   Theo on X, about GPT-6 Astra: the model is “surprisingly aware of what it can do”. So ask it.

   from his X post

   Add to the prompt · ours

   ⧉Copy

   What would you need to check your own work on this? Tell me before you start.

His conclusion: “The war on this part has already been won.” Writing the code is solved. The next job for agents is shrinking the other two numbers, so changes merge faster and ship fewer bugs. 13:39

1. 01Smaller, tidier changes

   “…tuning your agents to make better, more concise changes so that your reviews don't have to be as meticulous.”

   A change that touches four files gets read. A change that touches forty gets skimmed. Ask for the smallest change that reaches the goal, and a list of what moved.

   FakeNerd starter · lines for your CLAUDE.md or AGENTS.md

   ⧉Copy

   ## Changes
   - Make the smallest change that reaches the goal. Don't tidy nearby code unless I ask.
   - Don't add files, wrappers or tests that the goal doesn't need.
   - When you finish, list every file you changed and one line on why.

2. 02Agents that review with you

   “…training agents to do reviews for you, not to replace you but to augment you.”

   Let an agent do the first pass so your read starts from its notes. You still decide. It just stops you spending 30 minutes finding a typo.

   FakeNerd starter · a review prompt

   ⧉Copy

   Review this pull request before I do.
   1. Real bugs first: the line, what goes wrong, and how to reproduce it.
   2. Then anything risky to merge today, and why.
   3. Then what you'd test by hand.
   Skip style and naming. If you find nothing serious, say so in one line.

3. 03Ways for agents to test their own work

   “…building systems and code and tools and sandboxes that allow your agents to verify the changes and actually test things themselves.”

   The 20 minutes of testing per change only shrinks if the agent can do it. Give it a browser, a staging copy, test commands that work, and its own space to run.

   FakeNerd starter · ask it to set itself up

   ⧉Copy

   Look at how this project runs, tests and previews.
   What would you need to prove a change works without me checking by hand?
   Suggest the smallest setup that gets you there (a test command, a browser, sample data), and set up the first piece.

1. 01

   Pick one small, real problem

   A bug you can see, or a tiny feature. Something you could check yourself in two minutes. Open your agent in Claude Code, Codex, Cloudroom or bb.

2. 02

   Write the goal, not the file

   Say what should be true when it's done, in plain words. Leave out file names unless you're sure.

   The fill-in
3. 03

   Add one line on how to check

   A run in the browser is the easiest start. For a bug, ask for a test that fails first.

   What to give it
4. 04

   Say where to stop

   “Open a pull request” or “show me on my local copy”, and “don't deploy”. The agent edits code; nothing reaches your visitors until you publish.

5. 05

   Read it, then ask

   “What did you touch?” before you read the change. If the list is longer than you expected, ask why.

6. 06

   Next time, add a reviewer

   Ask it to have a subagent review the change before it hands back. Paste the review prompt below if you want a starting point.

   The review prompt

Here's a problem: [what's wrong, in the user's words].
Fix the whole problem, not just one file.
Before you change anything, find where it happens and show the problem with a test or a browser check.
Then fix it until that check passes, and click through it in a browser like a user would.
Don't deploy or publish anything. When you're done, open a pull request (or show me on my local copy) and tell me what you touched, how you checked it, and anything you weren't sure about.

• MEGA DEV, “Thinking Bigger: Theo Browne on Prompting End-to-End, Not Line-by-Line” (posted Aug 27, 2026; streamed live Aug 25). The ideas, the 15 steps, both prompts and the time numbers are Theo's. The steps, prompts and numbers are read off the whiteboard; quotes come from the captions. Where the spoken numbers differ from the board, the board is used and the page says so.
• Disclosure: the talk kicks off MEGA, a paid four-week course Theo teaches with Angie Jones, Kent C. Dodds and John Lindquist, starting Oct 26, 2026. Theo puts the price at $1,300 a seat and tells individuals not to pay for it themselves. Theo also makes T3 Code, which the talk doesn't mention. The video description promises an examples repo to MEGA newsletter subscribers; this page doesn't use it.
• The description also lists “experimenting past your limits” and keeping your setup ready for the next model. Neither is in this 15-minute cut, so neither is on the page.
• X posts are quoted with their dates and links. Two were posted in Spanish; the English is ours.
• The map's step notes, the “bigger prompt” run, the six examples (except the translation one), every fill-in and starter, the lines to paste in “What the agent needs”, the per-day math, the chapters and the takes are FakeNerd's. Not sponsored by anyone on this page.