Bruegel painted it in Antwerp, a booming port where traders spoke dozens of languages. In the Bible story, the builders share one language until they suddenly can't understand each other, and the tower is abandoned.
Look closely and it is already failing. The layers don't line up, and parts crumble while others still rise.
That is the risk with many agents: without shared context, skills and a coordinator, they build something that leans. The principles below keep everyone speaking one language.
We built Oncourse AI to 80k+ signups as a small, bootstrapped team, and built Caddie on the side. Neither would have been possible working the way most teams still work. These principles are how we did it.
Agents now write most of the code, so the slow part is your attention. These are the principles to spend it well.
Most teams still plan as if writing code were the slow part. Agents now write most of the code, so the slow part is the attention of the person in charge.
That shift is how a small, bootstrapped team runs Oncourse AI, and how one person can build a second product on the side. Caddie took 730 commits in 15 days, working alone with agents. Neither would have happened working the way most teams still do.
Agents leave you three jobs: starting work, checking it, and teaching them what good looks like. The principles are grouped by those jobs. The last one is about what to aim at once the three are running.
1.1
Start every task the second you know about it
Today Tasks go into a backlog and wait to be picked up.Instead Give each task to an agent the second it is written down.
1.2
Spend your time on triage and context, not on the task
Today You write a one-line ticket and explain it later, in standups and threads.Instead Decide what matters, then start each agent with the context it needs: who asked, why, and what done looks like.
1.3
Plan delivery dates, not start dates
Today Sprint planning decides what starts this week and what waits for the next one.Instead Keep the dates customers rely on, and start every planned task today.
1.4
Keep at least five agents running, day and night
Today Most people run one agent and watch it work.Instead Keep five or more running every hour, including while you sleep.
1.5
Give each project a coordinator agent
Today You hand out every task and chase every thread yourself.Instead Give each project a coordinator that watches its Slack channels, hands work to the right agent, and brings back one summary.
2.1
De-risk the merge button
Today Code review means reading every line before you press merge.Instead Make merging safe: confirm every finding in the code, and let tests and the build check every line.
2.2
Audit the app with personas, not checklists
Today QA runs a checklist for each feature.Instead Keep a shared library of personas built from real customers, and have agents test each feature as a different set of them.
2.3
Set up Kaizen routines that improve the work every day
Today Small improvements wait for a polish sprint that rarely comes.Instead Set up routines where agents improve the work every day, in small steps or large ones, and check that earlier fixes held.
3.1
Turn every good result into a skill
Today You make one good post, video or fix, and move on.Instead When an experiment works, turn how you made it into a skill, so agents can repeat that quality again and again.
3.2
Give every skill its references and the recipe behind them
Today A skill is a saved prompt, or a few good examples with nothing saying why they work.Instead Keep the reference examples that set the bar, add the steps and reasons that made them work, and test the skill on a fresh agent.
4.1
Give your agents MAD goals: measurable, absurd and daily
Today Roadmaps are sized for what a few people can do in a quarter.Instead Give agents goals a team of people would never attempt, like "make the app 10x faster."
4.2
Take ideas from three sources, not from the roadmap
Today Ideas come from the roadmap and from what the team finds interesting, and you learn whether anyone wants one after it ships.Instead Pick ideas that pull in a demo, meet a real need, or come from your own conviction. Build the ones that do all three first, and the rest for the fun of it.
4.3
Prototype live with agents, not in the background
Today You hand an idea to an agent, switch to something else, and come back an hour later to one attempt.Instead Sit with the agent: ask for ten approaches, ten versions of the best one, react to each, and iterate in minutes.
Start every task the second you know about it #
Give each task to an agent the second it is written down.
Today Tasks go into a backlog and wait to be picked up.
The problem A task that takes a day to do takes two weeks to ship, and most of that time is waiting.
Instead Give each task to an agent the second it is written down.
Follow one task from the day someone writes it down to the day it ships. In a typical team that plans in sprints, the work takes a day and the task takes two weeks. It waits in the backlog, then for planning, then for someone to be free.
An agent should make a first version in minutes. When the work takes minutes, the days a task spends waiting in a queue become almost all of its time. So start every task the second you know about it, even one that won't ship for weeks.
A meeting should start work, not add tasks
Meetings are where most tasks start. A typical call ends with a list of action items, and each one becomes another task in the queue. A meeting shouldn't add tasks. It should start the work. In Caddie, when a call ends, its Get it done card drafts each follow-up and hands it to an agent: the email, the Slack message, the PRD, even the payment. Anything sent in your name waits for your OK, and nothing lands on your to-do list.
The same rule applies to bugs. On the night of 22 October, an audit found that a deleted call note could come back after a workspace switch. An agent fixed it that night, and the fix shipped in version 0.5.48.
Measure time to happy, not time to close
- Minute 0 Ravi reports export is broken
- Minute 1 An agent turns Ravi into a persona
- Minute 3 Another agent fixes the export
- Minute 4 The persona tries the fix as Ravi
- 😊Minute 5 Ravi gets a reply, and it works
Measure time to happy: the minutes from a customer raising a problem to that customer being happy with the fix. Aim for five minutes. An agent fixes the problem, and a persona agent built from that customer checks the fix before anyone replies.
Support teams measure time to resolution, the hours from a ticket being opened to it being closed. Engineering teams measure cycle time. Both stop the clock when the team marks the work done, and the customer may still be stuck.
Measure something else instead: time to happy. The clock starts when a customer raises a problem, in a user interview, an email or a bug report. It stops when that customer is happy with the fix. Aim for five minutes.
A person can't fix and check a bug in five minutes, but agents working together can. One agent turns the customer into a persona: who they are, their device, and what they were trying to do. Another agent fixes the problem. Then the persona agent walks through the fix as that customer before anyone replies. If the persona wouldn't be happy, the fix isn't done.
The same goes for planned work. Say on Monday you plan an export feature that is due in three weeks. An agent drafts it that afternoon. The draft shows the hard part is the file format, not the screen, so the plan changes on day one instead of in week three.
Spend your time on triage and context, not on the task #
Decide what matters, then start each agent with the context it needs: who asked, why, and what done looks like.
Today You write a one-line ticket and explain it later, in standups and threads.
The problem An agent can't ask around the office. A one-line task gets a confident first version of the wrong thing.
Instead Decide what matters, then start each agent with the context it needs: who asked, why, and what done looks like.
When agents do the work, your time moves to the two minutes before they start. Those two minutes decide whether the first version ships or gets thrown away.
Spend them on triage first. Is this worth doing at all? How urgent is it? Which agent is set up for it? Most tasks die here, and they should.
Then add the context a new teammate would need. Who asked, and what were they trying to do? Link the Slack thread, the call or the customer's email. Say what done looks like, and what the agent must not touch. An agent that starts with the full picture needs one review. An agent that starts with one line needs five.
Plan delivery dates, not start dates #
Keep the dates customers rely on, and start every planned task today.
Today Sprint planning decides what starts this week and what waits for the next one.
The problem Start dates ration people's time, and agents don't need rationing.
Instead Keep the dates customers rely on, and start every planned task today.
Sprint planning sets two dates for each task: when work starts and when it ships. Start dates exist because a person can only hold a few tasks at once.
Agents don't have that limit. Keep the delivery dates, because customers and teammates rely on them. Drop the start dates. Every task in the weekly plan gets an agent the day it enters the plan.
By the next planning meeting, every task has a draft, a prototype or a failed attempt. The meeting stops estimating work and starts judging it. A failed attempt is useful too, because it shows what the task really needs.
In Caddie you hand a task to an agent from your task list, and the planner keeps tasks an agent holds out of your day.
Keep at least five agents running, day and night #
Keep five or more running every hour, including while you sleep.
Today Most people run one agent and watch it work.
The problem Watching makes you the bottleneck, and the agent stops when you log off.
Instead Keep five or more running every hour, including while you sleep.
With one agent, you write a prompt and watch it work. You have swapped waiting for a person for waiting for a machine.
With five or more, something is always finished. While one agent works, review what another made. With fewer than five, you end up waiting. The upper limit is how much you can check well, which is principle 2.1.
They shouldn't stop when you do. Before you sleep, start the long jobs, like audits and research. By morning, a night's work should be waiting for review. Many of Caddie's audits ran overnight.
Caddie's Agents inbox lists every agent by who needs you, including Caddie's own agents, T3 Code threads, and Claude Code and Codex sessions. An agent's question reaches you in the Mac's notch or on your iPhone, so no agent sits idle waiting for an answer.
Give each project a coordinator agent #
Give each project a coordinator that watches its Slack channels, hands work to the right agent, and brings back one summary.
Today You hand out every task and chase every thread yourself.
The problem With five or more agents, managing them is a full-time job, and requests in Slack wait until you look.
Instead Give each project a coordinator that watches its Slack channels, hands work to the right agent, and brings back one summary.
Five agents running day and night need managing: who works on what, what is stuck, what is done. Do that yourself and you are the bottleneck again.
So give the job to an agent, one per project. Oncourse has its coordinator and Caddie has another, each with its own channels, agents and memory. A coordinator reads each request and hands it to the agent best set up for it. A follow-up goes to the agent already on that topic instead of starting a new one. When the work is back, you get one short summary of what each agent did and what needs you.
Point it at the places requests arrive. It watches Slack continuously, so when a teammate asks for something, the work has started before you read the message. It never sends or posts as you without asking first.
In Caddie, every account comes with a Coordinator, and you can make one for each project. Slack messages and meeting follow-ups go to it, and it hands work to your other agents and T3 Code threads.
De-risk the merge button #
Make merging safe: confirm every finding in the code, and let tests and the build check every line.
Today Code review means reading every line before you press merge.
The problem Agents write more code than anyone can read, so merge becomes the riskiest button you press.
Instead Make merging safe: confirm every finding in the code, and let tests and the build check every line.
Agents write more code than anyone can read line by line. So spend your reading where it matters most, on what the agents claim.
When an agent reports a bug, confirm it in the code before anyone fixes it. Agents report wrong findings in the same confident tone as right ones, and a fix for a bug that doesn't exist is a new bug.
Say an agent reports that checkout charges tax twice. You open the code and see it was reading an old test file. If another agent had "fixed" it, a working checkout would now be broken.
Let machines check the rest. Tests, type checks and the build run on every change. When several agents finish, confirm each change is still there, because a later agent can quietly undo an earlier one. And decide yourself anything that reaches the outside world, like a default, a permission or a release.
Audit the app with personas, not checklists #
Keep a shared library of personas built from real customers, and have agents test each feature as a different set of them.
Today QA runs a checklist for each feature.
The problem Checklists only find what you imagined, and the worst bugs sit between features.
Instead Keep a shared library of personas built from real customers, and have agents test each feature as a different set of them.
Think of a call recorded on the Mac, a workspace switch, then the note opened on a phone. No checklist for meetings or for workspaces covers that walk.
So give the audit agents personas. A persona is a specific person with a reason to open the app, a device and settings, permissions they deny, and 8 to 12 steps they take in order, including quitting and reopening. The agents trace the code at each step and ask what this person would see.
Pick different testers for each feature. Before a feature ships, choose the four or five personas it affects most. A new checkout goes to someone on a slow phone and a parent paying for their child. Offline mode goes to someone on a patchy connection and someone with low battery. Add new variations in every audit, so each one tries routes no earlier audit tried. We have used more than 120.
Build personas from real customers, in one shared place
Keep a library of 20 to 30 personas, built from real customers. Build them from what people actually say: user interviews, support emails, and Reddit threads where people describe their problems in their own words.
Then keep them in one shared place, so the whole team and every agent works from the same people. The library grows with research: every interview or support thread either adds a persona or sharpens one. In Caddie, that place is a team workspace.
Set up Kaizen routines that improve the work every day #
Set up routines where agents improve the work every day, in small steps or large ones, and check that earlier fixes held.
Today Small improvements wait for a polish sprint that rarely comes.
The problem They pile up, and old fixes quietly break again.
Instead Set up routines where agents improve the work every day, in small steps or large ones, and check that earlier fixes held.
Kaizen is the practice of continuous improvement that Toyota made famous. Many small improvements, made all the time, by the people doing the work. Agents make it cheap enough to do every day.
Set it up as a routine, a scheduled job an agent runs on its own. Each run looks over recent work, improves what it finds, and checks that the last run's fixes held. Point routines at anything that should keep getting better: the product, the onboarding emails, the help docs, the sales deck.
Don't stop at small fixes. Give a routine ambitious goals: find hundreds of bugs, make the app faster, cut its load time in half. Have it test each change from the point of view of hundreds of different personas, such as a student in their first year of study and one in their final year, so every improvement holds for every kind of user.
The check on earlier fixes is the step people skip. Without it, a fix can quietly break a week later. With it, a fix that breaks is caught the next day.
In Caddie, Kaizen is the first routine the Routines page suggests, with an agent of its own.
Turn every good result into a skill #
When an experiment works, turn how you made it into a skill, so agents can repeat that quality again and again.
Today You make one good post, video or fix, and move on.
The problem The next one starts from scratch, and its quality depends on luck.
Instead When an experiment works, turn how you made it into a skill, so agents can repeat that quality again and again.
A skill is a file of instructions an agent reads before a kind of work. It works like a factory. One good skill improves every output that comes after it.
Say one social media video does well. Most teams celebrate and move on. Instead, write down exactly how it was made: the hook, the pacing, the visual style and the sound. Now any agent can make videos of that quality on any topic.
At Oncourse we did this with explainer videos. When one video in the style of Vox worked, we turned the process into a Vox video skill. It covers the paper textures, the type, the 12 frames a second and the documentary sound, so every new video starts at the quality of the best one.
Do the same with feedback. If you correct an agent in chat, only that agent learns it. Add the correction to the skill instead, and every agent after it gets it right the first time.
In Caddie, an agent can write a skill itself once it has done a job well, so you don't have to start from a blank page.
Give every skill its references and the recipe behind them #
Keep the reference examples that set the bar, add the steps and reasons that made them work, and test the skill on a fresh agent.
Today A skill is a saved prompt, or a few good examples with nothing saying why they work.
The problem An agent copies the example's surface and misses why it worked, so the second result is a weaker copy of the first.
Instead Keep the reference examples that set the bar, add the steps and reasons that made them work, and test the skill on a fresh agent.
Start from references. The result you liked, and the work you admire from others, show an agent the bar better than any description. Keep them in the skill. Then add the recipe on top: how that result was made and why it worked. The Vox video skill links its best videos, and also says to start from a real story, put one idea in each sentence and one picture behind each sentence, and check every frame before rendering.
Then test it the way you'd test code. Give the skill to a fresh agent with no other context and a new topic. If the result isn't as good as the original, the skill is missing a step. Find it and write it down.
Five things make a skill hold up.
- References. The examples that set the bar, yours and others', with a line on what each one gets right.
- Steps in order. The process, from first decision to final check, so an agent can't skip to the end.
- The reason for each step. An agent that knows why a rule exists applies it to cases the rule never named.
- A lessons log. Every critique you give, dated, newest first. The skill gets better every time something goes wrong.
- Pointers, not copies. Link the style guide and the template rather than pasting them in, so the skill never goes stale.
Keep one skill per kind of work: one for explainer videos, one for blog writing, one for audits. A skill that tries to cover everything gets vague, and vague instructions get average results.
Caddie's agents can save a skill themselves once they've learned a job, and every agent reads your skills before it starts.
Give your agents MAD goals: measurable, absurd and daily #
Give agents goals a team of people would never attempt, like "make the app 10x faster."
Today Roadmaps are sized for what a few people can do in a quarter.
The problem With agents, that roadmap leaves most of your capacity idle.
Instead Give agents goals a team of people would never attempt, like "make the app 10x faster."
Sooner or later you'll ask what the agents should do next. If you can't answer, your goals are too small.
So make every goal MAD. Measurable, so an agent can tell when it has won. Absurd, so a team of people would never try it. Daily, so agents take a fresh run at it every night. "Make the app 10x faster" is MAD. "Improve performance" is not.
Your roadmap was sized for what a few people could do in a quarter. You now have more workers than ideas. So set goals a team of people would never attempt. Make it ten times faster. Make it ten times more accurate.
Give each goal a number an agent can measure, like seconds or error rate. Then agents can try ten approaches overnight, and you only check the attempts that beat the number, and confirm that they really did. Most nights none do. The night one does can change what your product is.
Take learning, the field we care about most. We haven't done this yet, but it is where we'd point every spare agent.
- Make answers more accurate.
- Find better ways to track how a student is progressing.
- Calibrate score predictions, so a predicted 70% means 70% on the day.
- Build synthetic students, so every new method is tested daily before a real student sees it.
- With enough resources, read the research on brain stimulation for learning and design experiments from it.
None of these can ever be finished, so the agents never run out of work.
Take ideas from three sources, not from the roadmap #
Pick ideas that pull in a demo, meet a real need, or come from your own conviction. Build the ones that do all three first, and the rest for the fun of it.
Today Ideas come from the roadmap and from what the team finds interesting, and you learn whether anyone wants one after it ships.
The problem With agents, building is cheap, so you can build the wrong thing faster than ever.
Instead Pick ideas that pull in a demo, meet a real need, or come from your own conviction. Build the ones that do all three first, and the rest for the fun of it.
When building is cheap, choosing what to build is the whole game. Good ideas come from three places, and each answers a different question.
Demand: does the demo pull? Build around what can be shown well. Make the 15-second video before the feature and post it where your users already are, on TikTok, Instagram or YouTube Shorts. Saves, comments asking where to get it, and waitlist sign-ups are the signal.
Need: what job does it do? Talk to the people you're building for, with a prototype in the room. Don't ask what they want. Show them something an agent built that morning, watch where they get stuck, and change it while they're still on the call.
Conviction: what should exist? Some ideas nobody asks for and no test can prove yet. If you believe the world should have it, build it anyway, and let demand and need shape it rather than decide it.
Read demand as action, not views. A video with fewer views and many comments asking how to get it beats a viral one nobody acts on. The words people use in those comments become the feature's name and its onboarding.
Treat user research as live iteration, the same way as principle 4.3. Agents make a working prototype faster than you can schedule the call, so every interview can test a real thing instead of a question. By the end of a week of calls the prototype has been changed by everyone who used it.
Each source alone can mislead. Demand without need is a fad. Need without demand is a product nobody hears about. Conviction without either is a bet. Build where all three meet first. But building is cheap now, so build the edges too, for the fun of it. Some of the best ideas start as a toy only you believed in. The next post in this series covers the first one in full: working backwards from distribution.
Prototype live with agents, not in the background #
Sit with the agent: ask for ten approaches, ten versions of the best one, react to each, and iterate in minutes.
Today You hand an idea to an agent, switch to something else, and come back an hour later to one attempt.
The problem While you're exploring, the slow part is your taste, and one guess an hour gives it almost nothing to react to.
Instead Sit with the agent: ask for ten approaches, ten versions of the best one, react to each, and iterate in minutes.
Running agents in the background is right once you know what you want. It is wrong while you're still finding out. Exploring should be a conversation, and you can't have a conversation with someone who answers once an hour.
So when you're shaping an idea, stay in the loop. Ask for ten different approaches side by side. Pick the one that's closest, and ask for ten versions of it. React to each in a sentence, and go again. Three rounds take half an hour and get further than a week of handing work off.
These are the habits that make live iteration work. They come from how we actually work with agents.
- Ask for options, never one answer. Two motions to compare, ten layouts, four titles. You can't judge one version, but you can always pick between two.
- Look at the real thing every round. Open it in the browser, on the phone, at full size. A description of a design hides what a screenshot shows.
- React fast and specifically. "Too much text", "the label looks wrong", "this doesn't say anything". Point at the exact part, ideally with a screenshot.
- Say why. "Too much text, I want to understand it at a glance" teaches the agent your taste. "Change it" teaches nothing.
- Keep what works and change one thing. Each round starts from the version you picked, so good parts don't get lost.
When a round lands, write down why it worked as a skill (principle 3.2). When the direction is settled, hand the build to agents in the background and go back to running five of them.
There are enough problems in the world to be solved. It's time we were ambitious enough to take them on.
Run your agents from the same place as your work #
Caddie puts your agents, their questions and your routines next to your notes, tasks and calendar. It uses the Claude Code or Codex you already pay for.