The AI Coding Fluency Model

Every team now says it is AI-first. Ask what they mean, and no two answers agree. Diana Larsen and James Shore, and a definition of fluency I never forgot. Adopting a practice is not the same as keeping it under pressure. Five levels, from no AI at all to the factory that runs itself. The rest of this book is the map.

For the last year I have been asking other founders and engineering leaders the same simple question: is your team AI-first? Every hand goes up. Then I ask what they mean by it, and no two answers are the same. For one team it means a couple of engineers quietly running Copilot. For another it means a mandate that no human writes a line of code. For a third it means a deployment pipeline that ships to production with nobody watching. Same question, three teams, three completely different answers.

So this half of the book sets out to do the unglamorous work the slogan never did, which is to define it. What does it actually mean for a team to become AI-first, and how do you tell, honestly and without flattering yourself, where on that road you already stand? You cannot improve a position you cannot locate, and a badge is not a position.

The first half leaned on Kent Beck. Extreme Programming Explained gave us the shape of the argument: a world of practices designed for human developers, and the slow realisation that the developer is no longer only human. Beck’s world is where we started. It is not where we can finish, because knowing what the practices should be tells you nothing about whether your team can actually hold on to them when the quarter is on fire. For that I want to borrow from someone else.

Fluency, and what it actually means

In 2012, Diana Larsen and James Shore published something they called the Agile Fluency Model, later expanded and championed by Martin Fowler on his site. I have read a great many methodology papers in my life, most of them forgettable, and this one lodged and never left. What lodged was not a practice or a ceremony. It was a definition.

Fluency, they wrote, is not skill. It is a habit of exhibiting the skill even when you are under pressure. Their phrase is “skillful, routine ease that persists when your mind is distracted with other things.” You are not fluent in a language when you can order coffee from a phrasebook. You are fluent when someone shouts a question at you across a noisy room and you answer before you have consciously translated it. The test of fluency is never the calm day. It is the bad one.

That distinction is what separates a team that has adopted AI from one that has become fluent in it. I have watched a team look flawlessly AI-first through a calm sprint and then, the week a real deadline landed, throw all of it overboard, an engineer back to typing code by hand at midnight because that was the only mode it actually trusted. It had adopted AI. It was not fluent in it. Competence is what you can do when you are paying attention. Fluency is what is left when the deadline is slipping and nobody is paying attention to method at all.

The model has one more feature I want to carry across, and one warning. The feature is that Larsen and Shore describe fluency in zones, four of them: Focusing, Delivering, Optimizing, Strengthening. Each is unlocked by a specific investment and each returns a specific benefit. A team invests in one set of habits and, in return, gains a capability it can rely on. The warning is that, in their telling, this is emphatically not a maturity ranking. A zone is not a rung. You do not climb it to prove you are a serious team; you enter the one whose benefits your business actually needs, and go no further. I am going to keep almost all of this, and break one piece of it, in a moment.

Why an AI-first team needs its own version

The same problem hangs over every practice the first half of this book described. Specifying software precisely instead of typing it. Letting the agent write the tests and reviewing behaviour rather than method. Keeping the context window small and deliberate. Writing the rules of the house down where every human and every agent will read them. Every one of those is a practice a team can know and still lose the instant a deadline bares its teeth.

And we already have a name for what a team reverts to when it loses them. It is vibe coding. Prompt, accept, ship, shrug. Vibe coding is not a beginner’s mistake that teams grow out of; it is the resting state a non-fluent team falls back into under pressure, no matter how much it knows on a good day. The professional mode and the vibe-coding mode are not two kinds of team. They are the same team, fluent and not fluent, on its best week and its worst one.

So the useful question for an AI-first team is not “have you adopted these practices.” Everyone will say yes. The useful question is which of them survive your worst week, and that is a question about fluency.

This is a different fluency from the one I warned about earlier in the book, and I want to be careful with the word. The danger of the machine is that it is linguistically fluent: it produces the confident cadence of a settled answer whether or not the answer is any good. That fluency belongs to the model, and it is not to be trusted. The fluency I mean here belongs to the team, and it is what keeps you safe from the other kind. A fluent team is not seduced by a plausible-looking pull request, because checking it is a habit, not a decision.

The AI Coding Fluency Model

So here is the frame for the rest of this book. I will describe an AI-first team not by the tools it has bought or the methodology it has adopted, but by what it can actually do under pressure. And here is the piece I break with Larsen and Shore on, on purpose. Their zones are not a ladder; you enter the one your business needs and go no further. The AI version really is a progression. A team moves through these levels roughly in order, because each one rests on a capability the last one built, and there is a real frontier: almost everyone is near the floor today, and the best teams in the world are two or three steps up. But I am keeping the part of their model that matters most. A level is something you become fluent in, not something you announce. You cannot mandate your way up the ladder, and the most dangerous teams in what follows are precisely the ones that tried.

