The Missing In-Between

(And no, this is not "The Messy In-Between: Tech Edition." That name belongs to Murugi Munyi and Lydia K.M., and I would like this post to survive its first week online without a copyright strike. Mine is about a different kind of mess: the one in your codebase.)

Here is a sentence that should worry you more than it does: a working app shipped in 2026, and the person who built it could not tell you how it actually works.

That is not a hypothetical. It happened, publicly, to a vibe coded app that leaked 1.5 million API keys and 35,000 user emails because of a misconfigured database. The founder's own explanation was that they had never written a single line of code by hand. The app worked, right up until it very publicly did not.

I want to talk about the gap that made that possible, why it is getting wider, and why the people who can stand in the middle of it are about to become the most valuable engineers on the continent.

#Two tribes, one keyboard

Right now, software engineering has split into two tribes that barely speak the same language.

Tribe one is the new generation. They grew up with ChatGPT already invented. They describe what they want in plain English, the AI writes it, it runs, they ship it. Some of them have never opened a debugger. Why would they? The machine writes the code, the code works, next feature. As of 2026, over nine in ten US developers use AI tools daily, and roughly four in every ten lines of code being written globally are AI generated. This is not a fringe habit. It is the default.

Tribe two is the old guard. They learned to code the hard way: reading documentation nobody summarized for them, chasing a null pointer at 2 a.m., understanding why a for loop behaves differently than they expected. They can read a stack trace the way a mechanic reads an engine sound. Many of them are now slower to adopt AI tools, not because they are stubborn, but because they have been burned enough times to be suspicious of anything that looks too easy.

Both tribes think the other one is doing it wrong. Both are partly right, and that is exactly the problem.

#The part where I get harsh

If you are in tribe one and you are annoyed right now, good, keep reading.

The industry has quietly built up a mountain of evidence that "the AI wrote it and it works" is not the same thing as "the AI wrote it and it is safe." A widely cited 2026 study of AI generated code found it was nearly three times more likely to contain cross site scripting vulnerabilities than human written code, and failed basic security tests in close to half of the samples tested across more than a hundred models. A separate industry survey found that 43% of AI generated code changes needed additional debugging after they had already been deployed to production. GitHub's own data shows AI assisted developers shipping around 55% more code per week, and production bug rates running two to three times higher on that same code, mostly logic errors, the kind that only shows up once real users start doing unexpected things with your app.

Here is the part that should really sting: Stack Overflow's 2025 developer survey found that the vast majority of developers now use AI tools daily, while trust in the accuracy of what those tools produce has fallen to under a third. Read that again. We have built an entire generation of engineers who use a tool constantly and do not believe it, and ship its output anyway. That is not adoption. That is a coping mechanism.

If your entire skill set is "describe the feature, accept the suggestion, ship it," you are not an engineer yet. You are a very fast, very confident intermediary between a client and a language model, and the moment something breaks in a way the model cannot explain to you either, you are stuck. Not because AI failed you. Because you never learned what the code underneath the suggestion was actually doing.

That is the harsh part. Here is the hopeful part.

#The missing in-between

The most valuable person in a software team in 2026 is not the fastest prompter and it is not the purist who refuses to touch AI on principle. It is the engineer who can do both: use the AI to move fast, and then actually read what it handed back, catch the subtly wrong logic before it reaches a customer, and fix it by hand when the model gets stuck in a loop of its own bad suggestions.

That person is rare, and getting rarer, precisely because the industry is currently optimizing junior engineers straight into tribe one. Bootcamps, tutorials and "build an app in a weekend" content teach prompting. Almost nobody is teaching the underlying comprehension that makes prompting safe to rely on. The result is a widening hole in the middle of the talent pool exactly where the most important skill lives.

This is not really about whether AI shuts down one day. It probably will not. The real, current version of the problem is simpler: AI already generates code faster than most teams can properly review it, and someone in the room has to be able to catch the mistake before a client does. That someone needs to have written enough code by hand to recognize when something is subtly wrong, not just syntactically fine.

#What this actually looks like day to day

Concretely, the in-between engineer is the one who:

• Reads the AI generated pull request line by line before it merges, not just skims the diff for red squiggly lines.
• Can explain, in plain terms, why a piece of AI generated code works, not only that it passed the test.
• Knows when a task is a genuinely good fit for AI (boilerplate, CRUD, a dashboard) versus when it is not (authentication, payment logic, anything security critical), because they understand what is actually happening under those systems.
• Can sit down and fix production code by hand at 2 a.m. when the AI is confidently generating a fourth wrong fix in a row.

None of that requires rejecting AI. It requires having earned the right to trust your own judgment over the model's, which only comes from having done the work the model is now doing for everyone else.

#The hopeful bit, properly

If you are early in your career and reading this feeling exposed, here is the actual good news: this gap is closeable, and it is closeable faster than people think, because most of what closes it is not years of tenure. It is deliberate practice with the unglamorous stuff. Read code you did not write. Debug something without letting the AI touch it first. Ask why a fix works before you accept it. Build one small thing entirely by hand, badly, on purpose, so you know what "by hand" actually costs and what it buys you.

You do not need to pick a tribe. You need to refuse to stay in either one. Use the AI, it is a genuinely extraordinary tool. Just make sure that if it disappeared from your workflow tomorrow, you would still be able to do your job, even slower and even more annoyed about it.

That is the missing in-between. Go stand in it. It is surprisingly uncrowded up here.