Everyone is writing code

Introduction0:00

Hi everyone, and welcome back to the Hybrid Product Podcast. I’m Nikhil Kakarla, your host.

I want to start today with a quote from Adam Gardner, director of product at a company called Backstroke. He said, “I’m not an engineer. I want to be upfront about that. But three weeks ago, I shipped my first pull request into production.”

Last episode, we talked about how product orgs are designed. Today, we’re going to talk about who writes the code. Because the answer at a growing number of companies is everyone: product managers, designers, customer success, support, marketing, and of course the actual engineers.

This episode has two halves. First, what’s happening right now: we’ll zoom in on four companies, how they’re building differently, what’s working and what could go wrong. Then what’s coming next, and the fundamental question. If everyone can write a change, who becomes accountable for it when it’s in production?

Backstroke: a PM ships the fix1:03

Let’s start with Backstroke. Backstroke makes email marketing software for e-commerce brands, and email is notoriously difficult: fonts break. One afternoon around 3 p.m., Backstroke’s VP of marketing posts in Slack that customers keep complaining their brand fonts are breaking in their inboxes.

Normally, that message would enter an engineering queue, wait its turn and get patched. But this time Adam, a product manager, picked it up himself. He wrote a short spec, turned it into a ticket, opened Claude Code, and let Claude Code build the fix on a branch of the production app. He ran the app on his own machine, clicked through it, and opened a pull request for engineering to review. The engineers reviewed it that evening, and it was merged the next morning.

A Slack message at 3 p.m. was live by noon the next day, and no engineer had to write anything. Adam’s honest that it wasn’t easy. He didn’t really know how to use Git, and he wasn’t quite sure how to do it. But the power is there. Non-engineers can ship code that engineering reviews and pushes into production, and that by itself is a 10x improvement in productivity.

LTV.ai: proof for every change2:12

The next company is LTV.ai, which builds AI that writes personalized email and text messages for e-commerce brands. To change their product faster, they built an internal agent called LT. LT is basically a junior software engineer. In July, LT opened 84 pull requests, of which 45 were reviewed by engineers and merged. One customer request went from a customer success call to production code in two hours.

What stands out is how LT creates proof for technical and non-technical users. After any change, LT drives a real browser, records a video of it working, and makes sure all the proof is there for an engineer to review and merge.

The takeaway: writing code is cheap. Writing code is easy. What matters is the proof, and how quickly you can review it.

Dune: designers in the codebase3:12

Next is Dune, a crypto data platform where people query and chart blockchain data. It’s about as technical a product as you can find, so you wouldn’t expect its designers to be writing code. And yet designers at Dune now open between 5 and 15 pull requests a week.

Austin Keeble, a designer there, explained what changed. The biggest barrier, he said, was psychological, not technical. Once the designers had the production code running on their own machines, they stopped seeing code as an off-limits, scary thing. They could simply make the changes, approve the designs, and send those changes to the engineers.

Austin is also very clear about where the boundary is. Strong engineers remain absolutely essential, he says. It’s not a replacement story, it’s a delegation story. The designers at Dune are careful not to touch any of the engineering code, and every design change is submitted as a pull request that an engineer reviews.

HotDoc: who wakes up at 3 a.m.?4:21

While these three companies have had a lot of success, not everybody is convinced. Wendy Glasgow is the CTO of HotDoc, an Australian platform millions of people use to book doctor’s appointments. In September, she drew a hard line: non-engineers can build all the prototypes they want, but they can’t touch production code unless they understand its complexity and its constraints.

She posed a very simple question: who is the one who’s going to wake up at 3 a.m. when it breaks? It’s the right question. And today, every team answers it the same way. No matter who writes the code, an engineer reviews it, an engineer merges it, and an engineer owns it. If it breaks, they’re the ones with the pager. That’s the key bottleneck in every one of these stories.

The one thing that hasn’t changed5:10

As we start to think about what’s coming next, let me summarize where we are. The product world is now in its collaboration era. Designers are shipping code, engineers are shaping features, PMs are building prototypes. That part is real, it’s happening fast, and there are tons of products to support it.

But look at the one thing that hasn’t changed. At Monaco, engineering meetings are now mostly reviewing everyone else’s work. Dune talks openly about review load being the problem they haven’t solved. Coding agents have made it easy for anyone to write a change, but we haven’t made it possible for anyone to own one.

There have been attempts across the industry to solve this. Internal review tools, Greptile and CodeRabbit all do the same thing: they take a first pass at the review, so by the time a change gets to a human, it’s in much better shape and the obvious errors have been caught. What these tools don’t do is let someone other than an engineer review and improve a change before it goes into production.

What shared accountability needs6:15

So what would shared accountability look like? You’d need two things. The first is a rule set, probably designed by the engineers, that governs who is allowed to make what kind of change. A PM could make a UX change, a designer could make a front-end change, but neither should be able to touch payments, the back end or auth the way an engineer can.

The second is a way to review a change in a language each person speaks. A designer isn’t used to looking at code, so they’d review it visually. A PM would review it as a user flow. And an engineer can keep looking at the code before it ships.

Hybrid7:06

That brings us to Hybrid, Ten’s product for shared accountability. Instead of optimizing inside the engineering queue, Hybrid lets people bypass it when we know a change is safe. Safety is defined by a set of invariants mapped to your code base, which make sure the core of your product isn’t broken while giving anyone the flexibility to take accountability inside them.

If you’re interested in Ten and what we’re building, or you think it won’t work, we’d love to have you on the show. See you next time on the Hybrid Product Podcast.