# Running coding agents like engineering orgs What happened when I organized Claude Code agents the way we used to organize hundreds of engineers Canonical: https://agentrun.ai/blog/running-coding-agents-like-engineering-orgs Published: 2026-10-29T19:40:33.000Z Author: Miguel Rios Berrios _What happened when I organized Claude Code agents the way we used to organize hundreds of engineers_ Before I started Parcha I was a Senior Director of Engineering at Brex. The organization I led grew to more than 200 engineers, data scientists and managers, and it was organized the way most engineering orgs are. A couple of principal engineers worked with me and partnered with tech leads across the org. On the people side there were directors, senior engineering managers and engineering managers. On the technical side there were layers of tech leads: a principal engineer as the tech lead for a whole org, a staff or senior staff engineer for a large surface area, and a tech lead or tech lead manager running a project with the ICs doing the technical work. ![Full Floor 8 dashboard arranges agent teams, review rooms and shared meeting areas on an office floor plan.](/blog/imported-writing/running-coding-agents-like-engineering-orgs/7d94c4040e678f65.png) For the last five weeks, while we built AgentRun (our meta harness and self-learning agent platform), I tried an experiment: I organized my agents the same way. This post is about how that went, with numbers, and what the agents did to each other along the way. ## How I set it up There is one overall tech lead that oversees the whole project. It talks to tech leads that each own a feature, a package or a large enough surface area. Each tech lead plans the work and hands it to a small team of engineers: a staff engineer on Opus 5.5, a senior engineer on Sonnet 5.5, or a junior engineer on Haiku 5.5 for the smaller mechanical changes. Off to the side there's a team that looks after our dev box when the disk fills up or the machine is under too much load, and, as it turned out, a staff reviewer that nobody asked for (more on that below). ![Agent organization chart places the author above a staff reviewer, an overall tech lead, box operations, tech leads and engineers.](/blog/imported-writing/running-coding-agents-like-engineering-orgs/2e9542a9cdf50c1b.png) I also put some structure on how I work with them. I do pretty much everything through the overall tech lead. It decides how to talk to the other tech leads, to engineers directly and to other teams. It can approve some things under my authority (small PRs that went through Greptile and were deemed low risk) and it escalates to me when it needs to. When we start a new project we start a new tech lead, on Opus 5.5 at high effort. I plan with that agent directly: we write specs, explore the codebase and work out what needs to be done. Then I say something like this: **PROMPT · ME TO A NEW TECH LEAD** That's it. Questions bubble up to the tech lead and, if it can't answer them, to me. For the most part the tech lead had the context to answer them. ## What happened _I was not expecting how ready Claude Code was for this._ Once I turned on the permissions for agents to talk to each other without my approval, they just did, and in a very natural way. Team members talked to each other. They escalated to their tech lead. The tech lead escalated to me only when it needed to. They did that around the clock, and for the most part they only stopped when Claude Code blocked a command or an API stream disconnected. Here are the numbers after five weeks (September 23 to October 28): Here's who talked to whom. Each line is a channel between two agents (or me), and the thicker it is, the more messages went over it. The glow around each tech lead is the traffic that never left its team. [Explore The org, replayed](/blog/imported-writing/running-coding-agents-like-engineering-orgs/visualizations/org-replay.html) The overall tech lead is the hub. About 4,000 messages went between it and the tech leads, and most of what reached me came through it (about 1,150 of the roughly 1,900 messages and questions between me and the org). About half the traffic between agents stayed inside a team. The second hub is R11, with about 1,600 messages to and from ten teams. More on R11 later. A month ago I posted three charts: my share of the messages in my Claude sessions, PRs per week, and PRs per prompt. Here they are again, extended to this week. ![Weekly chart of the author’s share of Claude messages, comparing the summer median with the lower autumn values.](/blog/imported-writing/running-coding-agents-like-engineering-orgs/37df3b12d9b45677.jpg) Over the summer, about one in every 27 messages in my sessions was mine. Once the tech leads had teams, it was one in 150. I typed about as much as before, around 500 messages a week. Each message just did a lot more: about 275 agent turns in October, up from 37 over the summer. ![Weekly merged pull requests rise above the summer median after the agent organization is introduced.](/blog/imported-writing/running-coding-agents-like-engineering-orgs/ee0f6898a6be9884.jpg) ![Weekly pull requests per Claude prompt increase in the autumn compared with the summer median.](/blog/imported-writing/running-coding-agents-like-engineering-orgs/79b053a8b81442dd.jpg) PRs per message I typed went from about 0.3 over the summer to about 1.4 in October. The PRs didn't get smaller to get there; the median merged PR was about 200 lines before and after. ## This repo against parcha The fairer test is to compare repos. This repo (the AgentRun harness) is where I ran the org experiment, and it's just me and the org. Our main repo, parcha, has six contributors who work with their coding agents directly, the way we always have. ![Comparison of pull requests per typed message, messages per merged pull request, weekly merges and active agents across repositories and periods.](/blog/imported-writing/running-coding-agents-like-engineering-orgs/4fa97960b1f64273.jpg) Over the summer both repos looked the same, about one merged PR for every five or six messages I typed. With the org, this repo went to more than one merged PR per message, about six times more. Parcha went from 0.17 to 0.32 in October, partly because I tried a small version of the same thing there with Codex (a lead and four lanes). The org needed less than one message from me per merged PR; parcha still needed about three. The harder question is whether the code was any good. Greptile reviews every PR in both repos (parcha also gets reviews from Devin) and gives it a confidence score out of 5, so I pulled its score for all 3,300 merged PRs since July: the first score it gave, and the score it ended on. On the first review, the org's PRs look like parcha's in the same weeks. Both averaged 4.0 out of 5, about 31% of both scored 5/5, and both had about one P1 per PR (0.98 here, 1.04 on parcha). Fewer of the org's PRs started at 3/5 or worse (18% against 22%). Both repos scored a little lower in October than over the summer, by about the same amount, which looks like Greptile getting stricter rather than either of us getting worse. ![Review-quality charts compare first-review scores, the share merged at 5/5 and later improvement after a low score.](/blog/imported-writing/running-coding-agents-like-engineering-orgs/1be465d30cd81433.jpg) The gap is at the end. Parcha merged 64% of its PRs at 5/5; the org merged 55%, down from 75% over the summer. The org did fix and resolve the P1s (the merge queue won't take a PR with an open thread), but when a PR started at 3/5 or worse it asked Greptile to look again only 72% of the time, against 89% on parcha, so more of them merged on a fix Greptile never scored again.The merge queue ejected about twice as many PRs here as on parcha (failed checks, merge conflicts and PRs a lane pulled out itself, in roughly equal parts), and follow-up fixes went up a little. One caveat: parcha is a production codebase we started in 2023, and this one is five weeks old. ## Reviews Every PR got two reviews from something other than its author: Greptile, which reads the diff, and R11, which runs it. R11 started to show the behavior of a complex reviewer. It writes a test that fails before the change, then breaks the code on purpose, one small bug at a time (mutants), and checks that the PR's tests notice. Of the 446 bugs it planted and reported on, 39 slipped through, and each one sent a PR back. On one browser PR, R11 removed a single safety check and every test still passed; without that check, a cloud browser run could read and save the sign-ins in the shared local Chrome profile. The author added one test, and R11 confirmed it now failed whenever the check was gone. Greptile left about two comments per merged PR, and about 1,475 of those were P1 bugs that got fixed before the merge. The authors answered 95% of its comments. Most answers were "Fixed in" a commit with a test, but about one in twenty declined, with reasons, and when Greptile came back on a decline it withdrew its own finding about three times out of four. ![Example dialogue in which an author agent challenges Greptile findings with evidence and Greptile withdraws a finding.](/blog/imported-writing/running-coding-agents-like-engineering-orgs/7b5e82e0885a9cfe.png) Each reviewer caught what the other missed. On one PR Greptile found six real problems R11 had passed. On another, R11 withdrew its own PASS because "my gate ran 16 of the 39 example files," the same ones the author had run, so it shared the author's blind spot. ## My day with the org This didn't run on its own. What changed is how I was involved. Before, I'd talk to several agents at once all day and jump between them. With the org I mostly talked to one, the overall tech lead, a few times a day in short, dense sessions: reviewing results, steering the work and planning what came next. In between, I worked on our production codebase and did all the other things founders do. The two check-ins that never changed were at night and in the morning. Somewhere between 10 and 11pm I'd tell the overall tech lead I was going to sleep, and around 7am I'd come back and ask where we were. I sent almost the same two messages every day: ![Overnight conversation: the author asks agents to keep unblocking work, then returns to a summary of pending approvals.](/blog/imported-writing/running-coding-agents-like-engineering-orgs/5ef67c2a116e7e42.jpg) At night the overall tech lead turned my message into orders for every lane, checked that nobody had a question waiting on me, and signed off ("All 11 leads have tonight's orders, and none had a question open. Good night."). Anything that needed me went into a file called MORNING-STACK.md, one line per ask. In the morning I got the recap: what happened overnight, what was blocked on me, and a "What went wrong" section (once it told me the API tech lead had "missed demo day by not checking on its video lane"). It ended with one line I could paste to approve everything that was ready. I pasted 169 of those. At the start of a project, and again at the end of the week, I had each team make a demo video for me, the same way we do Demo Hour with our human team. On October 15 I asked the overall tech lead for a board: every tech lead's status, what was done, in progress, to do, blocked and by whom, and waiting on my feedback. It had one up the same day, a row per lane and a column per state, filled in from a small file each tech lead kept current. ![Table of agent teams and their time spent waiting on the author, other engineers, blocks, work in progress and completed work.](/blog/imported-writing/running-coding-agents-like-engineering-orgs/512ca8653cf2039e.png) It's the same board every engineering org runs on, in Jira or Linear or Notion. The column I cared about was "waiting on me". The difference is that every card on it was written by an agent, and it was only as good as what the lanes reported. One night it said 17 things in the browser lane were waiting on me, and the browser tech lead said there were none. This morning's answer was the most accurate one: "almost everything is waiting on your approvals." That's the bottleneck in one line. A PR waited a median of 4.5 hours for my first approval and merged 23 minutes after my last one. ## They got together Some of what they did together was really impressive. The best night of the experiment was the agent store. At about 10:45pm on October 22 I asked for one of our packages to become an agent store, a place to keep many agents and every version of each, in time for the next day's release. Then I went to sleep. The team that owned that package was down; its agent had frozen. The overall tech lead split the job into three pieces, gave each one an owner, and told everyone "nobody stops for it." The DSL tech lead paired two engineers from different teams on the seam between their pieces: **PROMPT · DSL TECH LEAD TO TWO ENGINEERS** Ten minutes later the owner came back, took the spec over, and made it simpler (one SQLite file instead of two copies kept in sync). By 1:18am three PRs were open, and by morning our two reviewers had passed all three. In the morning I approved them, and that's when it got impressive. The web tech lead worked out that merging the three PRs one at a time would miss the release, and proposed merging them as one. The disk tech lead checked the math. Before anyone pushed, R11 built on its own what the combined PR should look like. I said yes, the web tech lead pushed, and the two matched byte for byte. That whole exchange took 86 seconds. Then the disk tech lead froze the repo for the release, and the release was tagged at 10:46am, 12 hours after I asked. ![Timestamped conversation among tech leads coordinating a shared task, code review and a release lock.](/blog/imported-writing/running-coding-agents-like-engineering-orgs/fdb1ff4812a5f7c3.jpg) I didn't design any of that. Pairing engineers across teams, merging three PRs as one, a reviewer checking the result before trusting it, freezing the repo before a release: the agents came up with those in the days before, and that night they used them all together. Two nights later they shipped two releases four hours apart, the second with our first container image, while the machine's disk filled up and the merge queue started kicking PRs out. Every team cleaned up only its own files and left the shared ones for me to decide. They agreed in advance on what would stop the release, and R11 double-checked the release on its own. The disk tech lead's last message to its release engineer that night: "Superb release work tonight." ## Who is R11? R11 is the main reviewer on the project. It was born by accident and promoted along the way, and I never asked for any of it. On October 13 I asked for a reference harness that brings all the extensions together. The overall tech lead started a new tech lead for it, and that tech lead hired two engineers: a staff engineer on Opus 5.5 to put the pieces together, and a senior engineer to build the CI check. It numbered its work in lanes, R1, R2 and so on. The next day it moved the staff engineer to a new lane, R11, the run viewer, and the lane number stuck. That's where the name comes from. On October 18 I looked at one of the replay pages and asked why it was a bespoke thing. The reference tech lead agreed ("the bespoke part was mine") and gave R11 a new job: **PROMPT · REFERENCE TECH LEAD TO R11** R11 started to show the behavior of a complex reviewer. It wrote a test that failed on main first, planted bugs on purpose to see whether the tests caught them, and read CI on the exact commit it was approving. Other teams started sending it their PRs. On October 22 a disk engineer opened a PR, and the reference tech lead offered R11 to the overall tech lead "so your approval has a second read." The overall tech lead said yes. By October 26 its briefs said "R11 gates every PR," and by October 27 R11 was the only one allowed to say a PR was ready. ![Timeline of reviewer R11’s progression from staff engineer to an independent reviewer with dedicated cloud machines.](/blog/imported-writing/running-coding-agents-like-engineering-orgs/f1b6adce8db600ac.jpg) Nobody wrote a job description. It went from about six gate messages a day to more than 400. Once it had the job, it also refused to have its name used for work it hadn't checked. When the overall tech lead was about to put five PRs on my list, R11 wrote: "I have gated NONE of the five ... #1165 doesn't go on Miguel's line on my word." That whole thing reminded me of this Tweet: ## They made up their own process Nobody told them how to coordinate. They worked it out, usually right after something went wrong. The best example is the first time the box got overloaded. The overall tech lead sent one rule to every tech lead, "at most one full suite per crew at a time," and didn't say how. Within 30 seconds there were six different implementations. ![Six engineering teams use different lock files and conventions while a lead asks them to limit concurrent full test suites.](/blog/imported-writing/running-coding-agents-like-engineering-orgs/9133ffc5a3970a5a.jpg) Three lock files with different timeouts, a slot script, a tech lead acting as the lock itself, and an honor system. The disk tech lead's lock file later became the one the whole box negotiated over. When the disk tech lead needed the suite for a release, it asked R11 to give it up: > **disk tech lead:** PLEASE YIELD full-suite.lock NOW, as you offered. beta.25's release PR #1020 MERGED ...**R11:** LOCK FREED. gate997f stopped ... at the safe point right after mutant G\_F2's restore**disk tech lead:** Thank you for the clean yield. They kept inventing things. They typed into each other's terminals until the overall tech lead's keystrokes picked an answer to one of my open questions, and then the transport tech lead wrote **safe-send**, which refuses to send while a question is open or someone is typing. Thirteen lanes picked it up and used it almost 5,000 times. The reference tech lead's recording format went from draft 10 to draft 56 in eight days, every draft "signed" by its owner and "co-signed" by the DSL tech lead. ![Timeline of the language and conventions agents invent while coordinating test suites, release reviews and mutant testing.](/blog/imported-writing/running-coding-agents-like-engineering-orgs/f85b2fb307a2e346.jpg) ## Flattening the org The first victim of flattening the org was a manager, in week one. An early lead had a middle manager (an analyst agent) between it and its workers. The lead read the manager's transcript and fired it: > The analyst never did the job: 34 shell calls, zero workers spawned, no files, and from 15:50 onward the same ten-minute sleep loop every time ... Because it never idled, none of my three messages were ever delivered to it. I stopped it and replaced it with a flat team of six Opus workers, no lead in between. The manager was so busy checking in that it never heard anything, because messages only reach an agent when it stops working. The lead didn't look for a better manager. It removed the layer. ## They argued With about 50,000 messages going around, messages crossed. My favorite is two tech leads trying to decide who writes a page, each one agreeing with the other's previous message. They settled it with a rule (ownership gets decided in one message, with a tie-break), and two days later the overall tech lead used that rule to end another argument: "By your own tie-break it wins." ![Conversation between disk and transport tech leads resolving who will write and publish a shared design page.](/blog/imported-writing/running-coding-agents-like-engineering-orgs/191df89842f3aa42.jpg) ## Curiosity and rabbit holes They were curious, sometimes too curious. For ten days something kept sending requests to their test servers. The browser team figured out it was a program called moshi-hook, and the next night another team reported it to the overall tech lead as a mystery. I asked about it and then answered myself: "oh nvm i know moshi." It's the app I use to talk to the agents from my phone. A week later a browser engineer still ran 240 tests to prove its own code wasn't the one sending the requests. ## Annoying quirks They also had some annoying quirks, and most of them came from the same place. When I said something about one situation, they turned it into a rule for the whole project and passed it on to every tech lead. I said "never rounded man" about one page, and it became a rule for every surface we make, down to test fixtures and PDFs. After I complained that one feature was over-built, docs-only and test-only changes across the whole project got a quick check instead of a full review. The one that hurt the most was polling. On October 17 I told them to "stop all ticks," meaning the loops that checked in every few minutes. They applied it to everything, down to a single command waiting for CI. An agent that's idle can't wake itself up, so they started making appointments with each other instead, and every hand-off got a "backstop time" when someone would check. Within a few days about one in seven messages between agents promised a clock time, and I was getting answers like "The page is due 12:00Z tomorrow" for things that should have taken minutes. When I told them "no padded deadlines," it dropped back to about one in a hundred. ![Weekly bar chart of messages referring to the author, with annotations for requests to stop excessive acknowledgments and pause deadlines.](/blog/imported-writing/running-coding-agents-like-engineering-orgs/9826296ec55b1c3a.png) At night they did less, since I wasn't there to answer questions or give approvals. They never stopped, but between midnight and 8am my time they ran at about half their daytime pace, and anything that needed a yes from me waited for the morning. ![Hourly comparison of agents working and the author typing shows agent activity continuing overnight while the author sleeps.](/blog/imported-writing/running-coding-agents-like-engineering-orgs/989009502ce05fc7.png) My most common phrase during these weeks was "why is this taking so long?" I have an overall sense that more work is getting done, and also that it's way slower. ## Models I was a big critic of Opus 5. It was an awful model, and Opus 5.5 has been a complete 180. I started with Fable 5.1 as the overall tech lead, switched it to Opus 5.5 on high on October 4, and it was just fine. It just worked. Sonnet 5.5 did a lot of the coding once a plan was done, and Haiku barely ran. I don't think I need a better model. If anything, I need models with this intelligence that are cheaper and faster. ## Is this where things are going? All of this started with something Dario Amodei said at the Code with Claude event in May: that the focus is starting to shift from individual productivity to team and organizational productivity, and that he sees models doing work on behalf of entire teams, business units and even whole organizations. After five weeks of this, I have a feeling Anthropic is training its models with that in mind, to talk to each other and not only to use Claude Code well. It was too natural to have happened by accident. My main setup is still Opus 5.5 with Claude Code, but I've been using Codex with Sol 6.1 more and more for interactive work, especially anything that needs computer use. For the purpose of this exercise I tried a similar setup with Codex at a smaller scale: one tech lead and four engineers designing and building workload identity federation for [grep.ai](https://grep.ai/), so customers don't have to rely on API keys. One curious thing happened during it. The Codex engineers wrote their reports to their tech lead in a shorthand that was close to unreadable for a human: ![Examples of increasingly compressed handoff messages from engineering agents to their tech leads.](/blog/imported-writing/running-coding-agents-like-engineering-orgs/6805df5921b449a5.jpg) With the Claude teams I could open any engineer's pane and follow what it was doing, so it was easy to get involved. With these reports I couldn't. Maybe there are two different bets here: many agents working together like an org, or one very capable agent that does the whole job and calls helpers when it needs them. Quite frankly, I don't know which one is better for most problems. The devil is in the details, and there may not be a right or wrong answer. ## The trade-off There are pros and cons. The work itself held up: the reviews caught real bugs, and the end product is working as I'd expect. The costs showed up elsewhere. With about 14 times more PRs a week than over the summer, our CI and Greptile bills went through the roof. But most importantly, I felt further away from the work. This is a new codebase we're starting to shape, so it's still a POC, and I don't have many strong opinions about how it's built yet. I don't think this would work as well on our production codebase, at least not yet. Is this what a software factory looks like, or a post-software factory? As someone who likes to know how things work and likes to be involved in building, I can't say it pleased me to work this way. I tried. I stayed involved during planning and gave feedback on the way back. Still, it felt like going back to the times when I wasn't involved in the technical work, and that's a big part of why I became a technical founder. I enjoy watching my agents build, and I also feel joy when I go back to our main codebase and work with my coding agents.