AI Isn't Making Software Development Reckless. It's Making It More Disciplined.
There's a story people tell about AI and software right now, and it goes something like this. A developer types a vague wish into a chatbot, code appears by magic, nobody really understands it, and the whole thing ships on a hope and a prayer. The internet has a name for it: "vibe coding." For anyone responsible for a real product, and especially for anyone in a regulated field like healthcare, it sounds less like progress and more like a liability waiting to happen.
I understand the worry. I also think it has the story backwards.
Done properly, AI-assisted software development is not less disciplined than the traditional approach. It is more disciplined. It has to be.
Where the discipline used to live
Traditional software delivery front-loaded its rigor. Teams spent weeks, sometimes months, writing detailed requirements and specifications before anyone wrote a line of code. The logic was sound for its time. Writing and changing code was slow and expensive, so you tried to get everything right on paper first. The specification was the safety net.
That model quietly assumed the risky, expensive step was building. So most of the control lived at the front, in documents.
What actually changed
AI changed the economics. A working version of a feature that used to take a week can now take hours. When building becomes cheap and fast, the upfront specification stops being the thing that protects you. You no longer have to imagine the software in a document, because you can look at the real thing almost immediately.
This is the part the chaos narrative misses. When a team can produce many times more working software in the same period, it also produces many times more things that need to be checked. The bottleneck moves. It is no longer typing the code. It is reviewing it, testing it, deciding whether it should exist at all, and making sure it is safe. The discipline does not disappear. It relocates, from paperwork at the start to verification all the way through.
And relocated discipline is still discipline. Arguably there is more of it.
More checks, not fewer
Consider what a serious AI-assisted team actually does. Every change, no matter how quickly it was produced, goes through a real human review before it counts for anything. Automated tests and evaluations are written alongside the work, often before it, so the team can prove a feature behaves correctly rather than assume it does. Nothing reaches production without passing those checks. In regulated domains, security and compliance requirements are not waved through because the code arrived faster. They are enforced at the same gates they always were, and often more consistently, because the checks are automated and run continuously.
The volume of change goes up, so the process around each change has to get tighter, not looser. A team that skips review because "the AI wrote it" is not doing modern development. It is doing the reckless thing everyone fears, and it will get the results everyone fears.
What "no process" really looked like
A good illustration made the rounds recently. The CTO of Gusto, a payroll and HR company serving hundreds of thousands of small businesses, described how a team of five rebuilt a product in ten weeks using these tools. On the surface it sounds like exactly the chaos the skeptics warn about: no thick specification documents, no traditional project-tracking board, a tiny team, a blistering pace.
Look closer and the opposite is true. Every feature went through a genuine pull request and a human code review before it was accepted. Work that did not meet the bar was deleted rather than shipped. For the trickiest behavior, engineers wrote a test that failed first, then made it pass, then confirmed nothing else broke. What looked like the absence of process was actually process concentrated where it matters most: on working software and rigorous review, instead of on documents describing software that did not exist yet.
They did not remove the discipline. They moved it to the part that determines whether the product is actually any good.
Prototyping is not shipping
This is the distinction that keeps getting lost. Quickly prototyping an idea to see whether it is worth pursuing is a legitimate and useful thing. It is also not the same as shipping a product. A prototype is a question. A production system is an answer, and it still has to pass every check it always did before real people depend on it. Confusing the two is what gives "vibe coding" its bad name. The professionals are not confused about the difference.
Why this matters most in healthcare
In healthcare software the stakes make all of this obvious. When a system touches patient data, clinical decisions, or payments, "we moved fast" is never an acceptable answer to "did you verify it." The encouraging part is that AI-assisted development, done well, tends to strengthen verification rather than weaken it, because testing and evaluation become continuous rather than a phase squeezed in near the end. Speed and rigor are not in tension here. The rigor is what makes the speed safe to use.
At Vicert, this is why we have leaned into this way of building rather than treating it as a novelty. The organizations we work with cannot trade correctness for speed, and they should not have to. The shift underway is not from order to chaos. It is from discipline you perform once, on paper, to discipline you perform constantly, on the real thing. For anyone serious about building software that has to work, that is a change worth welcoming.