I have 13 engineers on my team. None of them is human

In 45 days we merged 263 pull requests. Here's how this department is built, what holds it together, and why it's precisely the speed that made human judgment more expensive, not cheaper.

The first thing I open in the morning isn't a code editor. It's a list of five jobs running in parallel, each in its own copy of the code, each in the hands of a different engineer. One is building an events screen, a second is digging into slow load times in the feed, a third is writing a spec. I move between them, read a report, approve, send back a comment, move on.

It sounds like a team lead's morning. It really is a team lead's morning. Except that none of my engineers is human.

I'm the CTO of Josie, a new kind of music curation platform where creators, artists and media people, along with hundreds of regular music lovers, already publish recommendations with the reasoning behind them, and tens of thousands of music lovers discover new music through them and listen to it on Josie. I'm also, as of right now, its entire engineering department. The rest of the team, thirteen AI agents, lives inside the repository itself. Each one has a job description, boundaries of responsibility, and long-term memory that's stored in git and loaded into it automatically every time it wakes up.

I used to manage tools. Now I manage an organization

Over the last few months I've read quite a few articles about startups and companies adopting agents, and they all describe the same pattern: a senior developer runs five or six agents in parallel, briefs them, and asks them to check each other too. An engineering manager at one company put it nicely: "There aren't really developers anymore. We're all team leads."

I read that and nodded, because that's exactly how I was working. What occupied me was the question of what happens if you take that direction all the way.

Because running five agents in parallel is already a real change, but I hit a ceiling very quickly. Each of them starts from zero. You explain the same thing to it for the thirtieth time, and it makes the same mistake for the thirty-first. That's not a team. Those are excellent freelancers with amnesia.

Until July, my team was basically the movie "Memento," just with TypeScript

What solved it wasn't more agents, but structure. On July 2, 2026 I stopped operating agents and started managing an organization: a team lead who routes every task to whoever owns it; three advisors (an architect, a UX and product specialist, and a designer); two platform engineers who hold up the infrastructure of the website and the mobile app; and seven domain engineers who actually build and ship.

The strictest rule in the system is the ownership rule: every shared concern has one and only one owner, and two agents never touch the same code. A task that crosses domains doesn't split on its own. It goes through the architect first, who writes a short design doc, and only then splits into parallel work.

The memory is the asset. Not the agents

If you take one thing from this post, let it be this: the hierarchy isn't the interesting part. The interesting part is what's left behind it.

At the end of every task, each agent writes itself a lessons entry: not a description of what it did, but what it learned. The entries are saved as files in git and loaded automatically the next time it wakes up. Right now we have 188 of those entries, and 957 lines of distilled, maintained memory.

What's in there is prosaic to the point of boredom, and that's exactly why it's valuable: that a certain query in the database doesn't behave the way the documentation promises. That the production servers have a name that sounds like a dev environment, and you must not infer anything from the name. That a certain background process can, on an unclean shutdown, quietly silence every notification email in the system.

Every line in there is a bug we've already paid for once. Without the memory, you pay for it again every week

That's the difference between a team that compounds and a team that resets. It's also, by the way, the difference between a veteran employee and one on their first day, except that here you can git commit it.

How a change gets to production here

I'm asked a lot whether the speed comes at the expense of control. The answer is that it comes because of it. Every change, without exception, goes through the same path:

The code is written by one model and reviewed by another, a separation I introduced back at the end of 2025, before it had a name. Alongside that, every change runs automated tests, type checks and static analysis. And at the end there's one gate that doesn't move: the agent doesn't merge its own work. Ever. A human says yes, or it doesn't go into production.

And why April was actually the most important month

July's jump wasn't born in July. Josie was founded in January 2025 and used AI tools from day one. At first the maturity just wasn't there, and we brought in human freelancers, mostly ahead of launching the first version and shipping the mobile app. From summer 2025, development became AI-only, and since the end of that year every line of code in the company is written by AI and reviewed by a different model.

The real turning point was April 2026, the month I built Eager, a system for managing the agents' work: tasks, initiatives, and a link between every pull request and the task it closes.

If you'd looked at my commit graph back then, you'd have sent me a private message to ask if everything was okay at home. April through June look like three months of clinical depression. In June I touched thirty-one commits. Thirty-one.

But what was happening there wasn't a slowdown; it was building infrastructure. Eager, the ownership rules, the memory protocol, the boundaries between domains. On July 2 I just flipped the switch.

What went in over 45 days

The volume alone is a boring number. The spread is the story: the 263 pull requests touched almost the entire surface of the product in parallel.

The live events system was built end to end: ticketing, coupons, Q&A, recordings, and, for the first time in the product's history, Hebrew pages with full RTL support. In parallel, the personalized feed program was running: a taste-signals layer, a ranking and recommendation engine, and a fundamental rewrite of the feed's loading path after we identified a bottleneck in production. In a third track, a provider-neutral music entity layer was built: infrastructure that frees us from depending on a single music service. Private profiles for users who don't publish went to production. And the mobile app got its platform adaptations at the same time.

On a human team our size, we'd have picked one of the three and pushed the rest to next quarter

Today I no longer have a "next quarter" list. Not because I stopped prioritizing, but because when execution stops being the bottleneck, there's simply nothing to push.

And why human judgment is worth more right now

This is the question I get every time I tell this story: if the agents are so efficient, what's actually left for humans? I love it, because the answer is the exact opposite of what it sounds like.

The agents removed the bottleneck of hands. What's left is judgment, and the one thing you can't parallelize by adding another agent is precisely judgment.

First, pace. At 41 pull requests a week, a wrong architectural decision doesn't stay local. It replicates itself into dozens of changes before anyone even notices. The faster execution gets, the price of a bad decision goes up. It doesn't go down.

Second, bandwidth. Today I make the calls on architecture questions, product questions and user-experience questions, often in the same hour. The agents produce excellent options. The one who chooses between them is me, and I'm much slower than they are.

And third, and this is the simplest of all: all the context of the company's engineering capability runs through one head. Mine. That's an operational risk I don't like looking straight in the eye.

What's missing here isn't another pair of hands. It's a second opinion you can trust

And what's next

I don't think the structure I built is final, and I don't pretend it is. The agents are text files; their memory is files in git. Splitting a domain or merging two is an hour's work, not an organizational quarter with an alignment workshop at a hotel.

That, to me, is the real advantage: an org structure you can change on a Monday morning.

And what I was looking for wasn't to grow the team. The team is fine, thanks. I was looking to grow the number of people who can tell me "no." At this pace, that's probably the cheapest investment the company can make.