This summer one of our most technical people said something that raised my curiosity.
He has the Claude Code subscription. He read our process document. And when he sits down at the keyboard, he still doesn’t know how to start.
He wasn’t complaining about the document. He was describing a gap, and I wanted to know how wide it was.
So I asked Managing Partners across four of our offices what their teams have really adopted and what has bitten them. I had a specific reason. I’m out in the market telling healthcare organizations we know how to do this, and I wanted to know whether I was telling the truth.
Mostly I was. But the most useful thing I found wasn’t on my list of questions.
What’s actually working
The tools have reached every team. Every office is using agentic tools to build software and to manage what the team knows about the product. That happened in a matter of months across a distributed company, and I don’t want to skate past it. Consistent practice is still catching up.
The gains are showing up in projects. On one eight-week engagement with two developers, the team estimated afterward that they could have shipped in five. They put that time back into quality instead of banking it, and the client told us the engagement went better than with their previous partners.
Teams are also building their own tooling now, and it travels. Somebody writes a skill and it moves to the next team. That’s a different world from committing to a framework and living with it for three years.
The thing three people told me without being asked
Six months ago the problem was individual. People didn’t know how to use the tools. That’s resolving on its own, faster than I expected.
The problem now is a team problem. When everyone is running their own set of agents, the team has to reorganize around definition and shared knowledge. We don’t yet have a consistent way to do that across teams.
Building stopped being the hard part. Defining the right work, and knowing it’s good, is the hard part now.
Three of the four Managing Partners I talked to said a version of that on their own. I didn’t put it in front of them. It came up in each conversation unprompted, which makes it the strongest signal I found all summer.
It also changed what I thought I was measuring. Early on, everyone was measuring velocity, and chasing it mostly created slop. The measures that matter are quality and the value the work delivers. Speed still counts. The better question is how the whole team goes faster, and how we make sure that speed isn’t producing more slop.
Our developers got there first
I’m not the first person at Atomic to notice this. Our developers have been writing about it on this blog since June.
Kealy Williams put it in seven words in When Code Becomes Cheap, What’s Left?: “The typing got cheap. The judgment didn’t.” Isabella Wloch came back from Code Remix with the same theme. The limit is writing solid requirements and breaking work down fast enough. Kendra Haan wrote about her first agentic project, where the hard part was deciding how much of the product needed to exist on paper first. And Jordan Booker pushed back on the whole productivity story in It’s Not Up to You to Prove AI Makes You Faster. In his words, the code was never the whole job.
They wrote from different projects and landed in the same place. My conversations suggest the pattern runs across our offices. In healthcare, it puts pressure on two parts of the process: understanding the work and verifying the result.
Healthcare puts pressure on both ends
Both depend on expertise that a faster coding tool doesn’t supply.
First, some of the work you need to understand was never written down. Clinical workflow often lives in a nurse’s head and in the workarounds she built over six years because the system in front of her didn’t do what she needed at 2 a.m. An agent can’t reliably infer that from the documentation. Neither can a developer who was never in the room. You get it by sitting with the people who do the work. Tools can help capture what you learn. They can’t replace being there.
Mike Meyers wrote about exactly this in Walk the Halls. Before his team designed recall management for a healthcare inventory client, they spent a day in the client’s mock facility with the crash carts and the barcode scanners. They got that feature right the first time.
Take a requirement like “Let clinicians override the recommendation.” It sounds ready to build. But which clinicians? Under what circumstances? What gets recorded? And who decides whether the resulting workflow is safe? An agent can help surface those questions. The answers still need the people who understand the care being delivered.
Second, changes need review that fits their risk. Depending on the product and the change, that can mean clinical, security, quality, or regulatory review. When clinical judgment is needed, the people providing it often already have full patient-care schedules. You can buy more engineering capacity. You can’t buy more of their time.
So in healthcare the work gets squeezed from both ends. Definition has to account for workflows and exceptions nobody wrote down. Verification has to keep pace with more proposed changes, often from people whose calendars were already full. Faster building doesn’t remove either job.
When a change touches patient care, a hospital doesn’t get to ship a bug on Monday and fix it Tuesday. As building speeds up, teams have to protect the time it takes to understand the risk and verify the result. I believe the pressure on that work is only going up.
What we don’t have yet
We need to tell thoughtful adaptation from quiet avoidance. No team is running our published process exactly as written. I heard that in June and again in August, from different people. Every client brings us a different problem, and we shape each engagement to solve it. A two-week solo engagement and a nine-month build with ten people shouldn’t run the same playbook. A product company gets to build software the same way every day. We adapt our practices to each client’s situation, and our people doing that is the most Atomic thing I can imagine.
The gap is that we can’t yet say which practices every team should use and which are situational. From where I sit, thoughtful adaptation and quiet avoidance can look identical. Without that line, it’s hard to learn across teams.
We need a practical way to start. Our guide gives us a strong strategy, and our clients, especially their leadership, needed something smaller. Drew Colthorp’s Brief puts that strategy on one page. Teams also need a starting point for the work in front of them: what to define first, and where the team’s shared knowledge lives.
We need to make learning travel. Everywhere the practice has taken hold well, a person helped make it happen. Somebody sat with a team on site, or an experienced practitioner embedded and helped them adapt. That works, but the number of people who can do it is small, so we need to capture more of what they teach. Delivery leads and designers need that support too. If definition is the constraint, they may need it first.
We need to measure the right numbers. We’re still figuring out how. Time is easy to measure. Value isn’t. For one project, value might mean a clinician spends less time on a task. Quality might mean fewer errors or less rework. Speed still matters, but what counts is what improved for the people using the software.
The human attention behind the speed
Faster building also strains human attention. The people defining work and reviewing results may also be supervising several agents at once. One office reported engineers coming to the end of the day exhausted from tracking fast-moving agents. Somebody described it as managing four or five people who each need five minutes of your time every fifteen minutes, and you can’t fully trust any of them.
Only one office raised it. But two of the people I asked told me they aren’t close to the implementation work on their teams, so I wouldn’t read quiet as absence. It’s the kind of strain that’s easy to miss from where leaders sit, so I’m asking about it on purpose.
Fatigue isn’t the only cost. I’m also seeing people, especially remote engineers, spend more of their day talking to agents and less of it thinking through problems with colleagues. To me it feels like COVID all over again.
The research is starting to show it. In a survey of 1,033 desk workers on project teams, published in Harvard Business Review in October, teams where people routinely went to AI instead of a colleague reported about 22% lower coordination and 22% lower trust. One respondent’s colleague now gets writing feedback from AI instead of from her. “I miss having those connections and I feel lonelier now.”
This is one place our culture helps. We’re an in-person team. Our people work side by side, and we invest in our office community. We still have to make sure people get time to think through problems together and to step away from the agents.
What I’d ask your team this quarter
If you lead technology at a healthcare organization, these are the questions I’d bring to your next team meeting. They’re the same ones I’m asking our own people.
Who defines the work, and when did they last sit with the people who use it? Name them. If it’s the same two people who were stretched before AI showed up, that’s likely your constraint. If nobody has watched the clinicians or staff use the software lately, start there.
Who reviews changes for safety, and how much more are you asking of them? Name the clinical, security, quality, or regulatory people each kind of change needs. Then ask whether they have time for the volume your team now produces. If the same people both define and review the work, count both loads.
Which parts of your process are non-negotiable? Every team will adapt the process, and that’s healthy. Decide which steps every team does every time, so adapting doesn’t quietly turn into skipping.
What does a team pick up on Monday? If a strong engineer can’t answer that for a four-week project, a strategy document won’t fix it. A two-page starting point for that kind of work might.
What are you measuring? One good project story isn’t enough. Pick one project and choose a measure for the people using it, one for quality, and one for delivery speed. Get a baseline where you can, then track what improves and what gets worse. We’re working on the same question.
Where I come out
The tools are everywhere and they aren’t going back. Our next job is to turn what our best teams are learning into practices every team can use, with a clear way to start and measures that tell us whether faster building produces better software. That’s the work we’re doing now.
For healthcare organizations, the same job means investing as deliberately in definition and verification as in the tools that write the code.
I believe we’re further along than most teams in this space. It’s also changing fast, and keeping up is a challenge, even for us. A lot of the answer starts with writing down what our best teams already know, and we’ll keep sharing what we learn.