By Joe Widi, VP of R&D, Verisma
August 28, 2026
Every engineering leader is being asked some version of the same question: What does artificial intelligence (AI) change about how software gets built? Most of the honest answers are still speculative. Ours isn’t. We spent the first quarter of 2026 rebuilding our software development lifecycle (SDLC) around AI as a first-class participant, and on April 1 began moving our development teams onto it. This is what we’ve learned in the 100 days since.
Verisma builds and operates health information technology (HIT) used by health systems. That context shapes everything here. We weren’t looking for the fastest possible way to ship code. We were looking for the right way to change how software gets built in a regulated industry, where the cost of getting it wrong isn’t a bad retrospective — it’s a client’s operations.
The Diagnosis: The Constraint Didn’t Disappear. It Moved.
Sprints, standups, story points — most of modern software process is scaffolding built around one assumption: humans writing code is slow, expensive, and hard to redirect once it’s underway. Nearly every ceremony we inherited over the last two decades exists to manage that constraint gracefully.
AI dissolved it. Agents can produce a working specification, a test plan, and an implementation in minutes. That left us with a decision every engineering organization is facing whether they’ve named it yet or not: layer AI onto the process you already have and get a faster version of the same thing or treat this as enough of a shift in the cost of software to rebuild the process itself.
We chose the second path. From January through March, we ran the experiment — new tooling, a rethink of how requirements and design get produced, a reconsideration of what’s worth measuring once the old proxies for progress stop meaning what they used to. We began migrating our development teams onto the result.
Removing the old constraint didn’t remove friction. It relocated it to two places that used to be background costs and are now the whole game:
Judgment — how fast, and well, humans make decisions. AI can generate ten specs before lunch, but it can’t make a human validate the intent behind any of them any faster. Every review point in the new process is a judgment call, and the quality of the organization is much more visibly a function of the quality of those calls.
Governance — what it costs to move something from “code complete” to “in production” safely. That cost was never zero; most organizations have never measured it apart from development time. In a regulated industry, it has always been the real constraint. AI just made it impossible to keep ignoring.
That lens became the organizing principle: in an AI-enabled SDLC, the central constraints are no longer how fast code can be written. They’re how well decisions are made and responsible change moves into production.
Pipeline One: Product — Where the Hard Thinking Happens First
By the time a developer touches a work item, most of the hard thinking about it is already finished.
The old failure mode is familiar to any engineering leader: a product manager writes a ticket, a developer picks it up, and a meaningful fraction of the real requirements surface once someone is already mid-implementation. Every one of those discoveries is an unplanned delay, and they compound across the feature in ways hard to see until velocity quietly erodes.
We moved that discovery upstream. Before a developer is involved, an AI-assisted process works alongside the product owner to draft and pressure-test requirements, develops the user experience in parallel (rather than after), and carries the result into a full test plan and, ultimately, a technical design — each stage reviewed and gated the way a senior human reviewer would, just faster and more consistently. Complexity gets scored objectively along the way, using function-point-style analysis rather than a room of engineers estimating by feel — the real replacement for story pointing. Not a faster planning meeting. No planning meeting: a number derived from the shape of the work, refined automatically as the design gets more detailed.
One sequencing choice matters more than it sounds like it should: test cases get defined before the technical design exists, not after. The design must answer how the work will be proven correct, not just how it’ll be built. And nothing advances on an AI draft alone. Development, quality assurance (QA), data, infrastructure, security, and product have a checkpoint in that sequence, so alignment happens before a release is on the calendar, not as a surprise once it is.
Is this just waterfall wearing new clothes? Structurally, yes — sequential phases, full specification before implementation, a gate at each step. We’d rather name that resemblance than pretend it isn’t there. But the two things that killed waterfall don’t apply here. Waterfall failed because each phase took months, and a wrong requirement wasn’t discovered until a quarter of investment was already sunk into it. Here, the same sequence for one unit of work runs in hours — a bad guess costs an afternoon, maybe days, not a quarter. And waterfall assessed last; we test first. This isn’t one big waterfall. It’s a lot of very small, fast ones — slight enough that being wrong is cheap again.
None of this is process for its own sake. It’s the guardrail that lets AI build against something solid instead of inferring intent from a two-sentence ticket — and it’s what makes the next pipeline trustworthy.
Pipeline Two: Development —Decisions Replace Implementation as the Bottleneck
Once a spec and test plan exist, the developer’s job changes shape — more than most engineering leaders expect.
A coordinating layer takes the work item — already carrying its share of the requirements, design, and test plan — and breaks it into an executable spec. An implementation agent builds against it. Before a human sees the result, an independent reviewing agent checks the work and iterates with the implementation agent until every issue it finds is resolved. Only after that loop closes, and after the code clears linting, unit tests, security scanning, integration tests, and end-to-end tests, does it reach a developer at all — as a pull request, ready for a decision rather than a first pass.
The developer’s role here was never really “write the code.” It’s render judgment: on the spec, the pull request, then — once intent is validated — whether the work is ready to wait for a release. Each of those is a named decision, not an activity, and our boards say so explicitly: no “In Progress” or “QA” columns, but “Awaiting Code Review” and “Awaiting Intent Validation.” The question isn’t what phase something is in. It’s whose decision it’s waiting on — and the discipline keeping that meaningful is simple: clear your decision queue daily, with a 24-hour target.
That discipline changes what needs limiting. Work-in-progress limits existed because a developer holding three implementations in their head at once could make mistakes — the context-switching cost was real. Agents hold that state now, so running several in parallel costs a developer nothing. What accumulates is decisions: spec and pull requests to review, and validations for sign off. The health signal isn’t “how much is this person building” anymore. It’s how many decisions are sitting in someone’s queue, and how long they’ve been sitting there.
Pipeline Three: Release — The Deliberate Bottleneck
We didn’t build our release pipeline to be fast. We built it to be its own bottleneck, on purpose, and measured separately from everything upstream of it.
Once a feature is merged and selected for release, the question isn’t whether the code works. Development already answered that. It’s whether, when and how it’s safe to put in front of clients running a health system on this software. We track product, development, and release separately so we always know where to look when something slows down, instead of assuming development is the bottleneck just because that used to be true. AI made development fast. If release weren’t measured on its own, we’d keep mistaking a governance constraint for a development one. As a result, we’d be trying to fix the wrong piece of the puzzle.
A release isn’t ready when the code is. It’s ready when the business is. Release dates get set with enough lead time to notify people who need to know, train anyone who needs it, and place downtime around what clients require, not our own development schedule. AI writing code faster doesn’t buy a shortcut through our release process, nor should it.
This is what governance constraint looks like in practice. Not slowdown for its own sake. Machinery making it responsible to move as fast as AI now moves upstream of it. In a regulated industry, that’s not overhead. It’s the whole point.
The Dashboard: What We Can Finally See
Eight metrics drive our view of this system, across three categories, calculated automatically off the board (rather than assembled by hand). That matters more than it sounds like it should: clean data is a prerequisite for a trustworthy signal, and AI made clean data a side effect of doing the work rather than a discipline someone must remember. Nobody needs to remember a reporting process. They need to use the tooling, and the data falls out correctly because of how it’s built.
Delivery asks whether speed is landing in the calendar, not just inside an agent’s context window — pipeline time by stage, and how accurately we hit committed release dates.
Quality asks whether AI-generated work is held to the same bar as before, or a higher one — the rate of defects escaping into later stages, how often work gets sent back for rework and QA catches something before a client does.
Engineering Discipline asks whether the organization is operating the way we’ve described here. Not just on paper — how often work is ready before it starts, “done” holds up under scrutiny, and how quickly decisions are made once they’re in queue. This category exists because the other two are only as good as the data feeding them. Clean data is a discipline, not an accident.
Day 100. Some of the metrics are where we want them. Others are catching up, particularly around verifying older parts of our codebase as fast as agents can now generate changes against it. That gap is real, it’s being worked, and exactly what this dashboard exists to catch early (rather than discover later).
That’s the right place to be 100 days into migrating an entire organization. Not a pilot team onto a new operating model. Growing pains are supposed to show up in metrics before the process fully absorbs them. That’s what metrics are for.
Should You Implement This?
Not a blanket yes. Before touching process, ask four questions honestly:
1. Are your AI tooling and practices mature enough to warrant a change of this scale, or is appetite ahead of readiness?
2. Can you tolerate metrics that look unflattering to the people who’ll ask you about them?
3. Have you identified your organization’s real constraints, or optimizing a proxy?
4. And if you have, would a change like this move those constraints, or relocate the same friction somewhere less visible?
Start with measurement, not process. It isn’t possible to responsibly redesign around a constraint you haven’t first proven exists.
