Coding interviews were a proxy for engineering judgment. AI broke the proxy.

The T-shaped engineer is a familiar shape inside software organizations: one engineer who can move across many parts of a system (the horizontal bar) plus a deep specialty earned over years of watching things fail (the vertical bar). For most of the last decade, the vertical bar was the harder one to build and the easier one to defend. A new InfoWorld opinion column argues that agent tooling has flipped that asymmetry in roughly twelve months. The horizontal bar is wider than ever. The vertical bar is, in the author's word, "quietly getting shorter."

About four months ago, a front-end engineer on the author's team needed an infrastructure change. The old loop was to file a ticket and wait for the platform group, losing a day to a week. The new loop is to use the agent tooling and ship the change themselves. The code is, in the author's description, "occasionally brittle but it works" and ships in a fraction of the prior time. In one quarter, with the right agent tooling, that same engineer shipped a billing system, a data connector framework, infrastructure for isolating customers by region, and a consumption-based pricing implementation. Code passed review. Tests were green.

The trade-off the author names is not that engineers are getting worse. It is that the proxies engineering organizations used to measure judgment are no longer reaching the thing they were trying to measure. Green tests cannot tell you whether the person who shipped the work understood why the system needs redundancy in one specific place, where the failure modes are hiding, or which trade-offs the model made silently on their behalf. The same flattening shows up in hiring. The author describes a 20-minute working coding problem that would have taken two hours a year ago as now "mostly measuring prompting skill, not technical competence." Traditional coding interviews were an imperfect proxy for engineering judgment, and the tooling has, in the author's word, "obliterated" them.

The author sits at Thread AI, an AI infrastructure company whose engineering team has direct skin in the agent-tooling argument, and has rewritten their interview loop in response. The piece positions the question against two reductive framings the industry is using instead: celebrating that one person can do the work of five, and treating the shift as just the next round of tech layoffs. The author's standing concern is the vertical bar of mastery, not the headline productivity gain, and the broader question is which other org-level practices still need to be rebuilt. Code review norms, on-call rotations, mentorship pipelines, and the way engineering ladders define seniority all inherited their shape from a slower ship cycle.

The strongest version of the skeptic's case, which the column gestures at but does not engage, is that depth is being relocated rather than eroded. The argument goes that the years-of-failure-watching bar is now concentrated in incident response, in the small set of engineers who actually debug the post-deploy fire, and in the architectural decisions the agent cannot yet make. Under that reframe, mastery has not shortened; it has migrated into a smaller set of roles, and the horizontal bar has widened because the vertical bar has moved elsewhere. The author's own concern is closer to the loss frame, but the redistribution reading is the honest pressure test against it.

What an engineering org can do, on the terms the column lays out, is treat the proxy break as a forcing function. If green tests no longer reach judgment, code review has to reach further. Not "does this work" but "does the shipper understand why this works, and where it will fail." If the interview loop no longer reaches competence, the loop has to surface how a candidate reasons about trade-offs the model is silently making for them, rather than how fast they can produce working code. If mentorship pipelines inherited their shape from a world where breadth took a decade to acquire, the pipelines have to be rebuilt around an engineer who is touching every part of the system in year one. None of those redesigns is impossible, because they all assume the proxies are no longer doing the work they were hired to do.

The falsifier for the whole argument is the redistribution case above. If depth has migrated rather than eroded, the right response is to widen the surface area of incident response and architectural decision-making, not to rebuild every proxy the old ship cycle gave us. Either way, the proxies need to be re-examined. The author has already rewritten their interview loop. The harder question, which the column raises but does not answer, is which other parts of the engineering org still need the same rewrite.