Real lessons in AI-enabled software product development

We’ve hit one of those rare moments where “this changes everything” isn’t hype. AI-enabled software product development is a true inflection point in how we conceptualize, design, deliver and maintain custom software. In our org, AI isn’t just helping developers type faster or auto-complete a few lines of code. It’s quietly changing how we design products, structure teams, architect systems, and think about risk… and it’s doing it faster than most companies out there are ready for.

So on a recent ENO8 Answers episode, I sat down with our Head of Architecture, Craig Mertens, and an AI-forward engineer, Maximus, to talk through what we’re actually seeing inside real projects (not just in demos or on Twitter).

This is the short version. If you want the full hour-long deep dive, the video’s embedded below. If you just want the highlights you can read on and be done in a few minutes.

The Cliff’s Notes on AI-enabled software product development

• AI’s impact is wildly uneven across the lifecycle
  Going from zero to working prototype? Massive lift. Going from proof-of-concept to MVP? Big lift. Ongoing feature development and maintenance? Helpful, but nowhere near the same order of magnitude.
  
• The real productivity gains show up at the system level, not the task level
  Academic studies see mixed results when they measure “time to complete a single coding task.” Our experience is that AI shines when you zoom out to “what work is now possible that we wouldn’t have done at all before?”
  
• We’re shifting from Figma-first to prototype-first
  A year ago, my favorite artifact in our Innovation Lab was a clickable Figma prototype. Today, in many cases, it’s cheaper and faster to build a thin, end-to-end technical prototype than it is to design and wire up a beautiful clickable mockup.
  
• Clarity matters more than ever
  AI is a thought amplifier. If your spec is tight, it accelerates you in the right direction. If your spec is fuzzy, it happily accelerates you off a cliff.
  
• Architecture is bending around AI, not the other way around
  We’re designing systems differently so an “infinite army of junior AI agents” can work safely and effectively: smaller surfaces, tighter guardrails, more up-front structure, more QA earlier.
  
• Tokens are cheap; understanding is expensive
  Generating code is now the cheap part. Having senior people understand, constrain, and validate what’s being generated is where the real cost (and value) lives.
  
• DIY “vibe-coded” products can get surprisingly far… but then hit a hard wall
  Non-developers with good domain expertise can now produce real working software. But the last 20% (security, scalability, reliability) still absolutely requires experienced engineers.
  

Where AI actually moves the needle in the lifecycle

One of the clearest patterns we’re seeing is that AI doesn’t help every stage of the product journey equally.

• From nothing → prototype
  This is where the lift feels almost absurd. Going from an idea and a requirements doc to something you can click on, demo, and put in front of users can now happen in days instead of weeks. AI copilots, code agents, and UI generators shine here.
  
• From proof-of-concept → real MVP
  Still a big win. You can scaffold more of the backend, wire up CRUD APIs, stitch together services like Supabase, auth, etc. The team still has to be thoughtful about architecture and quality… but they can stand up a credible MVP much faster than before.
  
• From MVP → ongoing product development
  Here, the gains are more modest. Auto-complete in IDEs, smarter refactors, code search, test generation — all helpful… just not the 5–10x multiplier people imagine. You still need teams making tradeoffs, managing complexity, and protecting quality.
  

A real example: we recently had a startup come in with a detailed requirements doc. Historically, we’d run a 6-week Innovation Lab just to define the thing, then a couple of months of build to get them to MVP.

Because of the internal AI-native processes and tools our team has developed, we felt confident we could deliver a working MVP in about eight weeks… total — at a budget that previously would’ve been reserved just for design and definition work. Same or better quality; radically compressed timeline.

That’s the pattern: the “time to something real in users’ hands” is collapsing in the new world of AI-enabled software product development.

From Figma to full-stack prototypes

For years, I’ve preached the gospel of clickable design prototypes. Figma, InVision, all of it. It was the fastest way to get alignment and de-risk a build before you committed big dollars to engineering.

AI has changed that math.

Craig and Maximus both hit on the same point from different angles:

• In the past, end-to-end technical prototypes were too expensive. You’d maybe do a tiny, tightly-scoped proof of concept, but you weren’t going to burn weeks of dev time just to validate a hypothesis.
  
• Now, with AI agents helping scaffold frontends, backends, and glue code, it’s cheap to build something that really runs (even if you’re going to throw parts of it away later).
  

Instead of only validating flows in Figma, we can:

• Hit real APIs or realistic mock data
  
• Run real auth and permissions
  
• Exercise real performance constraints
  
• Put something in front of users that behaves like the actual product
  

The result is that more of the “design thinking” and hypothesis testing can happen in the market, with real users and usage data, instead of purely in workshops and focus groups.

We still care deeply about UX and design… but we’re no longer limited to “pretty pictures that look like software.” We can get to real software, faster.

Why clarity and spec-driven development are making a comeback via AI-enabled software product development

One of Craig’s lines that’s stuck with our team is this: “AI is approximately wrong.”

It doesn’t reason. It doesn’t “know” anything the way a human architect does. It’s operating off a compressed statistical representation of human knowledge and whatever context you feed it.

