Signal
Writing lines of code, once the core craft of software engineering, is now the least valuable step in the pipeline. Code generation has become a commodity, and what takes its place is taste: the ability to decide what should be built, judge whether an AI-generated solution is actually good, and spot when the machine has quietly gone wrong.
Anthropic co-founder Jack Clark put the shift in its most compact form on The Ezra Klein Show: “Everyone becomes a manager, and the thing that is increasingly limited is having good taste and intuitions about what to do next.” At a company where Claude now writes “comfortably the majority” of the code, Clark has watched the bottleneck move off typing entirely and onto judgment. “The value of more senior people with really, really well-calibrated intuitions and taste is going up,” he told Business Insider. That framing is the working definition for the rest of this piece. We’ve been tracking this signal since early February 2026, and it keeps surfacing in leadership talk across frontier labs and start-up culture alike.
Context
For decades, the software engineering ecosystem ran on a steady pipeline: juniors produced code, seniors validated it, and the industry grew its next generation of experts through deliberate apprenticeship. That model is now under structural pressure from three directions at once. AI coding tools and agentic systems have absorbed the repeatable, entry-level implementation work that historically justified junior headcount. The volume of AI-generated code has created a review bottleneck in turn: pull requests are 18% larger since widespread adoption, Jellyfish / OpenAI found, and incidents per pull request are up roughly a quarter, per Cortex. And the hiring market has responded by skipping the junior rung entirely: 48% of tech leaders report pressure to hire more senior engineers as teams get leaner, and 71% say their hiring is focused on high-impact roles rather than broad team growth, OfferZen reports.
What’s Happening
The Junior Employment Decline
Employment among software developers aged 22 to 25 fell nearly 20% between 2022 and 2025, Stanford Digital Economy Lab found, right as AI-powered coding tools were taking off. The rest of the data points the same way. Software engineering job postings remain roughly a quarter to a half below pre-pandemic levels, per Indeed Hiring Lab. The Class of 2025 saw 15% fewer full-time early-talent postings, while applications per job rose 30%, according to Handshake. This is a structural shift, and it was happening before the broader 2026 macro environment accelerated it. We explored the shape of that cognitive shift among junior and middle tiers in Complexity Climbing: The Hidden Pattern in AI; here we focus on what survives the change.
The Need for Engineering Taste
OfferZen’s engineering leadership research found that while 55% of tech leaders describe AI’s capabilities as overhyped, the skepticism is about teams still being early in the learning curve, before the real gains start to show, not about the tools themselves. The debate has moved past speed and tooling and onto taste.
Emma Tang, head of data infrastructure at OpenAI, put it directly: “Everybody can be a 10x engineer now, as long as you have people with good software taste.” Tibo, head of Codex at OpenAI, said the most successful engineers on his team “spend a lot more time thinking about their users” and “need their own compass,” they told The Pragmatic Engineer.
A Gap in Automatic Reviews
Other leaders at frontier AI labs have independently landed on the same conclusion: self-critique within AI systems is not enough.
At Anthropic, researcher Prithvi Rajasekaran formalized this into an engineering discipline. His harness design for long-running applications uses a multi-agent architecture with a generator and evaluator, inspired by GANs, where the evaluator grades outputs against concrete criteria for design quality, originality, craft, and functionality, as documented on Anthropic Engineering. The insight driving this work is simple: AI models are poor critics of their own output. When asked to evaluate work they have produced, agents tend to respond by confidently praising the work, even when, to a human observer, the quality is obviously lackluster.
Separate building from judging, and make that split explicit in how teams actually work.
What Do You Taste?
Taste is the quality of your internal evaluation function. Every time you exercise it, you are running an evaluation: comparing the current state against an internal standard and making a judgment. In a world where AI generates the code, the human’s job is evaluation: deciding what to build, judging whether the output is good enough, sensing when the architecture needs to change.

