AI Won't Fix Your Healthcare IT Organization. It Will Expose It.

A CIO at a large integrated health system asked me to help his company rewrite its SDLC with AI as the anchor. He wanted a modern engineering process, built around AI tools, that his teams could adopt. He feels the pressure to make changes and wants to know how to move.

I told him we could absolutely help him do that. But I also told him the thing he asked for was not the thing he actually needed. What he needed was change management. He needed alignment on his teams and a real plan for those who would not want to come along.

If you are leading technology at a large healthcare organization right now, the same conversation is waiting for you. Whether you are a CIO at a health system, a CTO at a payer, a VP of Engineering at an enterprise division, or running a digital health business unit, the pressure feels the same.

Your inbox is full of AI vendors. Your board or your parent company is asking for an AI strategy. Your peers at competing organizations are quoting productivity numbers that probably are not real.

I have sympathy for the seat you are in. And I have a hard truth to share with you.

AI is not going to save you. It is going to expose you.

Here's what the data is already saying out loud.

Last week, I read the third part of Gergely Orosz's series in The Pragmatic Engineer on the impact of AI on software engineers in 2026. He and Elin Nilsson surveyed more than 900 working engineers. One quote from the data captures it better than anything I could write:

"AI is an amplifier, not a fixer. Good software engineering practices get multiplied. So do the bad ones." — Staff+ engineer at a large European company

I would print that on a card and tape it to your desk.

The survey is showing a clear pattern. Codebase quality is going down at most companies. Bugs are up, duplicated code is everywhere, and contributions keep landing in systems the contributors do not understand. A 10,000-person company in Europe rolled back parts of its AI tooling after senior engineers' work product dropped off a cliff and production incidents climbed.

One principal DevOps engineer in the survey said it plainly:

"In our company, we hand AI tools to inexperienced engineers who can't distinguish good code from bad code, and it's falling on deaf ears in our leadership. They only seem to care about short-term to mid-term cost savings."

That is not a tooling problem. That is a leadership problem. And it is the same problem about to play out inside large healthcare organizations at a much greater scale.

I am hearing this from both sides of the table.

I recently had a meeting with a strategic consultancy that advises a group of technology providers serving national health plans. I shared a version of the amplifier point with their lead. She told me that is exactly what they are seeing across their clients, and exactly what they are now telling those clients out loud.

There were two sources, looking at this from two different sides of the table, telling me the same thing in the same week. The CIO was trying to anchor his SDLC on AI. The consultancy was watching their clients try to bolt AI onto health plan software. Same pattern.

The places that already had good engineering practices are accelerating. The places that did not are generating more output, more bugs, more rework, and more quiet little production incidents than they were a year ago.

This is why healthcare IT organizations will struggle most.

Large healthcare organizations, from health systems to payers to enterprise digital health divisions, have spent decades building IT organizations to do the opposite of what AI demands.

You built them to be careful. You built them to not break things. You built them around HIPAA, HITRUST, FDA, CMS, and the very real risk that a software bug can become a patient safety event. That caution is correct. I would not change it.

But over those decades, that caution turned into something else. It turned into a process for the sake of process, like approval boards on top of approval boards. Maybe six-month release cycles for systems that the rest of the industry deploys in hours. Or it could mean teams who got very good at saying no, and never had to learn how to say yes carefully.

I believe what AI is going to do, more than anything else, is shine a very bright light on those years of accumulated debt.

Process debt. Communication debt. Documentation that nobody has read in five years. And the castles of control your internal teams have quietly built up over time, where one person knows the system, one team owns the gate, and nothing moves without their blessing.

AI does not care about castles. AI exposes them.

I have started to watch this pattern.

I have watched this start to play out at several healthcare organizations over the last year, and the shape of it is depressingly consistent.

It usually begins with pressure from above, say the board, or the parent company that owns you. The senior technology leader gets the AI mandate, builds a strategy slide, and stands up a pilot. The directive then goes down to engineering and IT. Adopt the tools. Show productivity gains the board can put on a slide. Some teams comply. Output goes up on paper. So do errors, rework, and the production incidents nobody wants to write up in detail.

When the in-house effort stalls, the CIO calls the trusted name-brand consultancy that has been on the preferred vendor list for a decade. That firm sends a team that is wrestling with the same AI adoption problems inside their own organization. Six months later, there is a beautiful slide deck and an invoice with a comma in it. Not much real movement to show for either of them.

That is the moment the frustration sets in. Board members ask harder questions. The CIO is exhausted. The teams are cynical. And the original problem, the one underneath the AI conversation, is still sitting there waiting.

The original problem was never AI. The original problem was that the engineering culture of the organization could not absorb change at the speed the market is now demanding. AI just made that fact harder to hide.

What does good look like?

The good news is that there is a way through this that doesn't require you to become someone you are not.

At Atomic, we have been running AI agents inside our normal delivery practice for a while now. We are shipping faster than we did two years ago, and we have not seen the quality drop the survey describes.

I do not believe that is because Atomic developers are unusually talented, though many of them are. I believe it is because the practices we already had in place are the ones that make AI work. Small teams. Strong code review. Automated tests. Pairing. Written conventions. Honest retrospectives. People who actually own the code they ship.

AI did not create any of that. It rode on top of it.

When we walk into a healthcare organization with those practices, the work moves. Not because we are magicians. Because we are modeling the operating system the organization actually needs to install.

What's the honest path forward?

Remember the CIO I described at the top. He asked for an SDLC rewrite. I told him he had a change management problem. Both of us were right. The engineering practice has to change. And you cannot change the practice without changing the behavior of the people inside it.

I believe there are two things any senior technology leader in a large healthcare organization must do to get out of this loop, and neither is easy.

Start here first.

The first is to stop hiring the partners you have always hired and start working with a consultancy that has spent the last twenty years proving it can deliver quality while moving fast. A team that already builds the way you need your organization to build. You do not need another strategy deck. You need a working software product, shipped in a cycle you would have called impossible a year ago, by people who do not panic when the codebase gets ugly.

That working product is the artifact that changes minds inside your organization. It is also the artifact that exposes which of your internal people are going to come along with the change, and which ones aren't.

Take the next hard step.

The second is the harder one. You are going to have to make tough calls about the people inside your organization who are protecting their castles.

This is the tough stuff. The kind of decision you do not put on a slide. I do not say it lightly. These are often long-tenured, well-respected senior people, and the institution has organized itself around them in ways nobody fully maps until they are gone. They earned their position through years of competent work in a model that was correct for its time.

But the model isn't correct anymore. And if you keep paying salaries to people whose primary contribution is slowing down change, the change is not going to happen. Your board will figure that out eventually. Your competitors already have.

I have watched this play out. The CIOs who succeed are the ones who back up their delivery partner publicly, support the people leaning into the new way, have the difficult conversations with the people who refuse to, and stay in the room when the politics get loud.

The CIOs who fail are the ones who try to keep everyone happy.

The light is coming on.

If you are leading technology at a large healthcare organization, the light is coming on whether you turn it on yourself or not.

You can run the exposure carefully and deliberately, with a partner who already knows how to deliver quality while moving fast, and with the courage to change the people inside who will not change with you. Or you can wait until the market and a few public failures do the exposing for you.

I know which one I would pick.