Building with AI is not like building software. Here's what's actually different.

Most founders who come from a traditional software background try to apply the same intuitions to building AI products. They scope requirements, estimate timelines, write tests, ship incrementally. Some of this transfers. A lot of it doesn't. The mismatches are subtle and expensive.

This isn't about using a different tech stack. It's about the fundamental nature of what you're building: a system whose core behaviour you don't fully control and whose capabilities change underneath you, often dramatically, on someone else's schedule.

The floor moves

In traditional software, the primitives are stable. A database query behaves the same way today as it did six months ago. A function you wrote last year still returns the same output for the same input. You can build confidently on top of things that don't change.

With AI, the foundation shifts. A model update can improve your product dramatically or break a behaviour you were depending on. OpenAI, Anthropic, and Google ship meaningful capability changes on a cadence that no enterprise software vendor has ever attempted. That's mostly a gift, but it means your product has a moving baseline.

The practical implication: you need evaluation infrastructure before you need much else. Not formal benchmarks, necessarily, but a disciplined way of knowing when model behaviour changes in ways that matter to your users. Founders who skip this step discover the problem at the worst possible time.

You can't fully unit test intelligence

1. The output space is too large

Traditional testing works by enumerating expected outputs for known inputs. AI outputs are probabilistic and high-dimensional. You can test that a response stays under a certain length, or contains a required field, or doesn't include a banned phrase. You cannot easily test that it's good. "Good" is a judgment call, and judgment calls don't compile.

2. Regression is ambiguous

In software, a regression is clear: something that worked before no longer works. In AI products, a model update might make most outputs better but worse for a specific edge case your heaviest users depend on. Knowing whether something is a regression requires human evaluation, and human evaluation doesn't scale easily.

3. Prompts are code, but they behave differently

Prompt engineering is real engineering, but it has properties that make software engineers uncomfortable. Small wording changes can have large effects. Changes that improve performance on one class of inputs can degrade it on another. There's no compiler to catch errors before they reach production.

Speed and certainty trade differently

In software, moving faster usually means accruing technical debt: shortcuts that slow you down later. In AI product development, moving faster often means staying closer to the model's native capabilities and investing less in custom infrastructure. The teams that move fastest are frequently the ones who've resisted the urge to build complex orchestration layers and instead let the model do more of the work.

This inverts a classic engineering instinct. The answer to "we need more control" is often not to build more infrastructure but to iterate on the prompt, improve the evaluation set, and upgrade the model.

What this means for how you build

None of this means AI products are impossible to build rigorously. It means the rigour looks different. Invest early in evaluation. Treat prompts as versioned artefacts. Build feedback loops that surface real user signal quickly. And stay close to the model capabilities, because the team with the best intuition for what the model can do right now, not six months ago, will consistently make better product decisions.

The founders who are struggling aren't necessarily slower or less skilled. They're often applying the right practices from the wrong mental model.