A year ago we came for horsepower

On September 24, 2025, ProductTank San Francisco and Lovable packed Cribl's office for a vibe-coding night. About a hundred product people came in with ideas and left with more than sixty demos. We were all very pleased with ourselves. Nobody in that room thought we'd be writing production code that way six months later.

One year and six days later I was back in the same room, at the biggest ProductTank of the year. Before saying anything I asked for a show of hands. Most of the room worked in product. A good number were founders. A few brave ones were in marketing. Then I put up a chart.

In October 2025, Pablo and I merged 14 pull requests. January was 14 again. In September 2026 we merged 1,657: more than fifty a day, one every twenty minutes if you never sleep. I was already surprised in May, when we got close to 400.

Same two people, by the way. We also design, sell, write, answer support and run the company, so this isn't two engineers locked in a room.

Most of that code isn't the product. It's the machine that builds the machine: the checks, tools, records and permissions that let two people trust work they didn't type. People have started calling that machine a harness. I like the word more every month.

The horse and the harness

The model is the horse. On its own a horse is horsepower: strong, fast and headed wherever it likes. The harness is everything you build around it so that horsepower turns into work you'd put your name on.

If you use ChatGPT or Claude, you already use a harness. It just belongs to someone else. Somebody decided what it remembers, what it can reach and what it does when it isn't sure, and as Wesley Frederick said when he opened the night, you can choose differently. Someone else's harness works for a while. Then you need something it was never built for, and the real question shows up: how much of the harness do you want to own?

We went through every stage, and each one felt different from the inside.

First, everyone prompts alone, and every chat starts from zero. Then come shared assistants: projects, Gems, custom GPTs. Now there's a horse, but you're riding it bareback. Then everyone gets Claude Code or Codex. You finally have something to hold on to, it doesn't take you very far, and it hurts. Everyone's setup drifts away from everyone else's.

The hinge is when you put the company into it. For us that meant a set of repositories that mirror the org chart: one for the product, one for customers and their calls, one for market intelligence, one for how the company runs and stays compliant, one that teaches agents how we work, and one full of synthetic data to test against. Now the horse pulls a cart. The agent starts inside your context instead of a blank chat.

Then you build utilities that engineers maintain and everyone else uses, and one horse becomes a team pulling a coach. A product manager or a marketer can open a pull request, because the system around them already knows how that kind of work gets checked. PMs always wrote the tickets. If an agent picks one up, builds it and leaves it ready for an engineer to review, what really changed? The PM's work ships the same afternoon.

The last stage is my favorite. The system starts keeping itself current: scheduled runs refresh what it knows, and a correction you've made twice becomes a rule. At that point you aren't riding anything. Your horses travel in a truck you designed, and they get there sooner than any horse you could ride.

A rule in a prompt is a request

Each repository has its own agents and its own permissions, the same way each team has its own access. Marketing's agents can write slides in our Google Drive. Should they be able to share one outside the company? Probably not.

We learned this the lucky way. An agent that was allowed to draft email could also send it, because one permission covered both. One day I noticed an email had gone out to a client on its own. It carried the order form for the annual contract we were moving them to. It was short and it was fine. It could easily not have been.

You can write "never send this to a client" in a prompt, and the agent will listen. Most of the time. So we forked Google's Workspace command-line tool and put roles on top of it. Agents write drafts. Anything that leaves the company, from a calendar invite to a deck, needs a grant from a person.

So when you write a rule for an agent, ask whether a tool could enforce it instead. If it can, the rule belongs in code.

Review works the same way. If you want a SOC 2 report, every change needs a second reviewer, and that reviewer shouldn't be an agent. Everything that reaches production at Zentrik has been read by both of us, and most of the harness exists to make that reading fast: clear briefs, checks that run before a person looks, and one place that shows what changed and why. Most of our day is reviewing now. I don't mind it.

Someone in the audience asked the obvious follow-up. With that much output, how much slop do you make? A lot.

Of every hundred pull requests our agents open, about a third ship on the first pass, a third go back for a loop or two, and a third never ship, because the evidence wasn't there, no customer was asking, or the work wasn't good enough. I'd rather open a hundred and merge sixty-six than open twenty and merge twenty. The harness has one job with that last third: keep it away from customers.

No mates moscas a cañonazos

In Spain we say no mates moscas a cañonazos: don't kill flies with cannonballs. A lot of agent work is a chain of small decisions, each with a short list of possible answers, and a frontier model is the cannonball.

Twelve years ago I was building chatbots, first in Barcelona and then in San Francisco. They ran on classifiers. You typed "I forgot my password" and a classifier sent you down the forgot-password branch. For a toy brand we chained them. Someone writes "a present for my nephew, he loves Star Wars", and within a few milliseconds one classifier decides it's a product question, the next picks the theme, and a third reads "nephew" as a boy of about a certain age.

