T-Shaped Developers: Why Breadth Without Depth Doesn't Survive the AI Coding Era

An AI coding agent generates a database migration that looks correct, runs cleanly in a test environment, and silently drops a column’s default value in production. Nobody on the team catches it until a null-constraint violation shows up three weeks later. The agent didn’t lack the syntax. It lacked the specific, hard-won knowledge that this particular migration pattern behaves differently under load with this particular database version, knowledge that lived in exactly one person’s head, and that person wasn’t the one who reviewed the PR.

That’s the shape of the problem AI coding agents have created for how developers should think about their own skills.

The T-shape, briefly

The T-shaped model has been around for a long time: a horizontal bar of broad, working familiarity across many areas (frontend, backend, infrastructure, data, testing, security), and a vertical stroke of genuine depth in one or two of them. It was originally a hiring and team-composition idea, mix T-shaped people so a team collectively covers breadth while still having real depth where it counts.

What’s changed isn’t the shape. It’s which half is under pressure.

Breadth got cheaper to fake

A developer with shallow, working knowledge of five frameworks used to be genuinely useful, because getting a basic feature shipped across a full stack required at least that much range. An AI coding agent now covers a meaningful chunk of that same ground: it can scaffold a REST endpoint, wire up a form, write a passable Dockerfile, and generate a CI config, all with syntax that looks correct and often is.

That doesn’t make breadth worthless. It makes shallow breadth alone a weaker competitive position than it used to be, because the thing that made it valuable, being able to produce plausible output across many domains, is exactly what agents do well. The gap that’s opening up isn’t between people who know more languages and people who know fewer. It’s between people who can tell when an agent’s plausible output is wrong, and people who can’t.

Depth is what catches the agent’s mistakes

The database migration example at the top isn’t hypothetical in shape, even if the specifics are composited. AI-generated code tends to fail in a specific way: it’s syntactically correct and follows common patterns, which is precisely why it’s dangerous when it’s subtly wrong. A shallow reviewer checks that the code looks like the kind of code that usually works. A deep reviewer, someone with real scar tissue in that specific domain, checks it against things that don’t show up in the code at all: how this database version handles this migration pattern under concurrent writes, why this particular auth flow has a known edge case with token refresh, what this queue’s delivery guarantees actually are versus what the documentation implies.

That kind of judgment doesn’t come from broad familiarity. It comes from having been burned by the specific failure mode before, or having gone deep enough to understand why it happens. This is the same argument we made about why take-home coding tests got worse, not better, once AI got involved: surface-level correctness is easy to produce and easy to fake, and the signal that actually predicts whether someone catches real problems has to come from somewhere deeper.

Why breadth still matters, just differently

None of this argues for abandoning breadth. An AI agent working through a full-stack feature will still hit boundaries, an ambiguous product requirement, an infrastructure constraint, a decision about which of three reasonable approaches fits this specific system, and someone needs enough range to make that call and keep directing the agent instead of getting stuck. A developer with deep backend expertise and zero frontend familiarity can’t effectively review or direct an agent building a UI, even if their backend judgment is excellent.

Breadth is what lets you stay in the loop across a whole task. Depth is what lets your judgment be worth something once you’re there. The T-shape hasn’t stopped being the right model. What’s changed is that the horizontal bar alone, without at least one deep column, now overlaps heavily with what an agent already covers on its own.

The harder problem: how do you build depth now

This is the sharpest version of the shift, and it lands hardest on junior developers. Depth used to get built gradually, through the accumulation of moderately difficult tasks done by hand: debugging a confusing null pointer, working out why a specific query is slow, tracing a race condition through logs at 2am. Those tasks were tedious, but the tedium was where the intuition came from. AI agents are increasingly good at exactly that category of task, which means the traditional path to depth is quietly eroding for anyone who lets the agent handle it every time.

The deliberate countermeasure is choosing, on purpose, to work through some of those tasks by hand, specifically in whatever area you’re trying to build real expertise in, even when the agent could finish it faster. That’s a real cost in short-term velocity for a longer-term gain in judgment, and it’s a trade most teams don’t structure time for. It’s worth structuring anyway, because the alternative is a team of people who can direct an agent across a wide surface but can’t tell when it’s confidently wrong, which is the exact failure mode showing up in production incidents already.

The practical takeaway

Pick one area, whatever intersects most with what could go wrong expensively in your specific codebase, and go deep enough in it that an AI agent’s mistake there is obvious to you before it’s obvious to whoever finds the bug in production. Keep the breadth too. It’s still what lets you work across a full task instead of stalling at the edge of your knowledge. But treat depth as the part of the T that’s now doing the harder, scarcer job, because it’s the part an agent can’t borrow from you.