We ship a lot. No, I mean, like really we ship a lot.

This morning I found out we shipped something I'm proud of, and I found out the way everyone else did: a Slack message at 7:50am, about a thing I had absolutely nothing to do with.

Julie Sanchez had built pnpm new-app, one command that scaffolds a whole study app on our K2 platform. Two study modes, stats, badges, a daily streak, keyboard shortcuts, a first-visit tour, and the nav, the sitemap and the CI guards all wiring themselves up on their own. Adding an app used to mean copying an old one and hand-editing a dozen shared files. Now you run the command, write your cards in one data file, open a PR, and every PR quietly builds two throwaway apps and tests them so the template can't rot without somebody noticing. She attached a little demo video. It's really good work.

I didn't ask for it. I didn't approve it. I didn't know it was coming. I had zero percent awareness. That's not something I'm admitting to. That's the thing I'm proudest of.

How we ship so much, so fast?

We went to pull the number this week. On our Bike4Mind app alone we merged 468 pull requests in the last seven days, and half of them were live in production within about six and a half hours of opening. Before AI, I would be excited about 1-2 pull requests per day from an engineer and see them to to production within 1-3 days (assuming it was not a hot-fix) and that would have still been fast compared to the industry standard of ship a thing every two weeks. We wanted the thirty-day figure too, and of course I am proud that GitHub's API caps at a thousand results, and on two of our products the thousand most recent merges don't even reach back three weeks. (Yes I can call the API multiple times, but don't distract me while I am bragging about my awesome team!) Across everything (somewhere around twenty live products) our deploy pipelines fire north of two hundred times a day (that is a hint that we are experimenting with truly autonomous engineering loops on a couple of experimental products). The slice where a human actually clicks "send this to production" is about three times a day. The rest ships itself the moment the work is good.

At Bike4Mind we put the "C" into CI/CD! ;)

Thirty-four people. No release managers. No change-advisory board. Nobody whose job is to count any of this, and why I learned about Julie's app from the same Slack channel as everyone else.

Pre-AI practices that had to go

We started where everyone starts. Someone writes a change, someone else reviews it, the reviewer leaves comments, the author goes back and fixes them, and around it goes until a human clicks approve. It's the orthodoxy, with code gen truly scaling our PR velocity by 20x, this became the largest bottleneck to the company.

The jam wasn't the people. It was the shape. Every trip back and forth paid to reload the whole change into a second person's head, and then paid a third time when the author returned to it two days later having forgotten half of it. At any real speed the review queue becomes the ceiling, and the ceiling is one tired person's reading pace. And tragically now that it is so many more PRs, we were also loading the PRs into the various AI LLM's input cache (think $$$) multiple times.

So we changed one belief: a pull request does not belong to the person who wrote it. It belongs to us. If you're reviewing something and you see the fix, you make the fix and you merge it. You don't hand it back with homework. The only thing that goes back to the original author is a change that's wrong at the design level and needs a rethink, and that's rare. Everything else gets handled by whoever's looking at it, because they already paid to understand it, and bouncing it just makes somebody pay that cost twice.

That one belief is the whole difference between a team that reviews and a team that ships.

Everything meets an adversary first

Before a pull request is ever even opened, it's already been torn into by a fresh AI agent that has no stake in it and no memory of writing it.

The agent reviewing didn't write the code, can't talk itself into the approach, and has no pride on the line. It reads the diff cold and goes looking for the thing that breaks. It's frequently a harder, more clear-eyed critic than a second human who's been marinating in the same problem all afternoon and has quietly started seeing the code the way the author sees it. This happens on everything. It doesn't show up in our GitHub history, which is why anyone counting from the outside undercounts how much review we really do. The rounds you can see on GitHub are a second layer we add, when a change is worth another set of eyes.

The one rule we actually have

Use your actual judgment for the task.

That sounds soft but it is actually hard. The second you write a rule like "anything over N lines needs two approvals," you've told everyone they can stop thinking, because the rule's got it. And judgment is a muscle. It goes the moment a rule takes the decision away from the person closest to the work.

So we don't gate on line count. One big PR from the last 7 days was a six-thousand-line addition that went straight in with no GitHub review, merged by the person who wrote it, and that was the correct call. It was a brand-new page that didn't touch anything already running. The author knew exactly what it did and knew it couldn't hurt anything, and making them sit through a ceremony review would've taught everyone that ceremony is what we value. Meanwhile a fifty-line change that quietly reaches into how we calculate credits gets the full adversarial going-over, because that's where the danger actually lives. Risk is about blast radius, not size, and a person reads blast radius better than any number you could write into a config.

Nobody here wears the methodology hat