There are five levels, numbered from zero. This chapter names them. The chapters that follow live inside them, one at a time.

• Level 0: No AI. No adoption at all, by the team or the person. The furthest most of them go is the code completion that has sat in their editor for years, which they think of as the tool being helpful and nothing more. This is where most of the profession still is, and it is not really a technical stage. It is a psychological one. Some of the people here are quietly optimistic and waiting for permission. Others are frightened, or resentful, or certain it is all a fad that will cheapen a craft they gave a career to. The most immovable are often senior, which lends their fear the force of policy. The entire content of Level 0 is belief, and it earns a chapter of its own because no team moves until the beliefs move first.

• Level 1: The Scramble. One person, or two, starts using an agent to write real code. The only conditions are a spark of individual enthusiasm and enough organisational tolerance to look the other way. Everything else here is disorder, and it runs in two opposite directions, both bad. In the first, the organisation is hostile: the work offends the coding standards and the regulations the team spent years building, and the early adopter is treated as a hazard. In the second, which is worse, leadership has decided AI is the future, ordered everyone to use it, and begun measuring success by tokens consumed, as if spend were the same as productivity. People are pushed into a way of working they did not choose and are not ready for. This is also the native soil of vibe coding, where someone who could not previously ship is handed the keys to the candy store and rides an agent off in six directions at once. Level 1 is adoption without control: real, energetic and haphazard.

• Level 2: The Paper Trail. The team decides, deliberately, to make AI part of how it works, and brings the first real organisation to it. Specifications get typed up (most likely by an agent, but the output being a markdown file). Skills appear next, and then elaborate schemes for managing the skills: folders of markdown, naming conventions, documents whose only job is to describe the other documents. Coding standards are codified as markdown and committed to the repository. Procedures appear for how an agent should review code. Systems get wired together, MCP tools talking to Git and to Jira. But the underlying work is still the old work with a faster tool bolted on, the way an editor plug-in makes a person quicker without changing what the job is. The signature of Level 2 is documents, a great many of them, written by different people and dragged around by hand: linked in Slack, dropped into repositories, commented on, argued over in pull requests a human still has to read. The friction is real, because every role is in the air at once. Where does the designer sit now? The architect? The developer? This is the lived version of the question the first half of this book spent its time on.

• Level 3: The Backbone. AI stops being an adjunct and becomes the centre of the process, and this is a deliberate act rather than a drift into one. The signs are specific. Code is no longer written by hand, only by agents. There is a decisive move away from markdown as the instrument of control, because a passive document an agent may or may not read is not control at all. The team’s attention turns to the machinery itself, the tools and plug-ins that govern how the coding system behaves. Specifications, standards and rules stop living in documents and move into a database wired straight into the tooling, so that an agent does not hope to comply, it cannot do otherwise. The purpose of all of it is to move the bottleneck left, all the way to the front of the work. When code is precise by construction, when the tests are written and run by agents, and when even the test frameworks are themselves tested, coding and QA stop being where the work piles up. The only constraint left is decisions: how many good ones the team can make and record, and how fast. This is the level where a team produces higher-quality work and produces it faster at the same time, the trade-off I was taught thirty-five years ago was simply a law of nature. Very few teams are here, and the ones that are tend to be the best in the world. If this book is pointing a professional team anywhere, it is here.

• Level 4: The Closed Loop. Every stage of the lifecycle is automated and the loop closes on itself. The system specifies, builds, tests, deploys and improves. The loop closes because it watches the world, the metrics in production and the way real users behave, and feeds what it sees back into the work, correcting its own course under human supervision. The human contribution narrows to the two jobs a person should never hand over: the decisions, and the final judgement on whether the work is good enough to carry the team’s name. The system governs and corrects itself; the person governs the system. I am naming a horizon here, not a place I can point to, and I will say plainly that the line between a factory that improves itself and one that has quietly stopped making sense is thinner than its enthusiasts admit. But it is where this is heading, and a model that stopped short of naming it would be a comfortable lie. When almost everything a team does can be done by the machine, the last human job is judgement, and it is exercised over the machine itself.

Five levels, and almost every team sits at Level 0 or Level 1 today, whatever the slide decks claim. Some teams are at level 2, and very few are at level 3. That is not a failure. It is a starting position, and knowing precisely where you actually stand, rather than where you have announced you stand, is worth more than any amount of enthusiasm about the destination.

Naming the levels is the argument, not the answer. Whether there are five, whether the borders sit exactly where I have drawn them, and what genuinely carries a team from one to the next, is the work of the chapters ahead. What I am certain of is the frame. A team’s real level is not the one it has adopted. It is the one it holds on its worst week.

You will not find out which level you are on during the demo preparation. You will find out when the demo breaks.

Barrie