Building with AI is a different game, not the next step in tooling. Tooling has been evolving continuously for as long as I've been doing software. Text editors, then IDEs, then code completion, and while each one made writing code faster, none of them changed how software got made. This does. The typing was never the real constraint, and now it isn't the work either. The work has shifted to specifying, reviewing, and verifying what an agent produces, and it produces faster than a person can read.
A team of four is no longer a team of four
It becomes obvious within a few weeks: a team using AI well produces more, and produces it faster than the same team did before.
How much more depends on how the SDLC is laid out, and on how well each person is set up to carry several pieces of work at once. The ceiling is partly individual capacity and partly the tooling and resources you give them to work with. It isn't a fixed number, and it isn't unbounded either.
The multiplier isn't a property of the AI. It's a property of the system you put around it.
Which turns the interesting question into a leadership one. When writing the code stops being the constraint, the constraint moves to whatever part of the process was already weakest, and it gets there well before any report tells you. Knowing where to look first is the job.
I've seen the slower version of this. Engineering went from 60 to 120, and the constraint didn't land on the code, it landed on the managers. Cadence held through the doubling, and what held it was the system processes around the work, not anything in the codebase. AI moves the same constraint, in weeks rather than quarters.
That is why the stack and the domain are not the hard part. They take time, but they are learnable. Understanding how the engineering process actually works, how work gets prioritized, scoped, planned, reviewed, tested, shipped, maintained and supported, is what everything else rests on, and having navigated it is what tells you which questions to ask.
In practice, that means visibility into:
- The queue. Is there enough work ready to pick up, scoped properly, detailed enough to act on, and prioritized so the right thing is next?
- Planning and plan review. Is there an agreed plan before implementation starts? Who looks at it, and how, while changing it is still cheap?
- Enforcement during implementation. Do the conventions hold while the work is happening, or only when a human reviews it afterwards?
- Verification and delivery. Test automation, deploy pipelines, smoke tests. Can the team ship as often as it can now produce?
None of these are new responsibilities. What's new is how quickly each one becomes the thing holding everything else up.
Knowledge that stays true
Every team has a wiki, and it was written for people to read. It always drifted, and teams absorbed that drift, because a person reading a stale page would usually sense something looked off and go ask someone.
That tolerance disappears with the multiplier. Wrong information no longer sits quietly waiting to be corrected. It gets read and acted on. At the mild end, a convention moved, the page didn't, and a commit gets rejected. At the expensive end, a spec that changed during review and never made it back into the document drives the wrong thing being built in several places before anyone connects them.
Stale documentation used to slow people down. Now it produces work.
So the knowledge base needs governance, and that means more than collecting whatever markdown the agents leave behind. Two problems have to be solved at once. The first is keeping it true: ownership, and a rule that the decision and the document move together. The second is harder and usually gets skipped: controlling what gets read and when. You cannot point every session at the entire company knowledge base. A flat index doesn't solve it either. And you don't want the answer to "what should I read for this task" to itself be a model call.
It also has to serve people and agents from one place. A single source of truth, with a reader layer on top that shapes what comes out for a person or for an agent. Two copies maintained separately is the drift problem again, one level up.
And it has to be versioned. When something wrong does get built, the useful question is what the knowledge said at the time, not what it says today. Once agents are writing into the same store as people, that history is your audit trail as well.
Conventions, decided once
Conventions used to get settled in review, one disagreement at a time. That worked when code arrived at human speed, and a reviewer could hold the line. Now the work is done faster than the reviewer can see it, and a convention that lives only in a reviewer's head gets discovered after the fact, over and over.
So conventions belong in the knowledge base, written where both the team and their agents will read them before the work starts rather than after.
Then there's changing a convention, which is where the real work sits. Agreement is the easy half. Rollout is the half that gets skipped, and it depends entirely on the change. Do you migrate what already exists, or leave it and require new code to follow the new rule? What happens the day someone touches the legacy path? There's no right answer to that in the abstract. It depends on the organization, the codebase, and what the change is worth.
The point isn't having an answer ready. It's knowing you need to ask the question and work out the answer with your team.
I'd resist turning that into a template. Processes fail precisely when we make them prescriptive, and then we wonder why they didn't produce what we wanted. We need to adapt it to the organization's needs, then adopt it.
Enforcement, and what deserves a human
You can't check everything manually. A team that tries makes its most experienced people the bottleneck the multiplier was supposed to remove.
Enforcing conventions at review time puts a person in a fight with a machine, and you pay for that twice. Once in cost, because every correction is another round trip and AI spend climbs quietly while nobody is watching it as a line item. And then in people, because your experienced engineers are meant to be a force multiplier for the organization, not a correction loop for a tool. Put them in that loop and you lose the leverage you were buying, and they no longer enjoy their work.
So push everything that can be checked mechanically down to where the code is produced. Linters, formatting, the suite staying green, the pipeline staying honest. None of this work is glamorous and all of it compounds, which is why the pipeline has to be solid even when the team is one person. That's the part that tends to get deferred because it feels premature at small scale, but it isn't, because with AI a team of one is no longer a team of one.
Everything that clears those checks and carries little cost if it's wrong goes through without a person looking at it. What's left gets triaged on one question: what does being wrong cost? Money, customers, compliance. How much breaks and how hard it is to undo are ways that cost shows up, not the test itself.
And a check nobody has ready visibility into is not a useful check. Whatever gets surfaced for a human has to arrive where the team already works, in the tools they're already in. A queue that needs somebody to remember to open it is where the time you gained quietly disappears. Every item sitting in it is waiting on that one person remembering.
What can't wait
Automating your conventions and getting the pipeline solid isn't one option among several. Everything above rests on it. The knowledge base only matters if what it says is actually applied, and a convention is only real if something checks it. Defer that work and the rest stays aspirational.
There's a thread running through all of this. You're no longer leading a team that happens to use a tool.
You're leading a combination of people and machines. Both need leading, both need managing, and they have to work well with each other.
Over to you
I'd love to hear how you've adapted your leadership practice in the age of AI, and what you've run into along the way.