---
title: "It's time: the work changed"
description: "The four short opening tutorials from MEGA's August 25 live: Angie, John, Kent, and Theo on autonomy, images, primitives, and prompting the whole outcome."
tags: ["agents","product","workflows"]
published_at: "2026-08-27T00:00:00.000Z"
canonical: "https://mega.dev/the-work-changed"
---
MEGA opened with one live event, August 25, called "It's Time: The Work Changed." The four instructors each recorded a short tutorial for it. They shipped over the next few days, about fifteen minutes each. This Drop is that set, in one place. Four arguments, one program.
## Angie Jones: the human is not the integration layer
Angie Jones starts from a double refund. A customer cancels an order. The system refunds them twice. The company loses money every time it happens.
An incident system starts an agent. The repo already has guidance: how it is organized, where cancellation lives, which tests to run, and an incident-response skill for how to investigate, add a regression test, and verify. The agent finds a race. Two overlapping requests both pass the check and both issue a refund. It adds a failing test, claims the event before the refund, and goes green. The fix ships.
Then it happens again. A person is paged, downloads a production trace, and hands it back to an agent. The two deliveries landed on two replicas. Each replica claimed the event in its own memory. The fix was locally correct and globally wrong.
Angie's question is why a person had to carry that trace. If the human is the integration layer, the system is not autonomous. The missing fact, that this service runs as more than one replica, belongs in the repo's agent guidance. The trace itself belongs behind a tool. At Block she had seen hundreds of MCP servers built for the business. Here, a production-operations server can return the incident, a sanitized trace, the refund policy, and an independent replay. An open-source agent gateway sits in front and allows only those four tools. The raw trace stays blocked. Closing the incident stays with the incident system, after the service has recovered.
Same agent. Same model. The second attempt fixes the shared claim because the system finally had context, access, feedback, and control. Her maturity model from Block's engineering org says tool adoption is the first measurement and not the one that moves the needle. System readiness is.
Find the step where a person still carries context or a permission between two systems. That is the seam to close first.
## John Lindquist: show the change, do not describe it
John Lindquist's loop starts with a screenshot. Draw an arrow at the button you dislike. Paste it. Say "this." The model finds the control in a storybook of many apps because the arrow is the specification. A second color means a second instruction: move this nav item to where the green arrow points. When it moves the whole nav, that was his wording, and a follow-up with the same picture fixes it.
He wants the capture to be a mouse button, not a ritual. One button drags a region and lands in arrow mode. Another copies to the clipboard. The history of those pictures is easier to search than a history of prompts. You can see what you asked for last week.
The same pictures generate the next pictures. Codex and Gemini can take "this button, as bread" and return an image. Claude, in his telling, does not. He batches models against one reference, keeps the results, and treats that gallery as the studio. Once a direction holds, a pixel-level recreation becomes a storybook of sites that resize, built from the images in an afternoon. He also generates fonts as derivatives of open-source faces, then expects the next step to be a font pulled back out of an image.
The iteration trick he is proudest of is not a faster compiler. GPUI, the Rust UI framework he was designing in, had nothing like browser devtools. He stopped waiting on Rust compiles and built a converter from web storybooks to GPUI components. Design where the loop is seconds. Let the model port it. Build the web reference first, then translate.
The last move is video. Record the screen, draw arrows while you talk, and run a tool that transcribes the audio, grabs frames at the moments you said "this" or "here," and turns the pair into a prompt. You did not write the spec. You pointed at it.
## Kent C. Dodds: a tight spec is a bad sign
Kent C. Dodds opens with a prompt you can say in one breath. Connect a Coda account to Discord so people get a role and can log in with Discord. Talk it through. Then tell the agent to do whatever it can on its own, and leave the manual steps for the morning.
Without primitives, that prompt produces a mess: duplicated work, invented systems, a diff you do not want. With primitives, the same sentence is a job. His thesis is the title. The tighter you have to specify, the worse or less findable your primitives are. A good playground lets you give a job, not a massive spec.
A primitive is the smallest unit of meaning the system exposes. A named capability an agent can compose without reimplementing. Not every function. Not four hundred lines of agent instructions. If the agent has to reinvent it, it was not a primitive it could use. React is one. A component on top of React is another. The data model, the authorization rules, and the tools the agent can call are others. [Kody](https://github.com/kentcdodds/kody) is how he gives an agent those tools, and how the agent can add its own.
The test: can a junior agent take a one-sentence job and compose what you already have? If it invents a new primitive, the old one is missing, hidden, or worse than starting over. After the run, look at what it reused. That is the report card.
He treats the set as a garden. Add on purpose. Talk a new primitive out before an eager model builds it. He floated one-off event subscriptions that were not packages, told the model not to do it yet, and deferred the idea. Prune on purpose. He pointed an agent at production data and asked whether Kody's global values store could die in favor of package storage, memory, and repos. It could. The migration he got back lasted a month, so existing data had somewhere to go. He dropped a persistent-service primitive the same way, after asking what it cost. A primitive that can drain the wallet is not a feature.
Three failure modes follow. The agent cannot find it: fix the routing, starting from the root agent file. The agent refuses it: the primitive is too rigid, or still hidden, so ask why it was not used. You cannot tell what the change did to the system: every pull request should say whether it reused, expanded, or added a primitive, and an architecture decision should say what you are not doing and why.
Give an agent a one-sentence job in the repo you actually ship. If it composes primitives you recognize, you are in decent shape. If it invents a parallel system, the playground is the work.
## Theo Browne: prompt the outcome, not the file
Theo Browne draws the cycle he lived at Twitch and Amazon. A user has a problem. A product manager hears it. A designer specs the interface. A tech lead turns that into tickets. An engineer writes the code. Another engineer reviews. The product manager disagrees. The review is stale. Days disappear into the gaps, and a hundred-line fix takes weeks when the two engineers are in different time zones.
Most teams he watches use AI in one place: the engineer typing, and sometimes a reviewer bot. The gaps between steps are still human. The agent is an alternative to the keyboard. It is not yet a coworker that owns the process until it has to tap out.
Prompting bigger, in his terms, is the opposite of "update `app.tsx` to use the new localization primitives." That prompt names a file and a mechanism. The larger one states the goal: the same primitives everywhere a user sees a certain set of words, checked in more than one language, consistent across every surface that matters. He would describe a ticket to a coworker as a problem and a rough shape of a solution, not as a list of files. Talk to the agent the same way. Give it a way to know it finished.
He is not saying to delete human review. He is saying the small bugs that used to bounce for a week should be caught before the pull request reaches you. Tools, a browser, a staging environment with realistic mocked data, and a layout of the repos so one prompt can open linked pull requests across them.
The warning is the slopocalypse. Agents make writing code and filing pull requests too easy. A ticket that took three to six hours to implement, then twenty minutes to review and fifteen to verify, does not get cheaper in the way people hope. The three hours collapse. The review and the verification do not, and now there are thirty pull requests instead of three. The war on typing is already won. The work is review that merges faster, and verification that ships fewer bugs.
They're thinking of it as an alternative to their keyboard. They're not letting the agent own the process until it is ready to tap out.
## One opening
Angie's agent fails until the system can see production. John's spec is a picture. Kent's spec gets shorter as the primitives get better. Theo's spec gets larger in scope and more specific about the outcome. The four tutorials are the same argument from four seats: the model is not the bottleneck. The system you hand it is.