12 Engineers and Nobody Reads the Code

Picture a company with twelve engineers. Decent salaries, a busy Slack, a nice office. Every one of them works ten hours a day and every one of them ships a lot. The dashboard shows hundreds of commits a week, and the boss is happy with it.

Now walk up to any of those twelve and ask how the payment flow works. Or why some orders show up twice. Or what happens when the courier's system goes down. You'll get a long pause and then "let me check". And "let me check" means opening the AI and asking it.

What ten hours looks like now

A normal day on this team goes like this. Grab a ticket. Paste it into the AI. Let it write the change, run it, see the screen load, push. Next ticket. Do that fifteen times and go home tired.

Tired is the important bit. These people aren't slacking. They work harder than most teams did five years ago. They just spend all that effort moving code around and none of it understanding what the code does.

The old way had a speed limit built in. Before you could change something, you had to read the code around it. So after a year on the job, everyone knew some part of the system really well. That reading never showed up on a timesheet, but it's where all the team's knowledge came from. Take it away and the team still ships. It just stops learning anything.

The review that isn't a review

Most teams have a safety net for this. Someone else checks your change before it goes live. On this team, the reviewer is also doing ten hours of their own tickets. A 900-line change lands in their queue at 6pm. They scroll through it, it looks tidy, the tests are green, and they approve it.

Some teams go one step further and let the AI review what the AI wrote. So the code was written by a machine, checked by a machine, and approved by a person who pressed Enter twice. That's a lot of review steps with no reading anywhere in them.

We wrote about one person doing this in The One Who Keeps Pressing Enter. One person is a bad habit you can fix. When all twelve work like that, it's how your company builds software now, and that's much harder to see from the top.

Busy looks a lot like progress

From the owner's chair, this team looks great. Tickets get closed, commits go up, and there's a new feature to demo every Friday. Every number you'd normally use to judge a team is going the right way.

None of those numbers measure what you need, though. What you need is people who know how your business runs inside the software. You can't see that on a dashboard. You only find out how much of it you have on the day something goes wrong.

The night something breaks

Say it's Saturday night and customers are getting charged twice. You call the team. All twelve join the call, which feels good for about five minutes.

Then you notice what they're doing. Every one of them has the AI open. They're pasting in error logs and asking it what the code does. Twelve people reading your payment system for the first time, at 11pm, while your customers are on the phone with their bank.

A team with one person who had read the payment code would fix this in twenty minutes. This team takes four hours, and the fix is one more change that nobody reads. We told a similar story in The Server Nobody Could Turn Off. There, it took six years for the knowledge to walk out the door. Here it never came in.

Twelve people and no owners

Every system needs someone who can say "that part is mine, and I know why it works like that". It's the most useful thing a senior engineer gives you. It's also the thing that hurts most when they leave.

On this team, no part of the system has an owner. Everyone has touched everything and nobody knows any of it. So when someone resigns, you lose nothing. That sounds like good news until you realise it means there was nothing there to lose.

Hiring more people won't fix it. We covered that in More Programmers, More Mess. A thirteenth engineer who also doesn't read just adds a thirteenth stream of code nobody understands.

Three who read beat twelve who don't

We're not telling you to ban AI. We use it every day on every project. The fix is to put reading back into the job and pay for it on purpose.

A team of three or four engineers who read what goes in will ship less code than your twelve. They'll also ship far fewer bugs, and when something breaks at 11pm they'll know where to look. For most businesses, that's worth a lot more than the extra commits.

Three questions for your team this week

You don't need to read code to check for this. Ask these at your next meeting and watch how fast the answers come.

A good team answers these in seconds, and they like being asked. If twelve people go quiet at once, you've learned more than any dashboard could tell you.

What you're paying for

Twelve engineers at ten hours a day is 120 hours of work, every day. That's a big salary bill. If none of those hours go into understanding the system, you're paying for a very fast, very expensive typing pool.

Speed is nice to have. But your software is only as safe as the knowledge sitting in someone's head, and on a team like this that number is zero. No report shows it. You find out on a Saturday night.

So next time you look at your team, count the people who read. Ignore how many ship.