Building and shipping software is a skill, and it belongs to everybody. Every person at this company writes pull requests and pushes them to production. Not the engineers. Everybody. All thirty-four. When it comes to shipping there's one job: you build it, you ship it, you own it.

We have no scrum masters. No dedicated engineering managers. No process people. Nobody holds "how we work" as a capital-R Role, because the minute one person owns the methodology, everyone else is quietly told they don't have to think about it anymore, and how you build is the one thing you don't get to hand off.

I know the other way works because I watch it. Somewhere right now a company is paying a certified coach to take its whole team offline for a week, and at some point that week a room full of grown adults will be handed a bag of Legos and asked to build a little plastic duck, as if a duck has ever shipped a single thing a customer actually wanted. We don't run workshops about building. We build. You learn the craft the way you learn any craft that's real: by doing it, next to people who are good at it, on something that's actually going out the door.

The Slack message this morning wasn't luck. It's the flywheel. Julie didn't just ship an app. She shipped the thing that lets anyone ship an app, which means the next person who has something they want to teach doesn't need to be the strongest engineer in the building. They need one command and a list of cards. That's what "everyone a builder" turns into when you actually mean it: people quietly building the tools that let more people build. Nobody assigned it. Nobody could have.

And then she made a video about it

Julie didn't stop at shipping the tool. She recorded a short video showing how it works and dropped it in the channel, so the next person doesn't have to go archaeology through a pull request to find out the thing even exists. That's a habit violently spreading here: when you ship something other people could use, you take a couple of minutes to market it to your own team. Not a status update nobody reads. An actual little pitch for why your thing is worth picking up.

It sounds like overhead until you remember the alternative, which is the normal thing, where good work gets built and then dies in the dark because nobody knew it was there. A tool nobody finds is a tool nobody uses. So we've started treating "tell people, and make it easy to want" as the last step of shipping instead of a nice-to-have you get to later. Be kind to the next person, be smart about getting your work adopted, and market what you made. The flywheel only spins if people can see what you put on it.

Building things do not really matter anymore.

Marketing well the things you built is what counts as done.

"Fulls-stack" at Bike4Mind now carries the obligation to market your build.

How we decide what's worth doing

Shipping fast only matters if you're shipping the right thing, so we keep the signal close. Customers are in our Slack, in our weekly calls, in the feedback channels, in direct conversations, and more and more they hand us formal eval harnesses, which is the nice version, because it turns "is this better" into a number we can actually watch.

What we do with all that is almost stupidly simple. If something's broken or value is bleeding, it's a P0, and we stop. No bio break. Everybody funds it until it's dead. The rest sorts into P1 soon, P2 normal, P3 someday. No story points. No planning poker. No two-hour ceremony to decide that the thing on fire is, in fact, on fire. The label is the priority, and getting the label right is a judgment call a person or an agent makes in about a second. We know the P0 drill works because we ran it a couple of weeks ago when a wave of bots showed up farming free credits, and the thing was handled before most of us had finished our coffee.

The backlog grooms itself now