There are five zones where taste creates disproportionate value in the AI era, and most engineers are competing in only two of them. Mastering one or all of these zones isn’t a formal qualification, but it’s what sets applicants apart. The work is evolving from technical knowledge into quality assessment, and into being able to express an idea clearly enough that other people can act on it. Hindsight will be the best arbiter, but the adoption of AI systems that let anyone code means we’ve moved past programming competence alone.
- Quality judgment: Validating AI outputs thoroughly, catching the subtle bugs that automated systems miss. Depending on the language, you’ll see a glut of helper functions, three layers of exception handling, or a one-line wrapper-of-a-wrapper. It all looked great in the social post the model was trained on, but none of it fits your platform.
- User empathy: Understanding the domain deeply enough to make the right tradeoffs. Tenure and hard-won domain knowledge get eroded when AI averages everything toward the most generalized solution, not because anyone is missing the small details.
- System architecture: Knowing when a solution is elegant versus when it is a time bomb waiting to detonate under load. Frontier models will happily build a fortress, but that may pose obstacles if your user only needs magic-link logins.
- Problem selection: Choosing the right solutions to implement. Speed without judgment leads to bloated products, wasted effort, and missed opportunities.
- Communication and storytelling: Explaining why a system works the way it does, and whether a change made life easier for users or just added more surface area. Always, always know what AI-generated code is doing, even if exactly how is not immediately recallable.
The gap between “no taste” and “some taste” is enormous but closable. The engineer who goes from “takes tickets and implements them” to “proposes what to build based on user research and then implements it with AI, including the test suite and the architecture decisions” has made a career-changing leap. That leap is the whole difference.
A concrete example of taste-as-framework comes from Matt Pocock’s skills system, which encodes engineering judgment as executable, reviewable skill files. His code review skill doesn’t stop at “review the code”; it defines a two-axis review (standards vs. spec) and ships a fixed baseline of twelve code smells, documented on aihero.dev and GitHub.
Case Study: Linus Torvalds, Taste at Scale
The most vivid illustration of this shift comes from the person who arguably defined what it means to be a programmer, and he put it plainly at Open Source Summit India 2026 in Mumbai. As ZDNET reported: “Let’s be entirely honest. I hardly read code at all anymore. I’m not a programmer, I’m a development lead.”

