Lately I have been paying attention to how people talk about working with AI. There is a phrase that keeps coming up, in conversations and on stages and in the updates companies send around. We are becoming an AI first team. We are going AI first. And whenever I hear it, I find myself wanting to ask the same follow up question. What does that actually look like on a Tuesday?
The answer is usually some version of the same thing. Everyone has Claude in their editor now. We ship a little faster. Code review moves quicker. The boilerplate writes itself.
All of that is real. Having AI in your editor genuinely makes you faster, and I am not interested in pretending otherwise. But the longer I sit with it, the more I think we are using one phrase to describe two very different things, and that the blur between them is holding us back.
The line I keep looking for
So I have been trying to find the line. What separates a team that has truly reorganized itself around AI from a team that has simply added AI to the way it already worked?
Here is the question I keep coming back to, and it is almost embarrassingly simple.
If you take the AI out of the workflow, does the workflow still make sense?
When the answer is yes, you have an AI assisted workflow. The shape of the work is the same as it has always been. You are writing code the way you have always written code, and the AI is sitting next to you making each step smoother. Take it away and you are slower, maybe noticeably so, but nothing fundamental breaks. The recipe is unchanged. You just lost a fast pair of hands.
When the answer is no, something more interesting is happening. The workflow does not have a slower version. Without the AI there is simply nothing there, because the AI was never sitting beside the work. It was holding part of it up.
Where “tool” stops fitting
That distinction took me a minute to see clearly, and once I did, I started to understand why so much of what gets called AI first is really AI assisted in nicer clothes. The cause, I think, lives in a word we use without examining it.
We keep calling AI a tool.
I understand the instinct. It arrives as software, you open it in a window, you type things into it. It feels like a tool. And the more I work with it, the less that word feels like the right mental model.
I want to be careful here, because I do not mean this literally. A programming language is technically a tool too, if you want to be precise about it. But a language does not sit at the same layer as an IDE or a linter. You do not bring it to your work the way you bring an editor to your work. You build the work out of it. And that is the layer AI has started to occupy for me. Closer to a programming language than to an editor. A building block rather than a tool. It is one of the materials the work is made of, not one of the instruments I carry to work I have already designed. Tools get added to old workflows. Building blocks get built from.
This is also why the subtraction question works the way it does. An AI assisted workflow degrades when you remove the AI, because the AI was an addition. An AI first workflow does something else. It reverts. It falls back to needing a person, because the thing the AI was doing was never a faster version of a human task. The capability had always existed before, but only through a person, only as a dependency on someone who already understood the system.
A capability with no slower version
This is easy to nod along with and hard to picture, so let’s talk through an example.
Imagine someone on your team who cannot read the codebase. Maybe they work in marketing, or design, or operations. Maybe they do not even have access to the repository. They hit a question in the middle of their own work, the kind of question that has only ever had one answer: go find an engineer who knows, and wait. Now imagine they can ask that question directly, in plain language, and get an answer good enough to unblock them and keep moving.
Sit with what happens to that workflow if you remove the AI. It does not get slower. It vanishes, and the old dependency slides back into its place. Go find an engineer. Wait. There was never a manual version of someone who cannot read code reading the code. The capability was made entirely of the model. That is what built from AI actually means.
When intelligence stops being scarce
When I first built something like that, I thought of it as a convenience. A way to spare engineers a few interruptions. But I have come to think the real change is sitting underneath the convenience, in something closer to economics.
For as long as I have worked in software, one fact has shaped every workflow I have ever designed, usually without my noticing it was doing the shaping. Human attention is scarce and expensive. The person who understands the system is a bottleneck, so you build careful structures around protecting their time. You route questions to them. You queue work for them. You write documentation so people will interrupt them less. A surprising amount of what I once thought of as good process is, when I look at it honestly, a strategy for rationing a scarce supply of understanding.1
What changes with AI is subtler than speed. A usable version of that understanding suddenly becomes abundant. Human attention is still scarce, still expensive, still the thing I would protect first. But synthetic attention, the kind that will answer a reasonable question about the codebase at two in the morning for the hundredth time without tiring or resenting it, is now cheap and plentiful. And once something that used to be scarce becomes abundant, every workflow you built to ration it is up for question.
Holding the outcome, letting go of the path
The part of this I am still learning to do well is what it asks of me as the person directing the work. When AI is a tool, I stay in charge of how. I decide the steps, and the tool carries them out. When AI is a building block, my job moves. I become responsible for holding the outcome and for being almost uncomfortably clear about what a good result actually is, and I hand off a great deal of the how.
It is a little like the relationship between a tech lead and a developer on their team. You decide the goal, and you decide what done looks like. They work out the path to get there, and often they find a path you would not have chosen, and sometimes it is better. Your clarity about the destination ends up doing more work than your opinion about the route.
I have been learning a version of this same lesson somewhere completely outside of AI. When you stop leading the work directly and start leading the people who lead the work, you run straight into it. You have to hold the outcome and let go of the path. Some days that letting go is the hardest thing in the world, and some days it is a quiet relief, and I have not fully made peace with which one it will be on any given morning. It turns out an AI first workflow asks for the same muscle. Define the outcome with real care. Release the route.
I made a fairly large bet on all of this recently. I built something with my team that only makes sense if you believe AI is a building block, something that would be incoherent if I tried to explain it as a faster version of what we already did. I am going to write about that next, properly, as a case study, because it deserves more room than I can give it here.
What the work was actually for
For a while the question I asked was what this tool could do for me. Lately the question has gotten bigger, and a little less about me.
I have stopped thinking of this as a question about technology. The question an AI first team is really answering turns out to be an organizational one. Which parts of how we work only ever existed because intelligence used to be scarce? Which approvals, which handoffs, which queues, which roles are load bearing, and which are scaffolding we put up to protect a resource that is no longer rare?
The teams that get the most out of this will not be the ones who push AI into every corner of what they already do. They will be the ones willing to look at a process they have run for years and ask what it would become if the thing it was built to protect were suddenly cheap. That is a harder question than it sounds, because it means letting go of structures that have felt like good engineering for a long time. But I am fairly sure it is the actual work. The tool framing keeps us busy making the old thing faster. The building block framing lets us ask what the old thing was for in the first place.
- I’m not against process, I’m just examining the source of a lot of our current procsses ↩︎