How David Bellairian's Team Builds Software: Inside the AI-Assisted Engineering Process

David Bellairian's product team is deep into building a new software product. The product itself is under a non-disclosure agreement, so this post won't describe what it does or who it's for. What it can share is the methodology, because the process behind it is a real-world example of what "lean, AI-adopted" actually looks like day to day, not just as a talking point. The work runs on structured specs, heavy AI-assisted execution, and a testing discipline that would be expensive to staff for at a traditional software shop.

The process itself is methodical almost to a fault. Work moves through numbered, written specifications — one section built, verified, committed, and deployed before the next one starts. Nothing ships without running against automated test suites that routinely execute dozens of checks per feature, across both debug and release builds, before a single commit goes out. It's the kind of rigor usually associated with much larger engineering organizations, made possible for a small team because AI handles the volume — writing the tests, running them, and flagging what breaks — while human judgment stays on the decisions that actually require it.

That discipline catches things that would otherwise slip through. In one recent session, a routine code change compiled cleanly but silently altered how a handful of unrelated comparisons behaved elsewhere in the app — the kind of bug that passes every build check and only shows up once a user hits the exact case, if it ever gets noticed at all. It was caught before it reached production because the process treats "it builds" as the start of verification, not the end of it.

There's also a founder-in-the-loop rigor to how business rules get decided. Rather than assuming a proposed simplification is correct because it sounds reasonable, the process checks whether a given rule exists for a legal, financial, or purely organizational reason before touching it — and in at least one case, that check surfaced a flaw in the team's own prior implementation, which got corrected on the spot rather than shipped as-is. The standard isn't "does this look right," it's "does this hold up once we actually check."

Some of the more important fixes have been the invisible kind: a data-reliability issue in early testing, where a specific class of time-sensitive records could have been lost between deployments under the wrong configuration, was caught, fixed, and proven end-to-end on production before it ever touched a real user. The team also tightened how repeat identity verification works for returning users, so someone who has already verified isn't re-billed or re-checked every time — and no raw identification numbers are stored anywhere in the system at any point.

That last piece is where the methodology earns its keep. It's easy to talk about building something more user-friendly than the incumbents in any category. What's harder is holding a real product to a "never strand a paying customer, never lose a record, never overcharge on verification" standard through every edge case an engineering team finds — and that's the bar this process is actually being held to.

None of this happens with a large team. It happens because AI is doing the heavy lifting on execution and verification, while a small group of people make the calls that actually need a human — which is exactly the model Glencore Associates and AIDiscover are betting the next generation of software will run on.