For healthcare, fintech, pharma, insurance, and other regulated companies, implementation has gotten so much faster. What’s becoming even more valuable is judgment, knowing what to build, how fast to move, and where you can’t afford to be wrong.

For a long time, one of the most common reactions to a software team that wasn’t moving fast enough was to add more developers. The bar for adding more developers is much higher now. AI has changed how quickly software can be produced, and coding agents can build working software at a pace that would have been inconceivable a few years ago.

That’s great news for product companies building software, but faster implementation puts even more pressure on teams to make good decisions about what gets built in the first place.

The harder work is actually knowing what should be built, what can safely be skipped, and which seemingly logical decision today becomes an expensive problem tomorrow. Those questions matter everywhere, but especially in healthcare, fintech, insurance, pharma, and other regulated industries. These companies don’t have the luxury of choosing between speed and safety. They have competitors moving quickly, legacy systems that aren’t going anywhere, and regulators who don’t particularly care how ambitious their roadmap is.

So when an important initiative isn’t moving fast enough, I wouldn’t start by asking how many developers you need. I’d ask what capability your team is missing and what’s the fastest responsible way to add it. Sometimes the answer is hiring internally, sometimes it’s team augmentation with an experienced consultancy like thoughtbot, and sometimes it isn’t another developer at all.

AI should make experienced developers more valuable, not less

We’ve been exploring what AI-assisted development should actually mean, and I think the least interesting question is who physically writes the code. A good developer should absolutely use AI to produce code faster where it makes sense, but an experienced developer should use that leverage for a lot more. AI should help experienced people understand faster, find risk earlier, and show up each day better prepared.

One of our developers recently described his current approach as having AI write nearly all of the code while he remains deeply involved. He directs the work, reviews decisions, and applies expert judgment throughout. His point was that the value comes from being in the loop, not stepping out of it, and that feels exactly right to me.

AI can propose an implementation, but it doesn’t own the consequences if that implementation exposes PHI or creates an auditability problem. It doesn’t have to explain to customers why you just spent six months building the wrong thing. AI can accelerate our work, but someone still has to be accountable for whether the work makes sense.

That’s also why I’m a big believer in using prototypes to reduce risk before the expensive implementation begins. As implementation gets cheaper, judgment gets more valuable.

The best teams know where they can afford to move fast

We recently commissioned independent research with 168 engineering, product, and technology leaders across U.S. healthcare organizations. 68% said they struggle to increase delivery velocity without introducing risk, while 94% said they value teams that ship reliably over teams that simply move quickly. You can explore the findings in our State of Software Delivery in Healthcare report and our summary of what we learned.

I don’t think the lesson is that regulated companies should move slower. They need to get much better at knowing where they can move fast. An internal tool used by ten employees can tolerate risks that software handling protected health information can’t. Experience should make a team better at understanding that difference, not make it more conservative.

We heard a version of this in our recent roundtable with David Pace, Executive Director of Research Labs IT Enablement and User Experience at Merck. Modern enterprise software doesn’t give you the luxury of solving modernization, AI, security, and governance one at a time, it makes them collide.

That’s where seniority matters. Not because experienced people write more code, but because they’re more likely to recognize expensive mistakes before you make them. In regulated industries, that judgment becomes part of the development capability itself. A team needs to understand not only how to implement a solution, but how privacy, security, compliance, existing architecture, and real-world workflows change what a responsible solution looks like.

Before you hire another developer, make sure development is really the problem

When delivery slows down, it’s tempting to turn it into a capacity equation. We have this much work, we have this many developers, therefore we need moar developers. When you’re a hammer, everything looks like a nail.

If engineers are waiting on product decisions, another developer doesn’t remove the constraint. If customers aren’t adopting what you’re shipping, more engineering capacity just helps you build the wrong thing even faster. If a modernization initiative keeps stalling on architecture, adding implementation capacity is still solving the wrong problem. Headcount is not the diagnosis.

Companies should build great internal teams. If a capability is core to your organization and you know you’ll need it for years, hire. I’ve written more about this in When to build an in-house engineering team and when to hire an agency. But today’s capability gap doesn’t need to become tomorrow’s headcount. My rule is to hire for ownership and augment for capability, and sometimes you should do both.

Experienced team augmentation should mean bringing senior developers, product managers, designers, or technical leaders into an existing team to add capability, not just capacity. The right people shouldn’t create another management job for your leaders. They should help figure out why the work isn’t moving in the first place.

A company may believe it needs three developers and discover that an experienced developer and product manager would remove even more constraints. Another may actually need a designer and developer. AI makes these smaller, experienced teams even more interesting because each person can now operate with even more leverage than they could a few years ago.

I’m skeptical of folks who believe one AI-enabled developer suddenly replaces ten people, but I’m equally skeptical that the team structures we built in the before-times are automatically the right ones now. The better question is what combination of people and capabilities gives you the best chance of solving the actual problem.

What should you look for when adding software development capability in a regulated industry?

If I were evaluating people to add software development capability in a regulated industry, I’d want to understand how quickly they can become useful, how they use AI, and how they think when privacy, security, or regulatory requirements complicate the obvious answer. I’d also want to know what happens when we disagree.

That last question matters to me. I don’t want experienced people who agree with every decision I make. I want people who can disagree thoughtfully, explain why, test an assumption when possible, and then commit to the decision the team makes together.

I’d also want evidence that they understand the difference between moving quickly and moving recklessly. In regulated environments, the best teams shouldn’t apply the same level of caution to every decision. They should know which decisions are easy to reverse, which carry meaningful privacy, security, or regulatory consequences, and when a prototype or smaller experiment can answer the important question before a larger investment is made.

Our healthcare research found that 89% of technology leaders believe accelerating delivery depends on external trusted software partners. If you’re trying to understand what’s actually constraining your own organization, give our Software Delivery Self-Assessment a try to help identify where your team may be getting stuck.

AI is going to keep making software faster and cheaper to produce. For healthcare, fintech, insurance, pharma, and other regulated companies, that creates an enormous opportunity, but only if faster implementation is paired with better judgment.

The goal shouldn’t be to move cautiously because getting things wrong is expensive. It should be to build teams that know where they can move incredibly fast, where they need to slow down, and how to tell the difference. When implementation gets cheaper, judgment gets more valuable, particularly in industries where getting it wrong can be very expensive.