Dev Chroniclesby Thinnd
Experiences

From Passing the Baton to Baking Together: How IT Teams Work in the AI Era

Instead of passing work through many stations, many IT teams are heading toward small crews that work with AI assistants. Told through a little bakery, with real numbers, examples from work, and the traps of the new way.

Nhu Duy Thin (Thinnd)14 min read
  • #teamwork
  • #AI
  • #process
  • #trends
  • #experience

Slide deck

Click the slides, then use the arrow keys to move. Press L to change language and F for full screen.

Open full screen

For anyone who works in or near an IT team, no programming needed. Every term comes with an everyday explanation, and the whole article uses one picture throughout: a bakery.

This is a new trend and it is changing fast. Figures come from public reports and surveys listed at the end, and many were published by the technology companies themselves. Examples marked "illustration" are rebuilt to be easy to picture and do not refer to any specific team or company.

Quick summary#

  • Instead of passing work down an assembly line (analysis, design, coding, testing, operations), many teams are heading toward small crews where each person can go further thanks to AI assistants.
  • Instead of meeting a lot to pass information along, teams are heading toward writing down what "done" means and putting context on paper. A good handbook serves both people and AI.
  • Instead of the bottleneck sitting at writing code, it is moving toward reading and reviewing. A large data analysis found that teams using AI heavily merged more changes, but review time also rose sharply.
  • The new way has its own traps: reviews that cannot keep up, one assistant per person with one opinion each, and newcomers with fewer chances to practice. Google's DORA report describes AI as an amplifier: a good team sounds better, a messy team sounds messier.
  • The short advice: small teams, clear task descriptions, a shared handbook, review rules, and measuring the whole team's results instead of lines of code.

Hard words, plain meaning#

Term Plain meaning
Handoff (passing the baton) One person finishes their part and hands it to the next, like passing the baton in a relay race.
Bottleneck The slowest spot in the whole process, like the neck of a bottle: however fast you pour, water leaves at the speed of the neck.
Agent (self-working AI assistant) An AI that does not just answer but carries out a chain of work, such as reading a project, editing many places and running tests.
Spec (task description) One page that says what to do and what "done" means, so people and AI understand it the same way.
Code review A second person reads the first person's code before it goes into the product, like a taster tasting the cake before it is sold.
Context file (handbook for AI) A file listing the project's conventions for the AI to read before it works. Common names are AGENTS.md or CLAUDE.md.
Amplifier A device that makes whatever goes into it louder, whether a lovely tune or a screech.

1. The old way: an assembly-line bakery#

Picture a bakery with five tables in a row. Table one takes the order. Table two kneads the dough. Table three bakes. Table four decorates. Table five boxes it. Each person is good at one table and sees only their own part. Many IT teams once worked exactly like this: analysis, design, coding, testing, operations, one group per stage, handing work to each other through tickets and documents.

This way had good reasons. It is easy to manage, who does what is clear, and when writing code was slow and costly, splitting the work was sensible. The trouble only shows when we look closely at the gaps between the tables.

1.1 One ticket through five pairs of hands (illustration)#

A small request: "add a cancel-order button on the order page".

Day What happens Who is working, who is waiting
Monday Analysis writes the requirement, half a day The later stages wait
Wednesday Design draws the screen, half a day Analysis is done, coding waits
Friday A developer builds it, one day Design is done, testing waits
Tuesday next week Testing spends half a day and finds: "after cancelling, what about the refund?" The requirement did not say Coding waits for an answer
Thursday next week Coding fixes it in half a day, ticket closed Waiting over

From writing the requirement to closing the ticket is nine working days, and only about three of them are real work while about six are waiting. This is a rebuilt example to make it easy to picture, so the numbers are illustrative, but the pattern of "little work, lots of waiting" is very familiar to anyone who has lived in a multi-stage process.

1.2 The puzzle of communication lines#

The more people, the more pairs have to talk. The number of pairs (communication lines) among n people is n times (n minus 1), divided by 2. Try it:

People Communication lines
3 3
5 10
10 45
20 190

Doubling from 5 to 10 people almost quadruples the lines. This is part of the reasoning behind the famous "Brooks's law", drawn from The Mythical Man-Month (Fred Brooks, 1975): adding people to a late project tends to make it later, because newcomers need guidance and the number of conversations grows fast. The law is also debated, but the picture of "too many cooks bumping into each other" is one everybody gets.