That old trick is back, with much better classifiers. On stage I pasted a meeting note into Open CRM, the open-source edition of the CRM we use internally. The matching runs on Jev, a classifier from TypeSafe. You give it a passage and a list of options, and it gives you back a probability for each one, read from the model itself rather than written into a sentence. It proposed every account update in about a second, and I approved each one before anything was saved.

Earlier that day I'd timed the same note against a CRM of sixty fictional accounts. Claude Code, editing a Markdown export of that CRM, took 19 to 45 seconds and around 70,000 tokens a note. It also edited files the next sync would overwrite, and politely told us so every time.

So break the decision into smaller ones. Give the settled parts to code and small models, and keep the large model for the part that needs judgment. If you write documents all week, build the utility that writes them. If you update accounts all week, build that one. You spend fewer credits and less time, and you keep the value.

Can I just stick with Claude?

The question I hear most came from a founder near the front who builds for clinicians. Their days go to patients' and clinicians' problems, and there's no room left to learn yet another tool. So what bad thing happens if they just stick with Claude?

Nothing bad. Stick with it. The assistants are converging. We pay for Codex, Claude Code and Cursor, about $420 a month per engineer, and they do roughly the same job. Pick the one you like and own the rest: the context, the checks and the record of what you decided. The models aren't the moat anymore. The system around them is.

On the day a provider starts squeezing you, moving to another one, open source or not, should mean redoing an instruction file, a login and a connector. It's like putting solar panels on your roof. This month's bill isn't the point.

How does any of that map to revenue?

Then came the question I should have had a slide for. Nice chart, someone said. How does it map to revenue, and to customers?

I couldn't answer in revenue. The number I watch instead is how much of what we merge links to a need at least two customers raised. We started counting in January, at zero. February was 8%. On the night of the talk it was 56%. Our goal is 85% by the end of the year.

The rest is fixes and the machine that builds the machine. Useful, and no customer is better off for it yet.

What I'm really counting is how many times a week I get to write to someone and say: the thing you asked for is live. One of our customers was in the room, so I put them on the spot and asked how long a request usually takes. Their record: an email on a Saturday at 4 PM, live on Monday at 3 AM. They know the exact time because they woke up from a nightmare, checked, and found it had shipped. I'm choosing to take that as a compliment.

That number is hard to move, for a reason that took me a year to see. Agents can always open another pull request. We can only talk to so many customers in a day. One side runs on compute and the other runs on conversations. So the work left for people is the human part: talking to customers, understanding them, and carrying what they said into the work. That's what the next people who join us will spend their days doing.

How we work now

This is the job we built Zentrik for. It reads the sales calls, support tickets and research a team connects, ranks the ideas already in the backlog against that evidence, and flags needs the backlog doesn't cover yet. A person decides what to test, and tests it with customers before anyone builds. The brief engineers and agents build from carries the customer's own words. When the change ships, the team knows who asked, tells them, and listens to what happens next.

Take the sample in the figure. Maya asks for PDF export. Her ticket, a sales call and a CRM note turn out to describe the same Friday afternoon, spent rewriting client updates by hand. Of three possible answers, Priya, the PM, tests a weekly email first. Four of five testers stop before sending to check what their client will see, so the brief adds a preview. An agent builds from that brief, two people review it, it ships, and Maya's next call shows what's still slow.

Every step keeps the reason attached, and that's the check a code harness can't make by itself. Tests tell you the code does what the spec says. Only a customer can tell you the spec was worth writing.

The job moves up a level

The last questions of the night were about product work itself.

One attendee put it better than I did: once you can give people everything they ask for, you reach the scary question, which is what they actually want. Another pushed back, and fairly. Part of a PM's job is talking customers out of the button they asked for, and in a large company a feature added for one account becomes clutter for five hundred others. That's still true. I keep a little pet in Codex I call the No Knight, and it comes out in a lot of client meetings. At our speed there's a second option too: build the button in an hour, watch them use it, and find out together that what they wanted was for it to happen on its own.

Prioritization moves up a level as well.

Instead of ranking tickets, you rank the epic, then the initiative, then the objective. In B2B, you sit down with customers, agree what success means for them, and let the team order the work underneath it. In B2C it's the metrics tree you commit to. Either way, the goal gets your attention and the tickets get the team's.

And you can finally take things away. Remove a feature, write down who you expect to miss it, and wait. The people who ask for it back tell you what it was for, and they value it more once it returns.

None of these are new problems. Product people have always asked whether we're building the right thing, for the right people, in the right order. We're in product to solve something for someone, and building is how we get there. Agents make it very easy to forget which is which.

Try it this week

A year ago that room came for horsepower. This time it asked about the reins.

So here's the exercise I'd start with. Trace the last ten things your team shipped. Count one as traced only if you can name two customers and what each of them said.

Then tell me yours. In part two I take the same question into a product squad, with a worksheet for one workflow you can start on Monday.

The agent should be replaceable. The work around it should pile up.

Part two: The customer's reason has to travel with the work, on what changes inside a product squad. The slides, Open CRM and the film prompt from the talk are in the references below.