The coding was never the problem.
For most of software history, the gate between “we should build this” and “we built this” was engineering capacity. That gate just opened. An ops manager with a Claude Code subscription and a free weekend can now produce a working prototype that would have taken a contractor a month. I’ve watched it happen, and it’s impressive.
What’s not real is the conclusion people are drawing from it: that every company can now build world-class products, that internal tools are free, that getting things done is a solved problem. Coding gated how quickly you could build — it never gated what you could build. Knowing what to build, how the work should actually flow, what good looks like, and how to keep the thing running after its author moves on: those were always the hard parts, and AI didn’t touch them. All of the hard things about building products are still there, minus the typing.
The clearest way I’ve found to see this is to map how AI adoption actually progresses inside an organization. There are five levels, and each one demands more sophistication than the last — not less.
Level one — Individual AI: prompting
Someone on your team opens Claude and asks it to draft a customer email, summarize a contract, untangle a spreadsheet formula. The sophistication required is knowing what to ask and being able to judge the answer. The value is real and immediate — call it an hour a day back, per person.
The limit is that nothing persists. The prompt that worked lives in one person’s chat history, and the judgment about whether the output was good lives in one person’s head. When they’re out, the capability is out with them. Level one makes individuals faster; it makes the organization nothing. It’s a better keyboard, not a better company.
Level two — Individual AI: agentic use
This is the step from asking to delegating. The AI reads files, writes code, runs it, checks the output, and iterates — and suddenly one person can build things: a report generator, a data-cleanup pipeline, a working internal app. The sophistication jump is real. You have to scope work an agent can actually complete, review output you didn’t produce, and develop judgment about what to delegate versus what to keep.
This is also the level where the fallacy is born. A prototype that works on Tuesday’s data feels like a product. It isn’t — it’s a demo with one user, no error handling, and an author who understands its every quirk because they built it that afternoon. The distance between that demo and something your team runs every day isn’t more prompting. It’s everything that was always hard about products.
Level three — Shared skills
The first team level, and the biggest jump in the whole progression. This is where one person’s workflow gets codified so that other people — and their agents — can run it: a documented, repeatable procedure for how a call gets debriefed, how a quote gets built, how a customer’s data file gets validated before it loads.
Writing a skill is writing a spec for how work is done, and most teams have never written that spec even for the people doing the work. Try to codify your order-intake process and you’ll discover it isn’t one process — it’s four people’s private variations, held together by exceptions nobody wrote down. The blocker isn’t AI capability. It’s that codifying a workflow forces you to agree on the workflow, often for the first time.
Level three is where process engineering enters, and where taste starts doing real work: deciding which workflows deserve codifying, what the exception paths are, who owns the skill when it drifts out of date. None of that is a coding problem, and no subscription includes it.
Level four — Team workflow AI
Workflows the business depends on, running without their author. They run unattended, integrate with your systems of record, handle exceptions on defined paths and escalate the rest, survive the departure of whoever built them, and can explain themselves when someone asks why the system did what it did.
At this level, what you’ve built is a product — whether or not you call it one. It needs requirements, edge-case analysis, testing, monitoring, permissions, change management, and a roadmap: the whole unglamorous apparatus that makes software dependable. This is why best engineering practices are more required than ever, not less. When code is cheap, discipline is the whole job. The cost of building the wrong thing fast has never been lower — and neither has the excuse for not knowing what the right thing is.
Level five — Self-healing, self-teaching workflows
The level almost nobody talks about, because almost nobody is there. A level-four workflow is dependable; a level-five workflow gets better because it ran. Every exception your team resolves becomes something the system knows. At level one, a correction lived in one person’s head and evaporated; at level five, it becomes durable knowledge the machine applies to every future case.
This is what we’re building at Deviceflow: self-teaching agentic AI that improves with use. When the machine first started matching POs to cases on its own, it matched about 60% of them. Today it’s north of 90% — not because we swapped in a smarter model, but because every unmatched PO a person resolved taught the system something it kept. A facility’s quirk gets discovered once, by a person doing the investigative work, and applied automatically from then on. The workflow heals where it breaks, and the break doesn’t recur.
The sophistication required here is the deepest in the progression, because you’re no longer just building the workflow — you’re building the system that improves the workflow. Corrections have to be captured as structured signal, not vibes. Someone has to decide which learnings get promoted into rules and which are noise. You have to measure whether the machine is actually getting better, not just feel like it is. And in our industry, the learning has to land as rules and configuration a person confirmed and an auditor can inspect — not as behavior that silently drifts. More on that below.
Level five is also where the economics flip. A level-four workflow is an asset that holds its value; a level-five workflow appreciates. The longer it runs, the more of your operation’s hard-won knowledge it holds — and the harder it becomes for anything built in an afternoon to catch it.
Where the difficulty actually lives
We build these workflows for a living, so let me show you what the hard part looks like up close.
A rep files a return for five items. Before the box ships back, one of them gets used in surgery. Four come back. How many does your workflow decrement, and against which case? The code to decrement inventory is trivial — an agent will write it in seconds. Knowing the answer is the product.
Or this one: a hospital operates with two patient identifiers, a financial one and a medical one. The rep writes the medical ID on the charge sheet. The PO carries the financial one. The charge sheet, if you know where to look, has both. No amount of prompting discovers that — someone had to sit with unmatched POs until the pattern surfaced. I still personally review our unmatched POs, which is how I know one customer’s facility dates its POs by the day the PO was cut, not the date of service. Edge cases like these take years to collect, and they’re the actual substance of a workflow that works.
Some of the most important decisions at level four are about what not to automate. Our matching engine doesn’t auto-match unless the SKUs match — not because we couldn’t loosen it, but because in a regulated industry a conservative workflow you can trust beats a clever one you have to check. That’s taste, encoded as a rule. It’s the least impressive-sounding thing we’ve built and one of the most valuable.
In our industry, add one more requirement: validation
Everything above applies to any company. Medical devices adds a multiplier the general AI-adoption conversation never mentions: validated software.
If your level-four workflow touches lot numbers, device history records, complaint handling, or anything else inside your quality system, it isn’t just software the business depends on — it’s software you have to prove works, in writing, before an auditor asks. The framework auditors expect you to follow is GAMP 5, and under GAMP 5, software you build yourself is Category 5: custom application, the highest validation burden there is. You write the user requirements spec. You run IQ, OQ, and PQ. You maintain a traceability matrix from every requirement to a test to captured evidence. You verify the Part 11 audit trail. And you do all of it again, under change control, every time the software changes.
Now notice what that does to the prototype from level two. Every prompt tweak is a change. Every model upgrade is a change. An agent whose behavior shifts with the model underneath it is a change-control problem most quality teams have never had to reason about — validation assumes the system behaves the same way in production as it did in the test protocol, and when it doesn’t, the failure mode isn’t a bug ticket. It’s a finding.
This is why we hold Deviceflow at GAMP 5 Category 4 — configured, not customized — as a deliberate architectural decision, and why every release ships with a validation packet: URS coverage, IQ/OQ/PQ, traceability, Part 11 audit-trail verification, evidence attached to every test. I’ve written about what it took to turn our ops system into a validated system — the short version is that it reshaped how we build, not just how we document. Conservative automation earns its keep here too: “don’t auto-match unless the SKUs match” is a rule you can write a test protocol against. “The model usually gets it right” is not.
Validation is also the constraint that shapes what level five can look like in this industry. A system that teaches itself sounds like the opposite of a validated system — and done carelessly, it is. The way the two coexist is that the learning lands as reviewable rules and configuration, confirmed by a person, versioned, and inspectable — configure-don’t-customize, running continuously. The machine gets smarter; its behavior stays something you can put in front of an auditor. That constraint isn’t a limitation on self-teaching AI. It’s the engineering requirement that makes it deployable here at all.
So in medtech, the level-four bar sits higher than anywhere else. The same afternoon-built workflow that’s merely fragile at a SaaS company is, at a device company, an unvalidated Category 5 system sitting inside your quality system — and the moment an auditor asks how you know it works, “we watched it for a few weeks and it seemed fine” is the wrong answer at exactly the wrong time.
The requirement curve bends up
I know it’s uncomfortable to hear that the subscription your team just bought doesn’t get you to level four. Look, I understand the appeal — I’ve watched an agent produce in an afternoon what used to take a sprint, and the feeling that everything is now buildable is intoxicating. But look at what each level actually demanded. Level one asked for judgment. Level two asked for scoping and review. Level three asked for process agreement and ownership. Level four asks for the full discipline of product development. Level five asks for all of that, plus the feedback infrastructure that turns every exception into knowledge the system keeps. The requirement curve bends up, not down — AI collapsed the cost of the one thing that was never the constraint.
This is also why “we’ll just build it internally now” is a harder road than it sounds. It’s not that your team can’t produce the code — they can, and faster than ever. It’s that the code was never the deliverable. The deliverable is a workflow that holds up across your team, your edge cases, and your next three hires — and in this industry, one you can hand to an auditor as a validated Category 5 system you now own, revalidation and all. That’s built out of product thinking, process engineering, and engineering discipline, not tokens. I’ve written before about the version of this that shows up in AI agents acting on operational systems — the pattern is the same. The demo is easy. The dependability is the work.
You don’t need a bigger engineering team to climb these levels. But you do need to treat the workflows your business depends on like products: write down how the work really happens, agree on it as a team, and hold the automation to the standard you’d hold a vendor to. The coding was never the problem — and now that it’s out of the way, you get to find out what was.