1.3 The limits of the old way#

  • Waiting. Work sits in queues longer than it is worked on.
  • Dropped context. Each handoff leaves some of the "why" behind. The next person follows the words, not the intent.
  • Late feedback. A misunderstanding only shows at the last stage, when fixing costs the most.
  • Thin ownership. Anyone can say "my part matched the requirement".
  • Meetings to patch the gaps. Many meetings only pass information along, when one written page would do.

2. The new way: a small bakery and AI helpers#

Now picture a small bakery with three bakers. Each bakes a cake from start to finish, but beside them is a quick-handed helper that kneads dough, bakes a test batch and writes down the recipe. The helper is very fast but sometimes mistakes sugar for salt, so the baker decides which cake to make, tastes every batch, and only then sends it to the counter.

That is the picture of the trend many IT teams are heading toward. It is simplified from public reports, and in practice every place does it differently.

2.1 Signs of the trend#

  • AI becomes a baseline expectation. In April 2025, Shopify's CEO (Tobi Lütke) sent an internal memo, which he later posted publicly. It said using AI well is a fundamental expectation of everyone, teams must show why AI cannot do a job before asking for more headcount, and questions about AI use will enter performance reviews. This is one company's stance, not a universal rule.
  • Part of new code is written by AI. In October 2024, Alphabet's CEO (Sundar Pichai) said more than a quarter of new code at Google is generated by AI and then reviewed and accepted by engineers. It is unclear whether that figure counts "autocomplete while typing" or "AI writing whole sections", and it is a 2024 number.
  • Teams of people and AI assistants. Microsoft's 2025 Work Trend Index describes the "Frontier Firm", where teams consist of people and AI assistants, each person plays an "agent boss" (the boss of the assistants), and rigid org charts give way to "work charts" that change with the goal. This is a survey run by a technology company that also promotes its own products.
  • AI is already common in the industry. Google's DORA 2025 report (a survey of nearly 5,000 software professionals) found about 90% use AI in their work.

No single sign proves anything, but together they point one way: smaller teams, each person covering more stages, and AI counted as a team member.

2.2 What people do, what AI does#

Task Often kept by people Often handed to AI (then checked by people)
Choose what to build and why People AI suggests options
Describe "what done means" People AI helps draft
Write code, tests, docs People review AI writes the first version
Read and review The accountable person AI scans for small errors first
Decide to release People Not handed over
Take responsibility when wrong People Cannot

2.3 Documents instead of meetings#

With an AI assistant, one thing becomes very valuable: context written down. AI does not attend meetings and cannot hear "you know what I meant". It only knows what is written. So teams working the new way often have two things:

  • A task description (spec): one page saying what to do, who uses it, what "done" means, and what is out of scope.
  • A handbook for AI (context file): the project's conventions, how to run a test, what is forbidden. It guides the AI and also documents the project for newcomers.

A small handbook might look like this:

Project: order page
Run tests: npm test
Conventions: function names in English, user messages in Vietnamese
Forbidden: do not edit the /payments folder without a reviewer
Done means: has tests, has a screenshot, the reviewer has read it

2.4 One afternoon of a small crew (illustration)#

The same "cancel order" request, in a team of three working the new way:

Time What happens
13:00 Lan (the owner) writes a one-page description, including "after cancelling, what about the refund?"
13:30 The AI assistant builds the screen, code and tests, following the project handbook
15:00 Minh reads and reviews, fixing two places where the AI misread a convention
16:00 The whole team looks at the working version and decides to release

The whole loop takes about one afternoon, not two weeks. This is a rebuilt example and not every feature is this tidy. The vaguer the requirement, or the closer it is to payments or safety, the more eyes it needs.

3. The new way has traps too#

A small bakery is not perfect. Four traps are worth naming.

3.1 Baking twice as fast, one taster still#

Faros AI's "AI Productivity Paradox" report (July 2025) analyzed data from more than 10,000 developers across 1,255 teams. Teams using AI heavily finished about 21% more tasks and merged about 98% more changes (pull requests). But review time per change rose about 91%, change size grew about 154%, and bugs per person rose about 9%. At the company level, the report found no clear link between AI use and outcome metrics.

Read with care: this is data from a vendor that sells measurement tools, it is a correlation and not necessarily causation, and I have only read summaries, not the original. But the picture is easy to grasp: when bakers get twice as fast and there is still one taster, the tasting queue grows. The bottleneck moves from making to reviewing.

