---
title: "We're system designers now"
description: "Angie Jones on the MEGA podcast: typing code may be solved, and the job that remains is designing the system agents can run without you in the middle."
author: "angie"
author_name: "Angie Jones"
tags: ["agents","product","workflows"]
published_at: "2026-09-24T00:00:00.000Z"
canonical: "https://mega.dev/system-designers-now"
---
You can hire the best programmer in the world. Hide the business from them and they still cannot do the job. Angie Jones's conclusion, on the MEGA podcast with Joel Hooks (September 24), is that the typing was never the job that mattered. Users care whether the software does what they expect. The work left is designing the system that gets them there.
I see us now as basically system designers. We are designing some system that we want and then giving it to one or more agents to go bang out.
## More agents is not more time
Angie led AI enablement at Block, about 3,500 engineers, and pushed the org to the point where people were orchestrating several agents at once. It was tiring. Five threads is a modest number. You tell one to go, context-switch to the next, and come back to a result you now have to trust. Agents monitoring agents monitoring agents, and at the end it still lands on you.
She does not think this gives the time back. Joel calls it a slot machine: one more, one more. The leverage is not the count of windows. It is whether the system can finish a piece of work before it needs you.
When she does hand work off, the instruction is specific. Quality is still her problem. Spin up as many adversarial agents as the review needs, and do not come back until it is done and done well. She is not reading an agent-written spec for its own sake. She is deciding whether the outcome is acceptable.
## Context the model will never have
A frontier model can be excellent at coding and still have no guarantee it will be careful. Angie had just written about reliable agent systems when they recorded. The carefulness has to live in the system, because it does not live reliably in the model.
That means context files, rules, and skills for the facts the model cannot invent: how this company refunds, which service owns the bug, what "done" means here. It also means access, with a limit. At Block they built hundreds of MCP servers specific to the business. An agent that can call all of them is not an autonomous agent. It is an unaudited one.
Shared memory is the unsolved piece. A new agent that has to rediscover the company on every task is, in her words, a really dumb design. They are solving it with markdown for now. She expects that to change, and she expects some of today's scaffolding to come back off.
Richard Sutton's bitter lesson, as Angie applies it: models keep getting better, and the structure we wrapped around the last model often makes the next one worse. Strip scaffolding when it starts constraining a stronger model. Keep the context the model still cannot know.
## Green tests can be lies
If the same agent writes the code and then "adds some tests," those tests are already biased by the decisions it just made. Angie says they will be shallow. They may be lies. Green is not the same as usable, and that is more true now than it was when a person was the one cutting corners in a hurry.
The counterweight she names is old. TDD is back: have the agent write the test first, then the code that makes it pass. Or have a different pass, with different context, try to break what the first pass built. The author of the change is the wrong only reviewer.
Slop, in the way she and Joel talk about it, is a choice. Craft is a choice. The lever is not a meaner prompt. It is a system that will not accept the shallow test, the missing context, or the change nobody can explain to a user.
## A world model, and a first day
One approach she describes from Block is a world model of the company: the services that exist, where the code lives. Block was formed from separate companies, so Cash App and the rest were not one tidy repo. An agent without that map guesses. An agent with it can be pointed at the right place.
She also ran a six-month pilot hiring early-career people who were already strong with coding agents. The interview checked that they were not blindly accepting whatever the agent said. On the first day, in person, customers came in and described what was frustrating about the product. Those new hires had never seen the codebase. They got access, an agent, and the customer's problem.
That only works if the system is legible. A first-day engineer, human or agent, needs the map, the policy, and a way to check the result. Senior, in the version of the job she is describing, is no longer "I write the code." It is "I can design the system, and I can tell when the result is wrong."
List the steps in your current agent loop where a person still carries context or a permission between two tools. That list is the design brief. Pick one step and move the context into a file or a tool the next agent can read without you.
## Not from the phone, yet
Joel asks whether she runs this from her phone. Not beyond chat. She has not gotten to multiple agents from a phone, and she is not sure she wants to. The interface she laughed about, a Stardew Valley face for a swarm of agents, did not last. People saw it and found it ridiculous. She does not think the current orchestration UI is the final form either.
The durable part is the role. Design the system. Give it to agents. Stay responsible for whether the user got what they came for.