Code Generation Stopped Being the Bottleneck. Now Everyone Prototypes.

Curtis Sherbo will not call what his team did an AI transformation. I tried to get him to. He kept correcting me, and by the end of our Stacked Sessions conversation, I understood why.

Curtis runs Patient Conversations at Athena Health, the smallest product group inside a large healthcare platform. Roughly 250 people across product, UX, and engineering. From that constraint, his team has gone further on AI than companies ten times their size are still planning to. The thing that changed most isn't how fast they write code. It's where the hard part lives now.

For years, the bottleneck was engineering. Product never had a shortage of ideas. The constraint was always how fast code could get written and shipped. That constraint is going away, and the bottleneck is moving upstream, back to the work that happens before a line of code gets written. Deciding what to build. Knowing it's the right thing. Curtis said it plainly: if you think in a process mindset, suddenly the slow part is everything you used to do first.

When the expensive part of the process flips, you change who gets to build.

Everyone prototypes now

In Curtis's org, every product manager and every designer can turn an idea into a working prototype. Something you can click through, instead of a slide or a spec. AI prototyping in product development used to be a specialized skill. Now it's table stakes for the whole team, all the way up to the executive leadership team getting their hands dirty building things themselves.

That last part matters more than it sounds. When a leader builds a prototype, they stop assuming what the tools can or can't do. Curtis was honest that he's learning right alongside his team. He didn't have these abilities when he was a PM. Nobody did. The reason everyone does it is shared language. The way the job worked two years ago is not how it works now, and a team that doesn't all speak the new language falls out of sync fast.

Building to learn instead of building to earn

I shared a mental model with Curtis that has stuck with me: the difference between building to learn and building to earn. Most teams build to earn. Spec it, research it, define requirements, hand it to engineering, ship it. Every step adds constraints, and plenty of those constraints are artificial. They narrow the solution before anyone has tested whether it's the right one.

Curtis flipped the order. Get to a prototype fast, show somebody, get feedback, then do it again. His teams resisted at first in a telling way. One group ran a single discovery cycle, got something 40 percent of the way there, and wanted to hand it to engineering to finish. Curtis told them no. That wasn't the point. Who had they shown it to? Do it again. The prototype exists to learn, not to ship.

When the cost of failure is near zero and trying again takes hours, you approach problems with far fewer constraints. That's the part a lot of orgs miss. They use AI to run the old process faster instead of running a different process.

The wall between prototype and production

This is where product and engineering have to get the rules straight, and where Curtis was the most disciplined.

His teams have an explicit rule: no prototype code gets picked up by the delivery teams and pushed to production to finish it. None. The prototype is for discovery. When it's right, engineering rebuilds it properly, with the security, scalability, and supportability a healthcare platform demands.

Anyone who has shipped software knows the trap. An executive sees a slick prototype, decides it looks pretty much done, and asks why it can't just be finished. Curtis has lived the sharper version, where the executive built the prototype themselves and then asked why the team couldn't just wrap it up. The answer is the same every time. A clickable demo is not a deployable system. There is a checklist between the two, and pretending otherwise is how fragile software ends up in production.

Solve one bottleneck, uncover the next

This is the part worth sitting with. Moving the bottleneck upstream doesn't make bottlenecks disappear. It relocates them.

Curtis was clear-eyed about it. Whenever you solve a constraint, you uncover the next one. Compress discovery and the readiness-to-ship work becomes the new drag. Compress that and something else surfaces. The pace of change in generative AI is fast enough that today's bottleneck gets more automated every month, so the job is never finished. You keep finding the next constraint and working on it.

That's a healthier way to think about AI in the product lifecycle than chasing a finish line. The work is continuous discovery and continuous delivery, not a project with an end date.

What it took to earn this

None of this started with AI. That's the detail I keep coming back to.

Curtis's team spent 18 to 24 months on the foundation first. They restructured around team topologies, splitting platform teams from feature teams so cognitive load dropped and dependencies stopped being a constant coordination tax. They adopted a product-oriented model from the SVPG world, and deliberately called it a framework instead of a process so they wouldn't over-specify the work. They led with learning rather than automation, running low-risk experiments and peer share-outs so adoption grew bottom-up instead of by mandate. They even rate-limited the change, because people can only absorb so much at once.

AI tooling came last, on top of an organization that was already built to use it. That ordering is the whole story.

It also maps to how we think about the lifecycle at Allstacks. The upstream work, deciding what to build and grounding it in how your teams actually deliver, is what Allstacks Product Studio is built for, running on the Allstacks context graph so it never starts from a cold prompt. The Allstacks Intelligence Engine handles the middle, surfacing delivery risk once the work is moving. Front of the lifecycle and the messy middle, on the same model of your org.

Curtis and I covered a lot more in the full session, including how he brought skeptical teams along without breaking them. Worth a listen if your bottleneck just moved and you're standing there looking at it.