Why I wrote up the AI-native SDLC case study

I just published a case study I almost didn’t write, because the interesting part of it isn’t a migration. It’s an argument I had to win against my own first draft before it ever reached leadership.

Here’s the setup. A Tebra product team had built a new AI-native clinical product at unusual speed on an edge-compute platform. A migration onto a new cloud platform was on the table, and the question that came down to me was simple: how long will the migration take?

I gave a different answer. Moving the code is the known, easy part. The hard part is recreating, on the new platform, the instrumentation and the way of working that made AI-native speed possible on the old one. Instead of asserting that and moving on, I put it under six days of formal adversarial test, and the raw version of my claim didn’t survive intact. It hardened into something narrower: the migration and agent enablement are one coordinated program, not one indivisible project.

That correction, made to my own argument before it reached the room, is the case study.

What shipping with agents actually looked like

I read the requirements roadmap, 104 requirements deep, as migration-timing evidence in its own right, and drafted a three-option sequencing straw man within hours of the strategy meeting so the room had something concrete to react to. On the reaction call, I conceded one of my own options on the spot when a teammate’s argument beat it.

Then I drove the definition of the harness itself: not a deploy pipeline, but the controls that let humans and agents build together without losing the thread. Autonomy gates, so agents never deploy to production and a human always owns the merge and the release. Typed run contracts and a mandatory dry-run with explicit stop conditions: failing diagnostics, an unknown component, a blocked quality gate, an unclear rollback path. An apply-audit trail on every applied change, plus a browser-verification gate before anything counts as done rather than merely written.

None of the positions behind that harness reached the room raw. I drafted a claim, handed it to independent AI agents whose only job was to break it (one auditing every citation live, one steelmanning the strongest opposing read), and adjudicated the conflict into a single hardened document: what broke, what survived, what the corrected claim now was. Over six days that produced at least fifteen adversarial and validation reports feeding six adjudicated hardened verdicts. In one pass, 38 external URLs and 31 quotes got checked live, and a fabricated quote was caught and pulled before it reached an executive-bound export.

What a design leader evaluating AI-native claims should look at first

Skip the harness diagram at first and go straight to the “Decision quality” section. That’s where the case study either holds up or doesn’t: it’s the part where I ran the same evaluation discipline against my own arguments that I was asking engineering to adopt against its code. If an AI-native claim on a resume or a portfolio can’t show you the governance behind the claim, not just the artifact, it’s marketing.

Then look at what actually changed. Leadership’s ask moved from a migration timing estimate to prioritizing the requirements gap. The room converged, in its own words, on a bounded MVP of the AI-native SDLC as the thing that would gate cutover: not migrate-then-figure-it-out, but prove the way of working survives the crossing first. What’s left behind is durable: a one-page operating model built on a falsifiable first-slice contract (baseline the incumbent platform, run one bounded slice on the target platform, measure it against stated thresholds, then decide), and an interactive briefing site a cross-functional room could actually use.

I’m not going to oversell this post. The case study is the proof, this is just the pointer. Read the whole thing here: the AI-native operating model case study.