APES on TechVibe: A Conversation with Jonathan Kersting

Watch the full conversation: APES on TechVibe

I recently spent twenty minutes in the Huntington Bank Studio with Jonathan Kersting of the Pittsburgh Technology Council, talking through APES, GridPulse US, and the gap between a demo that looks finished and a product that’s actually ready for customers. The conversation is part of PTC’s TechVibe series. Full episode below.

PTC also published their own written piece on the conversation, with the full transcript: Beyond Vibe Coding: Adam Wynne’s APES Method Builds Software Ready for the Real World.

The Question Everyone Should Ask First

Jonathan opened with the question I wish more founders asked themselves before they start building: how do you actually know when something’s ready for production, versus just looking like it is? That distinction is the whole conversation in miniature. Vibe coding will get you a demo that looks great, fast. It won’t tell you whether that demo can onboard 500 real customers without falling over. Those are different problems, and most AI coding tools only solve the first one.

Why APES Covers the Whole Engineering Cycle, Not Just the Code

Writing code is maybe 20% of building a real product. The other 80% is discovery, requirements, technical specs, testing, security review, and operations, and that’s where most AI-assisted development stops helping. APES (AI-first Product Engineering with Specs) runs specialized agents across the entire cycle instead of optimizing the one step everyone else is racing to speed up. It’s the difference between a faster demo and a faster product.

Adversarial Agent Reviews

One technique we get into: every feature I ship gets reviewed by four parallel agents, each arguing from a different seat at the table, a developer, a user, a security architect, and one more hunting for whatever the other three missed. It’s a technique adapted from existing engineering research and frameworks, built to replicate what senior developer review used to catch before senior review time became the bottleneck. It almost always finds something: an edge case, a security assumption that doesn’t hold, a bug that would have shipped quietly and shown up three weeks later as a support ticket.

Proof: GridPulse US

GridPulse US, a real-time US electric grid analytics platform built on EIA-930 data, is the reference implementation for what this approach can actually do. I built it solo, in about seven weeks, using APES end to end, from discovery through production. It’s the proof point behind the 10x claim: not a demo, a running platform.

People Ask Me: “We Need to Use More AI But Don’t Know Where to Start”

Every CEO I talk to knows they need to be doing something with AI. Almost none of them are getting a straight answer about what’s actually working versus what’s expensive theater. That’s the problem my Innovation Program solves: I embed with a small working group inside the company, typically three to six people, and lead a disciplined cycle of identifying the use cases that would actually move the needle, prototyping the strongest ones fast, and killing what doesn’t work. No slide deck at the end. Working tools your team owns, and the judgment to keep evaluating AI opportunities on their own after I’m gone.

The same AI-coding shift that’s compressing product builds down to weeks has also shortened how long it takes to validate whether an idea is worth pursuing at all. What used to take a large consulting engagement and a year and a half to prove out can now take weeks, with something real to show for it rather than a report.

See how the Innovation Program works →

Why the Code Has to Be Yours

A founder using AI to build their own product will often get surprisingly far solo, right up until it needs to go into production. That’s usually where I get the call, and the first thing worth discussing has nothing to do with code, it’s ownership. Everything I build, code, documentation, and specs, lands in the same repository a developer would actually work from. No black box, no “it just runs somewhere and we’re not totally sure how.” That matters most for founders who don’t want to trade equity for a technical co-founder just to get something built: I can scope the work, hand off a production-ready product, and step back, or stay on to help operate it. Either way, you own what you paid for.

Watch the Full Episode

The full conversation, including a segment on where AI-first product engineering goes next for small and mid-sized businesses, is here: watch on YouTube.

Thanks to Jonathan Kersting and the Pittsburgh Technology Council team for the conversation, and for the studio time.