Put a race engine in a regular car and it will go very fast. It will also go very fast in the wrong direction.
That is the first thing I tell any team that asks me how to bring AI into their software development process. The answer is not a tool choice or a model comparison. The answer is that you cannot step on the gas until you know which way you are facing. Once you do, and once you are actually moving at speed, you need better brakes and you need to look further down the road.
This series is about that. It takes the software development lifecycle apart one part at a time and asks two questions of each: where does AI accelerate this, and where do the brakes have to be? The context is regulated software, where the work carries obligations about data, access, and evidence. The pattern holds anywhere the output has to be defended.
I want to start with the part almost everyone skips.
Map the loop you already have
Before automating anything, describe the workflow as it exists today.
For one person doing one job, that means naming the tasks that make up the job, the decision points between them, and what the person actually looks at before deciding to move forward. Not “I reviewed it.” What did you check? Which specific things had to be true for you to let it pass? And when they were not true, where did you send it back, and why there instead of somewhere else?
Most of us have never written that down. We know it the way we know how to drive home. Which is fine until someone else has to do it, or a machine has to do it, or the work volume triples and we need to explain which parts of our judgment can be shared.
Raise that to the team and the questions get bigger. After one person finishes and hands work forward, who receives it? What is that person trying to accomplish? What do they need in order to make their decision? If I cannot walk to a whiteboard and draw the whole loop and explain it to someone who was not there, I am not ready to automate any of it.
Why the map has to come first
There is a specific failure I keep seeing. Someone gives an AI a task described in the terms they happen to have in their head, the model produces something with the same confident tone it would use if it were right, and everyone moves on.
The model did not know the parts that were not said. It could not know the business invariant that has held since before anyone on the team was hired. It did not know that this record type is never allowed to leave the tenant, or that this field is derived and must never be stored, or that the downstream system breaks if the sequence of events changes. It produced something plausible, because producing something plausible is what it does. It is built to be helpful, and when a request is incomplete, the most helpful thing it can do is fill the gaps.
That is the trap. Filling the gaps is not the same as satisfying the requirement, and the result arrives with the same confident tone either way.
So the sequence matters. First the workflow, then the acceleration. In that order, because the workflow map is the thing that tells you what context the model is missing and what constraints have to be stated out loud.
I have written before about flipping the human-in-the-loop framing. We are humans and we have loops. The useful question is not “where does a human supervise the AI?” It is “what does my loop look like, and where might AI help inside it?” The workflow map is how you answer the second question.
What better brakes look like
Everyone agrees with the brakes line until it becomes a specific change to how they work. Then it gets uncomfortable, because better brakes on a development process usually means reviewing sooner, in smaller pieces, more often.
If a step that used to take five days now takes half a day, the same weekly review cadence is no longer a control. It is a delay. By the time someone looks, five days of changes have accumulated instead of one. The speed of production went up and the speed of feedback stayed flat, so the gap between “made” and “known” widened. That gap is where the risk lives.
Concretely, that means:
- Shorten the feedback loop. If you were checking the output in the last two days of a sprint, check it earlier. More output means more checkpoints, not the same checkpoints looking at more.
- Look further ahead. When something is going wrong, you will cover more distance before you can correct it. Review has to start before the work is finished, not after.
- Make the decision points explicit. The map from earlier tells you where the real decisions are. Those are the places that need a person, and they need that person earlier.
- Ask what the saved time is for. If a step collapses from days to hours, the time does not automatically belong to more work. It can belong to tightening the next step, or to doing the step before it better, or to looking at something nobody had time to look at before.
That last one is the part I get wrong most often myself. The temptation with reclaimed time is to spend it all on throughput.
The time you are not saving
There is another version of the workflow conversation that matters more in regulated work than anywhere else: the loop that produces the evidence.
When you release a change into a system that carries obligations, someone eventually asks you to show that it was reviewed, that the controls applied, that the data handling was appropriate. In the old process, that evidence was a byproduct of how people worked. A pull request with a reviewer’s name on it. A test run. A checklist. Slow, but self-documenting.
Accelerate the production side and the evidence does not appear automatically. It becomes something you have to design. Which is why, in a regulated context, the workflow map is not just about speed. It is the list of places where evidence gets created, and the first thing you check when you start moving faster is whether those places still exist.
What comes next
The next four posts take the map apart. One on where AI genuinely helps and where it quietly costs you control. One on how to write the request so the model stays inside a safe scope. One on the difference between code that works and code you can stand behind. And one on how a person signs off on all of it when there is more of it than anyone can read.
All of it comes back to the same starting point. You can go much faster than you ever could. You are still the one facing the direction, and you are still the one holding the wheel.
Leave a Reply