The AI-Native Two-Way Build: When the Owner Ships

Last post I said that once alignment gets cheap, the next bottleneck is the handoff between the person who decides what to build and the person who builds it. This is the post about closing that handoff. It's also the one that made some of my engineers nervous, for good reasons.

The old shape of a small UI change on our team was a relay: PM writes it up, designer mocks it, engineer implements it, PM reviews the result, engineer adjusts, repeat. Four or five handoffs for a copy tweak and a layout fix. The person who owned the intent, the PM or the designer, sat at the far end of the chain describing what they wanted and waiting to see if it came back right. Every round trip was a review cycle, the exact thing we spent the last post trying to kill.

So we collapsed the chain. The person who owns the change makes the change. It runs in two directions, depending on where the work starts.

Engineer builds the skeleton, owner finishes it. An engineer takes a feature end-to-end behind a feature flag: wired up, working, not pretty. Then the PM or designer does the polish themselves, in our own product, Fei Studio: copy, spacing, empty states, micro-interactions. No ticket back to the engineer, no waiting. This is the Polish in PuMP. The engineer's merge gets the feature in behind the flag, and polish is a separate owner-driven phase that runs in parallel while the engineer is already on the next thing. It got ~50% faster for us.

Owner builds the front end, engineer adds the back. Sometimes the work starts on the surface. A PM or designer builds the front end of a flow first, gets it feeling right, and an engineer comes in underneath and wires up the real data, the persistence, the edge cases. The intent and the interface come from the person who owns them. The machinery comes from the person who owns that.

There's a bigger pattern under both directions. With a reliable system doing the building, everyone moves up a level. Work that used to need a senior engineer, a mid-level one can own now. Work that used to need an engineer, wiring up a screen or shipping a copy-and-layout change, a PM or designer can own now. Nobody's doing less. Everyone's a rung higher, closer to intent and further from the keystrokes. That shift is the whole point. The two-way build is just what it looks like in a pull request.

The thing that made it safe: there's a line, and everyone understands the principle behind it, even if the exact boundary gets renegotiated in the edge cases.

Above the line is user-facing: a change you can see and verify by looking. Copy, layout, a component, a flow. If the owner can look at it and know whether it's right, the owner ships it.

Below the line is the part you have to reason about, not look at: schemas, data, performance, security, anything where "it looks fine" doesn't mean it's fine. That stays the engineer's call, full stop. A PM moving a button doesn't touch a migration.

And the cultural bit that matters most: a change getting sent back across that line isn't a failure. It's the safeguard working. When an engineer pulls a PM's PR back because it quietly changed something below the line, that's the system doing its job, not the PM failing. We had to say that out loud, a lot, before people believed it.

Now the honest part.

The engineers' first reaction was fear, and it was legitimate. Not turf, quality. "I'm going to spend my time cleaning up after PRs from people who can't read what the agent wrote." Happens less than they feared, but it's not zero, and dismissing the concern would've been a mistake. The line is what addresses it: it's not "everyone can change everything," it's "owners ship the part they can verify, engineers own the part they can't."

The boundary gets renegotiated at the edges. Plenty of changes sit right on it: a component that looks like UX but carries real state logic, a "copy change" that's actually a behavioral rule. The principle is clear. Where a specific edge case lands is a living agreement we settle when one comes up, not a wall we built once.

Not everyone wants this. Some PMs were thrilled to ship directly. Others felt we'd handed them a job they didn't sign up for. Real tension, and I don't think the answer is forcing it uniformly. The ones who lean in change the pace of the whole team. The ones who don't still get value from the faster polish loop.

When it works, the effect is bigger than speed. The person closest to the user is the one shaping what the user sees, with no game of telephone in between. The handoff didn't get faster. It disappeared.

But all of this leans on one assumption I've been putting off. If more people are opening PRs, including people who can't fully review their own code, how do you not drown in them? If a PM opens fifty PRs, who reviews fifty PRs? Not a person in a meeting. That's the next post.