The Shift

The biggest change AI has introduced to software development isn’t speed. It’s that the conviction threshold required to build has collapsed.

When I was at Optum, “failing fast” meant getting a prototype out in 2 to 4 weeks. When I was at Harvard Business School, hypothesis testing meant finding the cheapest possible way to learn. Both ideas still matter. But AI has compressed that loop so dramatically that one person can now notice a problem, sketch the behavior of a minimum viable product, have an agent build a first version, and start using it the same day.

In many cases now, you might as well build it and see.

Not because planning no longer matters. Not because architecture is dead. But because for a growing class of internal tools and operational software, building is no longer the expensive step that comes after conviction.

Building is how conviction gets formed.

A Reconciliation Problem I Couldn’t Ignore

I ran into this directly during our quarterly revenue close.

The problem was ugly in a very specific way. Members might enroll in December for a January effective date. We might not see the carrier commission statement until February. We might not get paid until March.

And because this is an Individual Coverage Health Reimbursement Arrangement (ICHRA) model, employers sponsor the benefit but employees choose across different carriers and plans. That creates a messy many-to-many mapping: one carrier statement can include members from multiple companies, and one company can be spread across multiple carriers.

You do not need to know the details of health insurance to see the core problem. The revenue trail runs across enrollments, carrier statements, and bank deposits, and those systems do not line up cleanly.

The question sounds simple: did we get paid what we should have gotten paid?

The actual reconciliation workflow behind that question is not simple at all.

So I built an internal reconciliation app.

It started with one goal: make it possible to trace what should have happened, what the carrier said would happen, and what actually hit the bank. The app pulled enrollment data from our system of record, parsed carrier contracts into machine-readable commission rules, ingested carrier commission statements, matched expected payments against actual statements, flagged discrepancies, drafted dispute emails, tied bank transactions back to statements, aged receivables, and exported what accounting needed to close the month.

I didn't set out to build all of that.

I set out to solve a problem. Then the next problem surfaced. Then the next one. Once the first slice existed, the bottlenecks became obvious.

Within less than a week, I had a full-featured internal revenue reconciliation, carrier payment dispute, and accounting workflow tool. I built the initial version myself while still doing the rest of my job as CEO. Once it became clear this could help our carrier relations team too, we started iterating on it together.

That's the part I think matters.

From Design-First to Learning-First

This isn't just “AI makes coding faster.” It is a change in the process shape of software development.

The old model was more design-first: study the problem, specify the requirements, map the edge cases, and then build. For a growing class of problems, especially internal tools, workflow software, and operational systems, the better model is becoming more goal-driven, exploratory, and learning-first. Closer to discovery-driven engineering than traditional document-first development.

Start with the outcome. Build a thin slice immediately. Use working software to discover the real requirements. Let the design emerge from code, output, and feedback instead of assuming you can think your way to the right system upfront.

That's the shift I keep noticing.

A lot of the edge cases that used to get debated abstractly now show up faster and more clearly when the software is real. A lot of the requirements that used to live in product requirements docs now reveal themselves through usage. A lot of the user experience decisions that used to be overdebated in mocks can now be settled by building and reacting.

On the overview page for this tool alone, I did three back-to-back iterations. I didn't sit around trying to conceptualize the perfect experience. I built one, used it, reacted to it, rebuilt it, and repeated.

Build it. React to it. Rebuild it. Repeat until it feels right.

That used to sound sloppy. Increasingly, it feels rational.

Large language models did not invent iteration. They changed the economics of iteration. They collapsed the marginal cost of an experiment, reduced the amount of scaffolding and boilerplate required to try something, and made the specification process far more conversational. When that happens, “learn by building” stops being a niche move and starts becoming the default for problems that previously were not worth a formal software project.

One person can now function like a surprisingly capable product, design, and engineering team for a large class of problems. Notice a pain point. Work through the product logic with an AI agent. Have another agent build the first version. Start using it in your actual workflow an hour later. Find what breaks. Fix it. Expand it. Prune what does not matter. Keep moving.

The time window on “fail fast” and “hypothesis test cheaply” has become infinitesimally small.

That changes founder behavior. It changes operator behavior. It changes which problems are worth solving in software at all.

The conviction threshold required to build an app is now so low that, in many cases, you might as well build it and see.

Exploration First, Commitment After

None of this means serious engineering discipline goes away.

Pure exploratory development can absolutely give you working code before you have a coherent system. AI makes that easier too. You can accumulate local fixes that demo well but do not add up to a durable architecture.

That is why the right model is not “no design.” It's exploration first, then commitment.

Use rapid iteration to collapse uncertainty. Then do the hardening pass: refactor the system, carve stable interfaces, add tests, lock down invariants, and make it trustworthy. The best teams separate exploration from commitment. They don't confuse a fast prototype with a finished architecture.

But the important change is still the same:

Building is no longer the expensive step that happens after conviction.

Building is how conviction gets formed.

And once you internalize that, you start looking at your company differently. You stop asking whether a problem is important enough to justify building software for it.

You start asking why you are not building software for it already.

Lucas Hearn, CEO & Co-founder of Kyra Health