TL;DR
- The defects moved. They used to sit inside a function, where the compiler, the linter and the tests caught them. Now they sit at the seams between files, where nothing automated can see them.
- A seam is only visible to someone holding both sides of it, so the work lands on the one or two people who do, and refuses to distribute.
- Seam knowledge lives in people or it lives nowhere. A team stops shipping these defects only when more people carry it.
- The signal is what an engineer does after a review comment: patch the line they were shown, or work out why it was wrong.
I build Pravaha, an AI coach for engineering teams. As I write this, around 300 engineers across seven organisations use it, some startups, some software services agencies. That puts me in a lot of their review threads.
The complaint I keep hearing from tech leads is that their review load climbs every week. Pull requests are getting bigger. They write the same comments over and over. The team ships faster than it ever has, and the lead is more tired than they have ever been.
The easy explanation is that AI made everyone careless. It is wrong, and it sends teams after the wrong fix.
The defects did not get more numerous. They moved.
The defects moved to the seams
Two from recent review threads, details filed off.
The trial email. A trial expiry template hardcoded a fourteen day trial. Trial length is a per tenant setting, and it is the same field the scheduler reads to decide when to send. A tenant on a thirty day trial got a well timed email announcing the end of their fourteen day trial.
The contradictory response. A session filter was applied to three values in an analytics payload and not to the two functions computing the rest. The endpoint returned a total of one unique user, directly above a list of four top users.
Open the changed files and the code is fine. The template is a reasonable template. Each filter is correctly written. Both defects live in the relationship between the changed file and something else.
That is the shift. Junior defects used to sit inside the unit: wrong syntax, a misused framework, a function that did not work. The compiler caught those, then the linter, then the tests, and review saw whatever survived. Seam defects pass all three, because each piece is well formed on its own. Nothing in your pipeline compares an email template against the tenant configuration.
Which is why it lands on your most expensive person. A seam is only visible to someone holding both sides of it, and that knowledge is not in the diff, the ticket, or the context window. No linter holds two files in mind at once, and neither does the model that wrote them. Seam knowledge lives in people or it lives nowhere, so a team stops shipping these defects only when more people carry it.
Who is building seam knowledge, and who is routing around it
You cannot tell by reading the code, and you cannot tell from how many review comments someone gets, because strong engineers get plenty. You can tell from what they do with one.
Here are those same two defects, back in review.
The trial email BAD
Trial length is per tenant, and the scheduler already reads that field to decide when to send this. The template has to receive it too.
Why this is bad. The fix is correct and the reviewer approved it. But the same hardcoded fourteen was still sitting in the reminder email and the in-app banner, because the author patched the line they were shown rather than asking why a tenant setting had been turned into a constant.
The contradictory response BAD
totalUniqueUsers says 1 and topUsers has four entries in it. You filtered three of these values and left the two functions computing the rest untouched.
And groupEventsByUser.
Why this is bad. The author changed what a session means and then fixed the consumers one at a time as they were pointed out. Nobody went looking for the others. The reviewer was doing the tracing, which is the job the pull request was supposed to have done.
Now the same situation with the knowledge present.
The swallowed click GOOD
Convincing.
Why this is good. Rendering, event handling and input all had to be held at once to see this, and no reviewer had to hold them for the author. That is the same knowledge the two above were missing, in someone who had it.
All three changed code. All three ended with green tests. Two fixed the line they were shown. One understood the system it sat in.
None of this is about whether AI was involved. The engineer who traced the swallowed click may well have had a model help, and that is a good use of one. The question is whether the person ends up holding the understanding. An engineer who uses a tool to finish the ticket will be faster than everyone else for about a year. One who uses it to work out why is still learning, while the tools keep getting better at exactly the part the first one handed over.
What Pravaha does
Pravaha reads these conversations on every pull request your team raises, and works out which kind it is: an engineer who is learning, or an engineer who just needed the pull request approved. It keeps that history, so a gap that keeps coming back stops looking like a bad day and starts looking like a missing concept. Then it builds short courses aimed at that concept, so the same mistake stops turning up in the pull requests after it.
None of this requires anyone to use less AI. It requires that somebody, before production, has held the whole thing in their head and can say so.