3.2 AI is an amplifier#

Google's DORA 2025 report describes AI's main role as amplifying: teams with a good foundation (automated tests, fast feedback, clear process) benefit, while teams that are already messy get messier. Think of a loudspeaker: a good singer sounds great, a flat singer sounds flat and louder. If your team lacks tests and a clear process, adding AI may not make things better.

3.3 One assistant per person, one opinion each (illustration)#

Two bakers each ask their own assistant: "How should we store orders?" Lan is told "use relational tables", Minh is told "use a document store". Both sound reasonable, each follows their answer, and two weeks later the system has two storage styles. This comes from AI possibly answering differently each time you ask, covered at length in why you should not trust AI blindly.

How to avoid it: shared decisions (how data is stored, naming conventions) go into the shared handbook, and every assistant reads the same source. Do not let decisions live in private chats.

3.4 How do newcomers learn?#

Newcomers used to learn the craft through small jobs: fixing minor bugs, writing tests. When AI does those small jobs quickly, newcomers may get fewer chances to practice. There is not much solid data on this yet, so it is an open question, not a conclusion. A few things teams might try: have newcomers explain code the AI wrote, let them join reviews, and keep a few small jobs aside for practice.

4. Old versus new#

Old: assembly-line handoffs New: small bakery with AI
How work moves Through many stages, many tickets One person or a small crew goes from idea to a working version
Team size Large, split by stage Small, each person covers several stages
Communication Meetings and long documents Short task descriptions and a shared handbook
Bottleneck Waiting between stages Reviewing and verifying
Main limits Waiting, dropped context, late feedback Reviews that cannot keep up, scattered decisions, newcomers practicing less
Favorite question "Whose part is it?" "Who tastes it and who is accountable?"

5. Seven things a team can try#

  1. Keep teams small. Two to five people for a product or an area, so there are fewer communication lines.
  2. Write "what done means" before starting. One page, including what is not being done.
  3. Keep one handbook for people and AI. Write each shared decision once, in one place.
  4. Set review rules. Small changes get a quick review, changes touching money or real data need two people. Prefer small, easy-to-read changes.
  5. Measure the whole team's results. Measure time from idea to a working version in front of customers, and bugs that escape, instead of lines of code or changes per person.
  6. Share how you use AI. Ten minutes a week for everyone to tell which tricks work and which cause bugs.
  7. Keep room for newcomers to practice. Keep small jobs for hands-on practice and sessions where people read code together.

6. A balanced view#

Do not read this article as "a small team with AI is always better". The data is early, much of it comes from surveys and reports by companies with a stake in AI, and different teams get very different results, exactly as the amplifier picture says. Large products with heavy safety or legal constraints still need many eyes, only the way they are organized may change.

What seems fairly solid: the cost of producing a draft is falling, but the cost of verifying is not falling with it. So teamwork skills are shifting toward writing clearly, reviewing carefully and sharing context. This is also the direction in the dev career through the eras.

7. Ten questions for your team#

  1. How long does a small task take from idea to running in front of a customer, and how much of that is waiting?
  2. How many stages and handoffs does a typical task have?
  3. Could each recurring meeting be replaced by a written page?
  4. Where is your team's "done" written down?
  5. Do shared decisions live in shared documents or in private chats?
  6. Who reviews, how many changes can they review per day, and is the review queue long or short?
  7. Does the team have enough automated tests to trust an AI draft?
  8. Which changes need two people to look?
  9. Do newcomers have small jobs to practice on?
  10. When something breaks, does the team ask "who did it wrong" or "which part of the process let it through"?

8. Conclusion#

We used to organize teams like assembly-line bakeries because every stage was costly. As AI makes drafting cheaper, many teams are trying a different style: a small bakery, each person going further, with an AI helper beside them. It means less waiting and less dropped context, but it moves the weight onto tasting, meaning reading, reviewing and taking responsibility.

Remember the loudspeaker. AI does not turn a messy team into a great one, it makes louder whatever the team already has. Fix the foundation (clear task descriptions, tests, a shared handbook, review rules) before adding assistants. Baking together is more fun than passing the baton, but only when the whole shop tastes carefully before anything goes to the counter.

References#

Figures come from public sources as of October 2026. Many sources are reports by technology companies or summaries, and some numbers are reported slightly differently, so open the original sources to check before quoting.