So if AI is a thought amplifier, what you put in is what you get back, but amplified:

• Fuzzy input → fuzzy output (and a lot of clean-looking wrongness)
  
• Sharp, precise input → sharp, precise scaffolds you can actually build on
  

That’s why we’re leaning harder into a style of work that looks, on the surface, a little more waterfall than the agile orthodoxy would like:

• Start with a serious spec: data model, architecture, key flows, edge cases
  
• Use AI to help draft and refine that spec much faster than we could manually
  
• Have experts review the spec — DB schema, security model, architecture, constraints
  
• Only then delegate slices of that spec to AI tools to generate code
  

We’re calling it “spec-driven” or “schema-driven” development internally. And it feels a lot like some of the domain-driven design ideas from the 90s and 2000s that were arguably right… just waiting on the tooling to catch up. AI-enabled software product development is that tooling.

The upside is obvious: you get the speed of AI without losing the intentionality of real software engineering.

Tokens are cheap. Understanding is expensive.

Another mindset shift that Maximus articulated really well:

Generating tokens is cheap. Understanding is expensive.

In practice, that means:

• It’s often faster and cheaper to regenerate a chunk of code than to “rescue” a bad version
  If you gave an AI agent a vague prompt, let it thrash around, and ended up with a tangled mess, the right move is often to tighten the spec and start over (not ask it to patch the mess or edit code yourself).
  
• You keep the blast radius small
  Instead of turning an agent loose on your entire repo, you bound it to a small surface: a single service, a set of endpoints, a specific component. If it goes sideways, you roll back and try again.
  
• You treat checkpoints and guardrails as first-class citizens
  Tools like Cursor and Claude Code now support plan modes, checkpointing, context folders, etc. We lean on those hard. Every “run” happens inside clear constraints, with easy rollback.

There’s also a big implication for QA.

Traditionally, QA “rolled on” after Sprint Zero and ramped up as the system took shape. With AI in the mix, QA has to be in the room from the beginning:

• They help define what “correct” behavior looks like before code is generated
  
• They design tests and flows that will catch “approximately wrong” behavior
  
• They’re often the first line of defense against AI quietly generating features you never asked for
  

Craig described the shift nicely: instead of test-driven development, you get error-driven development. You assume the AI is going to be wrong in some interesting ways, and you build the traps that will tell you where.

To that end, AI-enabled software product development really requires a mindset shift in how you think about designing, building, delivering and deployment software… just not “what tool do I use for this task?”

The upside (and risk) of vibe-coded products

One of the more eye-opening stories was a client who came to us with a fairly sophisticated tool they’d built themselves using AI coding assistants.

They weren’t professional developers. But they:

• Were very technical in their own domain
  
• Were disciplined about how they decomposed problems
  
• Used tools like Cursor with real intentionality
  

The result was shockingly close to a real product. Not a toy. Not just a prototype. Something that, with some hardening, could credibly go to market.

That’s the upside. Domain experts can now get much further on their own (which is incredibly exciting).

The risk:

• The last 10–20% is where the landmines live: security, data integrity, performance, edge cases, maintainability.
  
• AI is great at creating “foot guns” — subtle mistakes you don’t notice until something blows up.
  Think exposing an admin key where a public key should be, or accidentally bypassing an auth check.
  

If you’re a founder or product owner who’s built a “vibe-coded” MVP, our advice is simple:

• Celebrate how far you got. That’s real progress.
  
• Get experienced engineers to review it early, not just at the end.
  
• Expect that some refactoring and cleanup is part of the journey; that’s not failure, that’s the cost of graduating from experiment to product.
  

What this means if you’re leading a software initiative

Whether you’re a startup founder, a CIO at a mid-market company, or an exec trying to get a new digital product off the ground, a few practical takeaways from what we’re seeing day-to-day in AI-enabled software product development:

• Use AI to aggressively shorten the distance from idea to real prototype
  Don’t stop at decks and Figma if you don’t have to. Get something real in users’ hands and learn from their behavior.
  
• Invest more in upfront clarity
  AI makes it cheap to go fast in the wrong direction. Tight specs, clear success criteria, and a thoughtful architecture are the safeguards.
  
• Design your systems for AI from the start
  Smaller services, clear boundaries, simpler stacks, opinionated platforms like Supabase where it makes sense… all of that makes it easier for AI agents to work safely and for humans to reason about what they’ve done.
  
• Treat QA and security as first-class from day one
  Assume AI will do surprising (and often unwelcomed) things at the edges. Build the tests and guardrails that will catch those surprises before your customers do.
  
• Don’t confuse “less typing” with “less engineering”
  We’re not seeing a world where you don’t need developers. We’re seeing a world where developers (and architects, and QA) operate differently… with AI as a powerful, opinionated junior partner they have to manage.
  

From where we sit, AI really is changing everything about how software gets built… but not in the simplistic “replace your team with a bot” way.

It’s changing what’s economically feasible to prototype, how quickly you can validate hypotheses in the real world, and where human expertise creates the most leverage.

If you’re trying to figure out what AI-enabled software product development could look like for your team (and how to get the upside without stepping on the landmines), that’s exactly the kind of problem we love working on.