On a team where only some developers use AI assistants heavily, what changes for everyone else?
answer
- Output rate meets someone else's input rate
- Only one of the two rates was multiplied
- The constraint moves rather than disappearing
- Gain and cost land on different people
- Size the change to the reader
basics
~20 sReading load rises for people whose own output did not. An assistant multiplies how fast drafts are produced and barely touches how fast anyone reads them, so the constraint moves to review and lands on whoever is absorbing.
solid answer
~50 sOne person's output rate is the next person's input rate. An assistant multiplies the rate at which drafts are produced; it does not multiply the hours anyone has available to read them, so once authoring stops being the constraint, reviewing becomes it. The load also arrives in a worse shape: changes are larger and come faster while a reader's capacity to hold one is exactly what it was. Since the heavy users are producing and the others are absorbing, the gain and the cost land on different people — which is how "we got faster" and "I am drowning" get said about the same team in the same week. The team-level moves are all about the shared resource: size a change to what can be read, make the request travel with it, plan review capacity, and rotate the load so it does not settle on whoever complains least.
go deeper
Notice that the person reading your change has the same hours they had before. Something that took you an hour to produce can still take somebody else a morning to understand well enough to approve.
Explain why multiplying the authoring rate moves the constraint to reading rather than removing it, and why a larger change costs a reader more than proportionally.
Show that you plan review capacity rather than assuming it, and that you can name who is absorbing the load on your team today and what you changed so that it is not always the same person.
Own the throughput target itself. A target set from the authoring side alone books work into a step with no capacity assigned, and the cost surfaces as a slower defect tail rather than as a missed date.
## Two rates, and only one of them was multiplied A team has an authoring rate and a reading rate, and they are different resources. An assistant acts on the first. It acts far less on the second, because reading a change means building enough of a model of it to be accountable for it, and accountability is not a step that can be handed to anybody else. So the arithmetic is not subtle. Raise one rate and leave the other, and the queue forms at the second. **The constraint does not disappear when you relieve it; it moves, and it becomes somebody else's.** That is the whole of the mechanism, and most of what follows is consequences of it. | what an assistant multiplies | what it leaves unchanged | |---|---| | drafts produced per hour | hours available to read them | | how quickly a change can be made larger | how much a reader can hold at once | | how many areas one person can touch in a week | how many people understand those areas | | the speed of a first attempt | how long a defect takes to surface after merge | ## The load arrives in a worse shape, not just a bigger one If the only change were volume, the answer would be arithmetic about headcount. Two things make it harder than that. - **Changes get larger.** A change grows to the size its author can produce comfortably, and that size moved. But a reader's capacity did not, and the cost of reading does not rise in a straight line with size — past a certain point the reader stops holding the whole thing and starts sampling it, usually without deciding to. - **The author can supply less of what a reader usually leans on.** The standard shortcut in review is to ask why something is shaped this way, and the answer is thinner when the shape was not chosen so much as accepted. How to read such a change well is its own subject; what matters here is that it costs more, and the cost lands on the reader. ## Who absorbs it, and why that matters more than it looks The gain shows up with the people producing; the cost shows up with the people reading. On a team split between heavy users and others, those are often different people, and the split is usually not deliberate — the reading tends to settle on whoever is conscientious, senior, or simply quiet about it. This is why two apparently contradictory reports about the same team in the same week can both be accurate. **"We are moving much faster" and "I cannot keep up" are measurements taken at different points in the same pipeline.** A lead who hears only the first has heard from the half of the team that got the gain. ## What does not fix it - **Everybody adopting the tools.** Universal adoption raises the authoring rate further, and reading capacity remains a property of people and hours. Adoption changes who feels the load; it does not change whether the load exists. - **Asking reviewers to read faster.** A faster read of a larger change is a shallower one. The effort is not removed, it is deferred into defects that surface later, which is the same bill arriving under a different name. - **Waiting for automated checks to absorb it.** Machine checks move the line rather than removing the constraint, and what a tool can catch versus what a person must is a separate subject with its own answer. ## What a team actually decides 1. **Size the change to the review, not to the speed of authoring.** The unit that matters is what one person can understand in one sitting, and that number did not move. 2. **Make the request travel with the change**, so the reader is not reconstructing what was wanted from what was written. 3. **Plan review capacity as a resource.** A throughput target set from the authoring side alone books work into a step with no capacity assigned to it, and the shortfall surfaces later as a defect tail rather than as a missed date. 4. **Rotate who carries it.** Load that is never planned settles on whoever complains least, which is usually the person already carrying it. 5. **Make the author the first reader.** The cheapest review is the one done before anyone else is asked, and it is exactly the step a fast draft invites skipping. None of these is exotic, and that is the point: the imbalance is a capacity problem in a familiar shape, and the mistake is treating it as a personal failing of whoever is behind.
- Your team's review queue has grown since adoption. What do you change first?The size of the unit being reviewed, because it both raises the queue and lowers the quality of each read. Cap what one change may contain and make the request it answers visible alongside it. Adding reviewers is the slower fix and it spreads understanding of the system thinner.
- Heavy users say the queue is just other people being slow. How do you answer?With the arithmetic. Their output rate rose and nobody's reading rate did, so a queue is the expected result rather than a failure of the readers. The useful conversation is about what the team does with a constraint it has moved, not about whose fault the queue is.
- Does the imbalance show up anywhere other than the review queue?Yes, in how thinly the team's understanding is spread. One person can now touch more areas in a week than before, while the number of people who understand those areas has not moved — so the queue is the visible symptom and a thinner shared model of the system is the quiet one.
Widening one station on an assembly line does not widen the line. The queue moves to the next station, where it is now somebody else's problem and rather easier to see.
saying these in an interview costs you the question
- If some people are faster, the team is faster
- Reviewing is the reviewer's own time-management problem
- A large change costs a reader about what a small one does
- Once everyone uses the tools, the imbalance disappears
- Nothing changes for the people who do not use them