After 35 years of maintaining the Linux kernel, Torvalds’s job has become evaluating whether the people sending patches actually understood what they were doing. He reads pull request descriptions more than diffs. Patches go out as suggestions (untested, explicitly provisional), and he expects the maintainers who know the subsystem to send the fix back. Merge conflicts he resolves from decades of pattern recognition, from reading the bigger picture rather than every line of code. As he told ZDNET: “When I do a pull request, I want to understand the bigger picture. It’s one of the reasons I ask for pull requests with very good explanations: I will read them. I want to understand what’s going on.”
That’s taste operating at the scale of the largest open-source project in the world. Torvalds’s unique capability is the system-level understanding built from living with the consequences of code over decades, not from writing C faster than anyone else. He tests for understanding explicitly by reading explanations rather than just code. And he is not worried about AI replacing engineers; he is worried about AI-assisted engineers who have not done the work of actually understanding their systems, Level Up Coding notes.
If the most consequential programmer alive says his job is no longer writing code, the industry should listen. The craft was never in the typing. It was in the thinking. Torvalds just made that visible by saying it out loud.
Why It Matters
For technical leaders, the strategic implications are immediate, but there is a disconnect on how to preempt detrimental changes to an organization and how to determine metrics or KPIs to map to this new skillset. The winning response: redesign the apprenticeship model around judgment development rather than task execution — reposition juniors as the humans who review AI output, document architectural decisions, and learn the codebase under deliberate senior mentorship, as explored in Complexity Climbing. Managers at all levels should also be mindful of sensational false flags and metrics for sizing up their engineering and research staff. A well known trap is that as soon as any metric is explicitly codified it ceases to be useful.
Token Capital Is a Fallacy: Taste Is the Metric
Some enterprises have tried to quantify AI impact the way they quantify any other investment, and the framing has a name: token capital. The idea, floated by Satya Nadella in June 2026 on Reid Hoffman’s Possible podcast and at the New York Times Hard Fork Live event, is that every company now holds two forms of capital: human capital (knowledge, judgment, relationships) and token capital (the AI capability a firm builds and owns, encoded in model weights, context windows, and reinforcement loops). That second form, he wrote on X on June 14, 2026, is “the firm’s AI capability it builds and owns.”
Treating that as a balance-sheet asset is seductive. It is also the wrong lens. The sheer volume of AI consultation and tokens a team consumes says nothing about sound understanding or a good product build. A team can burn an enormous budget of tokens and still produce output no one can explain, verify, or improve. Should “tokenmaxxing” be lauded as the word of the year for 2026? No, probably not, and IBM doesn’t think so either. Token counts measure spend, not comprehension. They measure how much the machine produced, which is precisely the thing that stopped being scarce. As a metric for engineering judgment, token capital is a fallacy.
The better metric is taste. It measures the part that still matters: whether the humans responsible for the output actually understand it well enough to steer the next iteration. Where token capital counts the machine’s output, taste measures the human’s comprehension and judgment layered on top of it.
A New Metric: Taste Among Cognitive Companions
Nadella’s sharper point was about the learning loop, and it deserves emphasis. Bring the models inside and own the loop where humans and agents compound each other’s work, rather than fire-and-forget agents that run unattended or “do it on my own” hand-coding. “The real opportunity is in building a learning loop on top of models where human capital and token capital compound,” he wrote.
The discipline behind that loop is economic. “The marginal cost of productivity improvement has to match the marginal cost of the token,” Nadella said on Hard Fork. Throwing frontier models at non-frontier problems, the “token maxing” from above, is a trap. The discipline is allocating tokens like the capital they are: deciding which problems deserve frontier intelligence and which need something leaner. “Don’t use frontier models for non-frontier problems.”
For individual engineers, the message is the same one that runs through this piece. The skill of writing code by hand is becoming less central to the job. Knowing what code should exist and whether it’s good enough was always the real skill. AI just exposed it by taking the typing away.
Looking Forward
The organizations that get ahead of this divide will be the ones that treat taste as a trainable skill, not an innate gift. There are concrete steps for different needs.
For individuals: Build an evaluation framework for AI-generated code. Pick a hard domain, solve it end-to-end with AI assistance, and deliberately develop the judgment to catch the model when it drifts. Study systems that fail, because failure teaches taste faster than success. A recent study by BCG claimed workers get as much as 8 hours a day back with AI usage but no guidance for what to do next. Individuals should reinvest that time honing their own taste for what’s next.
For teams: Implement structured internal apprenticeship. Redefine entry-level roles around judgment development. Have juniors own the review of AI output and the architecture notes, under close senior guidance. Measure taste explicitly in hiring: break down problems before prompting AI, validate outputs thoroughly, and understand whether a candidate can still code without AI when needed.
For the industry: The talent pipeline debt is real and compounding: companies that skip the junior hire today skip the senior talent they will need in 2031. The right question: how to redesign junior roles so they develop taste at the pace the market now demands.
Create more than you consume. Most of what you make will be mediocre, but that’s the process, not a failure. Taste itself may one day be automated too. But it will be a long time before a model has lived with the consequences of its decisions for thirty-five years. By then, the people who built that judgment will have built everything that matters.
Ready to Build Judgment Into Your Hiring Loop?
The deciding question is whether judgment can be developed on purpose, at scale, before the senior engineers who would teach it are swallowed by review work. Teams that solve this build a durable advantage; teams that don’t will find themselves unable to evaluate the output their own tools produce.
Interested in a more personalized discussion? We welcome you to consider an advisory services session. If you are restructuring a hiring loop to assess engineering taste or rebuilding a junior track around judgment instead of task execution, a session can surface the structural choices that matter most.
Want to see a signal every time we write? Sign up for the Signal posts.