Once your priorities live in your closed work, you can learn them. So we pointed a fresh instance at our own history (the closed pull requests, the labels they carried, the priorities we'd set) and asked it to label the ungroomed stuff the same way. It's right better than ninety-five percent of the time.

It isn't learning a rulebook. It's reading our real judgment out of thousands of decisions we actually made and applying it to the new ones. When our judgment shifts, the training data shifts with it, and the thing stays current with nobody maintaining a config file nobody reads.

Anything trained on your past is conservative by nature. It's brilliant on whatever rhymes with something you've seen and weakest on the genuinely new: the first request of its kind, the customer who isn't like the others. So that's where the humans spend their attention: on what the labeler is least sure of, not re-checking the confident ninety-five percent. And because a model of your past can only ever hand your past back to you, the only thing that corrects it is the signal from outside it: the customers, the evals, the conversations that don't start inside our own repo.

We don't try to be perfect

We could build a process that never ships a mistake. We don't want one. A process tuned to catch everything is just the jammed review queue all over again, slower on every change and dead at any real volume. So we made the trade on purpose: we accept a small, visible error rate, and in return we ship.

Judgment misjudges sometimes. A label lands a notch too low, or the auto-groomer waves through something a person would've stopped on. We keep those misses rare and out in the open, and we catch them fast. Every pull request gets its own live preview, so "does it work" is answered by the thing running and not by a reviewer imagining it running. Rolling back is boring by design, usually one setting and a redeploy. Most of what slips is small and reversible. The rare bad one gets a response measured in hours, not a post-mortem measured in weeks.

...wait, is this just agile?

We didn't set out to follow a methodology. We were just trying to ship. I didn't even notice what we'd built until I sat down to write this, and I mean that literally: a few paragraphs up, listing out how we actually work, I stopped cold. We'd fucking reinvented agile. The real kind. The 2001 manifesto, before the word got taken hostage by the people who sell the Legos.

So, fine. Akshually: we're agile. I worked that out about twenty minutes ago, in this very document. I'm as surprised as you are.

But that old manifesto was right, and it still is. It just quietly assumed every person in the room writing the code was a person. Some of us are agents now, and the values don't crack under that. They get sharper. So we stopped laughing and wrote down the version we actually work by. We didn't draft it in a conference room; we reverse-engineered it out of a few thousand pull requests.

Manifesto for Agentic Software Development

We're still figuring out better ways to build software, now by doing it alongside agents and helping other people do the same. Through that work we've come to value:

Judgment over gates

Everyone a builder over a methodology priesthood

Shared ownership over individual authorship

Fresh adversaries over familiar approvers

Reversibility over prevention

Outcomes over output

That is, while there's value in the things on the right, we value the things on the left more.

And a few things we've come to believe:

• A pull request belongs to the team, not its author. Whoever sees the fix makes the fix.
• Every change meets a fresh adversary before it meets a human. New eyes with nothing at stake break what tired eyes defend.
• A rule that makes the decision for you teaches you to stop deciding. Keep few rules, and save them for the things you can't undo.
• Size is not risk. Review the blast radius, not the line count.
• When something breaks or value is bleeding, stop and fund it. No estimate, no ceremony, no bio break.
• Learn your priorities from what you actually shipped, not from a document nobody opens.
• Make a mistake cheap to reverse and you can afford to move fast enough to make a few.
• Correct code and a better-off customer are not the same thing. Measure the second one.
• Shipping software is a skill, not a role. Everyone authors, everyone ships. Nobody wears the hat.

We didn't sign this at a summit. It gets signed every day, by whoever's shipping.

You don't find this on a whiteboard

The belief that a pull request belongs to the team and not its author didn't arrive on its own. I put it there. One day I came over the top of the whole engineering org and said: when you review someone's PR and you hit a P2 or a P3, stop leaving a comment and just fix it yourself.

That only landed because of who was saying it, and I mean something specific by that. I'm one of the top three committers out of thirty-four people here. So when I told the team to quit bouncing small fixes back to authors, it didn't come from a manager theorizing about other people's work. It came from someone who writes and merges code every day and has felt the exact tax of a bounced PR. The company authority and the earned, in-the-trenches authority were married together in one person, pointed at one change. Either half alone bounces off. A CEO who doesn't ship can't credibly tell engineers how to ship, and a great engineer with no authority can't rewrite the org's rules. You need both at once.

Which is the thing I'd put in front of anyone running an engineering org right now. In the age of agentic AI, your most senior people have to be shipping, a lot, with AI as their agent, today. Not reading dashboards about it. Doing it. The shape of the organization you're going to need next is not visible from a whiteboard. It only shows up once you've felt where the work actually binds, and the only way to feel that is to be down in the pull requests with everyone else.

Where this is headed

On most of our products, a person writes the change and an agent tears into it. On a couple (our game engine and our paint tool among them) we're pushing further. The agents do more of the building, and the human job thins down to curation at the very edge: a light hand picking among what the system makes, deciding what's worth keeping. Still a human in the loop. Just the thinnest viable layer of one. We'll write that one up properly another time. For now the only point is that the way we work didn't strain when we handed more of it to the agents. It's the reason we could.

That's the whole trick, and it isn't one. A few assumptions everybody treats as mandatory that turn out to be optional, people trusted to think, feedback kept fast, and fresh eyes on everything. We can't tell you exactly how many times a day we ship. It is simply not important. It was always the wrong question. The right one is whether each thing we shipped was worth shipping. And that, we can answer.

It's just gradient descent to customer value

The machine-learning version of all of this: it is gradient descent to customer value, and we are trying to take bigger steps, more often, than anyone we compete with.

That is the entire objective function. Every practice in this piece is just a term that makes the step bigger or the steps more frequent. Shared ownership, so a fix ships in one move instead of three. Fresh adversaries, so a bad step gets caught before it lands. Severity triage, so we always descend the steepest slope first. Judgment over gates, so nothing slows a step that didn't need slowing. None of it is the goal. The goal is the rate at which customer value improves, and a practice only earns its place by raising that rate.

The opposite is the thing I will go to war over: there is no such thing as process for its own sake. A ritual that doesn't make customer value get better faster is not neutral. It is a cost. It is friction on the only number that counts.

And that number runs all the way down the stack. Descend to customer value faster than your competition and it shows up as revenue sooner, as lower cost per thing shipped, as more EBITDA, as cash you get to turn back into the next product before anyone else can. Speed to customer value is not an engineering nicety. It is the whole business, wearing an engineering costume.

Come build with us.

- Erik, and the whole Bike4Mind team