There are two dominant narratives about AI and software engineers right now. The first is about acceleration: AI makes engineers faster, more productive, more leveraged. The constraint is output, and AI removes it. The second is about obsolescence: AI will eventually replace engineers entirely, and the profession is living on borrowed time.
Both narratives share an assumption worth examining. They both treat engineering as fundamentally about producing code. One says AI helps engineers produce more of it. The other says AI will eventually produce it without them.
Neither asks what happens if production was never the thing that mattered most.
AI isn't just making engineers faster, and it isn't making them obsolete. It's changing what engineering work actually is. And that change forces a question most teams haven't asked explicitly: are we building an organization that produces, or one that reasons? Are we developing engineers who move fast, or engineers whose judgment can be seen, challenged, and built on by others? Are we optimizing for individual output, or for the team's collective capacity to think?
These aren't the same bet. And the engineering organizations that treat them as interchangeable are going to discover the difference the hard way.
What follows is an argument about what makes engineers valuable when AI can produce the code, why the answer involves something most people assume can't be taught, and what it would take to build engineering organizations around it.
Visible Reasoning as the Work Product
The principle that engineers should make their thinking visible isn't new. Any manager knows that the gap between a strong mid-level engineer and a senior one has less to do with technical skill than with whether their judgment is legible to the people around them. The best teams have always used code review as a reasoning surface, always tried to evaluate judgment alongside delivery.
But the orientation behind these practices has mostly been the exception. Most organizations have code review, design discussions, and postmortems. Far fewer use them consistently as reasoning surfaces: places where assumptions are named, tradeoffs are weighed, and judgment is developed rather than just evaluated. The practices exist widely. The intent to use them as instruments of visible reasoning has been maintained by individual leaders rather than embedded in organizational defaults. And the cost of leaving it that way is about to get much higher.
The trajectory is clear: engineers are increasingly directing AI agents to produce implementations rather than writing code themselves. They frame problems. They define constraints. They evaluate outputs. They make judgment calls about what ships. The code itself is increasingly a byproduct of those decisions rather than the core work product.
The engineer emerging on the other side of this transition will operate at a fundamentally different level of abstraction. Their value is entirely in the quality of their reasoning: how they decompose problems, what constraints they define, how they evaluate whether an AI-generated solution is actually correct, and whether they can explain why they accepted one approach over another.
If that reasoning is invisible, there is nothing left to evaluate. The work product is the thinking. If the thinking can't be seen, the engineer's contribution doesn't exist in any form the team can learn from, challenge, or build on.
Some would argue that's fine, that if the output works, the reasoning is irrelevant. But outcomes are a lagging indicator of judgment quality. Code that works today isn't evidence that the reasoning was sound. It's evidence the reasoning hasn't been tested by production yet.
An engineer who writes code at least leaves behind an artifact that others can read, even if the reasoning was never explained. The code is a partial record. An engineer who directs an AI agent and ships the output without visible reasoning leaves behind almost nothing. The agent doesn't preserve intent. It doesn't record which alternatives were considered. In a world where the code is generated, the reasoning is the only durable artifact the engineer produces. If it isn't externalized, it's gone. And what's lost isn't just one person's thinking. It's the material the rest of the team would have learned from.
This creates a development challenge the profession hasn't faced before.
The Erosion of How Engineers Build Understanding
Engineers have always built deep system understanding through direct engagement. Writing code was one path, but not the only one. Being on-call, debugging production incidents, reading other people's code, sitting in architecture reviews, learning from the senior engineer who'd say "we tried that in 2011 and here's why it didn't work." All of these built the intuition that later made engineers effective at higher levels of abstraction. Institutional stability helped too. When people stayed at companies for a decade, knowledge didn't need to be documented because the people who held it were still around.
That foundation has been eroding for years. Shorter tenures, distributed teams, and frequent reorgs meant institutional knowledge was already walking out the door long before AI. AI is compounding a problem that was already severe.
AI-native engineers may never build intuition through any of the traditional channels. If their primary interaction with code is reviewing AI-generated output rather than writing it, if they're joining distributed teams where the long-tenured engineer who remembers why things were built a certain way no longer exists, they arrive at the abstraction layer without having earned the understanding that makes operating there safe. They can direct agents effectively in familiar territory, but they may not be able to tell when the agent is confidently wrong, because they've never worked at the layer where that judgment forms.
Genuine understanding isn't produced by smooth execution. It's produced by encountering resistance -- moments where your model of the system collides with the system's actual behavior and something has to give.
The engineer who debugs a production failure and discovers their assumptions were wrong is being forced to think in a way that permanently changes how they see the system. AI agents absorb exactly this kind of friction. They handle the implementation details that would have forced the engineer to confront where their mental model breaks down. The engineer gets a working output without ever hitting the moment where their understanding was inadequate. They can operate fluently: recognizing patterns, directing agents, shipping results. They never encounter the resistance that generates genuine judgment.
There's a predictable generational tension embedded in this that most teams haven't named. Engineers who built their intuition through years of hands-on work look at AI-native engineers and wonder whether the judgment is actually there. AI-native engineers look at the traditional path and see an apprenticeship model designed for a world that no longer exists. Neither will be entirely wrong.
The harder thing to see is the drift. Organizational incentives almost always favor velocity over legibility by default. The pattern is well-documented: agile standups replaced design discussions. Continuous deployment replaced release reviews. Microservices replaced the architectural conversations that monoliths forced. Each time, the easy-to-measure metrics improved while harder-to-measure organizational understanding quietly degraded. AI is the most powerful accelerant of this pattern yet. The AI-native mode wins on every metric that's easy to measure, and deep understanding erodes quietly because its value doesn't show up in dashboards. The result is a slow migration toward shallow judgment masked by strong output numbers -- a brittleness invisible until a crisis reveals how little the team actually understands about the systems it's been shipping into.
The path to senior-level judgment is being disrupted at the same time that senior-level judgment is becoming the primary thing we need from engineers. And the default organizational dynamics make the problem worse unless the feedback loops are deliberately designed to counteract them.
Beyond Assessment: The Question of Taste
When the engineer's primary contribution is reasoning rather than code, most existing assessment signals break down. How do you evaluate a code review when the reviewer is assessing AI-generated code they didn't write, and the question "why did you do it this way" may not have a clear answer? How do you distinguish an engineer who made a thoughtful judgment call from one who accepted the first plausible output?
You evaluate the reasoning directly. If an engineer frames a problem clearly, defines constraints explicitly, documents why they chose one approach over another, and explains what would make them reconsider, you can evaluate every one of those things. You can coach on them. You can watch them improve.
If they don't, you're evaluating outcomes and hoping the judgment behind them was sound. With AI compounding the volume of decisions an engineer makes daily, that's a bet that gets worse over time.
But visible reasoning, as important as it is, may not be the deepest thing we need to develop.
There's a reasonable case that in an AI-native world, the scarce resource isn't legible decision-making at all. It's something less definable. Call it taste: the ability to recognize which problem is worth solving, which solution is elegant versus merely correct, which technical direction opens future possibilities rather than closing them. When AI can generate ten working implementations of anything, reasoning about how to build is table stakes. The real differentiator is knowing what to build and recognizing the difference between a solution that works and one that's right.
I find this compelling, and I think it identifies something real. But it also reveals an assumption worth questioning: that taste is unteachable.
What Taste Is and How It Develops
Engineering taste is the capacity to perceive a system at multiple levels of abstraction simultaneously and to judge well in situations where no rule tells you what to do. An engineer with taste can look at an architectural decision and see its concrete consequences downstream. They can look at a specific bug and see the systemic pattern it reveals. They hold both levels at once: the general principle and the particular case, the abstract design and the material reality of what happens when that design meets production. And when they encounter a problem that no framework, checklist, or best practice fully addresses, which is most problems worth solving, they perceive the right response before they can fully articulate why.
Engineers who lack taste aren't lacking intelligence. They're stuck at one level. Either they reason abstractly and design elegant systems that don't survive contact with real constraints, or they solve the immediate problem in front of them without seeing the larger shape it fits into. Taste is what happens when those two modes of perception integrate: the ability to move between them fluidly, to see how a decision at one level creates consequences at another.
That capacity isn't innate. It's perceptual. And it can't be taught through instruction, because instruction gives you rules and frameworks, and taste is precisely the skill of operating where rules and frameworks run out. But it can be developed through structured practice, through repeated encounters with situations that demand judgment, where the reasoning is made visible enough to be engaged with, refined, and internalized.
The act of articulating your reasoning transforms the reasoning itself. When an engineer writes down how they're framing a problem, they regularly discover mid-sentence that their framing has a gap, that an assumption doesn't hold, that their uncertainty lives somewhere different than they thought. Making the implicit explicit doesn't just produce a record. It surfaces commitments you were already operating on and makes them available for scrutiny: your own first, and then others'.
This is the expressive power of visible reasoning. It doesn't merely describe thinking. It advances it. An engineer who operates on unarticulated assumptions is bound by them in ways they can't examine. The moment those assumptions are stated, in a PR description, a design discussion, a ticket comment, they become something the engineer can evaluate, revise, and improve. The practice of articulation is itself a form of reasoning, not a report filed after reasoning is complete.
The practices that make reasoning visible to others are the same practices that make reasoning visible to yourself. And both are the practices that build taste. They aren't three separate goals served by one set of habits. They're the same process operating at different scales.
When an engineer learns to frame a problem explicitly before building, they're practicing the movement from concrete situation to abstract structure, learning what a good frame looks like by attempting frames and discovering which ones hold up. When they name tradeoffs across multiple dimensions, maintainability, operational risk, cost of change, delivery time, they're building the capacity to see a decision from several angles at once. When they surface uncertainty early, saying "this explanation doesn't feel right" before they can articulate why, they're developing the instinct to notice when their model of the system has diverged from its actual behavior.
None of those practices is taste. But together they build the perceptual infrastructure that taste operates on. They train the engineer's capacity to observe: to see what the system is doing, what it isn't showing, and where their understanding has quietly become wrong. The quality of an engineer's interventions in a system is always bounded by the quality of their observation of it. Taste is what observation looks like when it's been refined through practice.
The engineers who develop real taste are the ones who've built enough reps at perceiving systems from multiple levels, holding abstraction and concreteness in tension, and questioning their own models, that they start recognizing patterns before they can fully explain them. That recognition is what we experience as taste. And the reps that produce it can be structured, practiced, and coached, but only if the reasoning is visible.
Taste that stays in one person's head is just intuition. It might produce excellent individual decisions, but it can't teach, it can't scale, and it can't be engaged with by the team.
Taste becomes organizational leverage only when it's legible enough for others to learn from. The architect with extraordinary instincts who can't explain their reasoning doesn't make the team better. They make the team dependent.
Developing Taste Through Practice
What does development look like when it's oriented around building this capacity?
The practices themselves will look familiar. Code review, design discussions, pairing, decision documentation. None of this is new. What's new is the purpose they need to serve. These practices used to be about quality assurance and knowledge transfer for engineers who had already built foundational understanding through implementation. Now they need to do something harder: develop the perceptual capacity of engineers who may have never encountered the system's resistance to their assumptions firsthand, and produce the only durable reasoning artifacts that will exist in a world where the code is generated. The ceremonies look the same. The intent behind them is fundamentally different.
Structured investigation as a teaching method: engineers tracing problems through layers of a system with a more experienced engineer modeling not just the diagnosis but the way of looking. Which level of abstraction are we operating at? What would we expect to see if our model were correct? Where has our understanding diverged from what the system is actually doing? The goal isn't to transfer the answer. It's to transfer the perception. And more fundamentally, it's to engineer a productive confrontation between the engineer's assumptions and the system's actual behavior. The kind of encounter that forces genuine thinking rather than allowing the engineer to fall back on pattern recognition. For AI-native engineers who may rarely encounter this friction in their normal workflow, structured investigation may be the primary mechanism through which deep system understanding develops at all.
Code review reoriented around understanding: not "is this implementation correct" but "do you understand why this implementation is correct, and what would make it wrong." When the engineer didn't write the code, that second question stops being rhetorical. This forces the movement between abstraction and concreteness that taste requires. The implementation is concrete. The "what would make it wrong" is abstract. Holding both in view is the practice.
Design discussions where the expected output isn't a solution but a framed problem with named constraints, considered alternatives, and an explicit rationale for the recommended direction. Every one of those elements exercises multi-level perception: seeing the problem from above and below, holding the general and the particular simultaneously.
Decision logs that capture not what was built but what was weighed. Not as a reporting mechanism, but as shared material that distributed decision-makers learn from, not by copying the decisions, but by engaging with the perception behind them.
Underneath all of it, a consistent expectation that reasoning is the work product. Showing your thinking isn't overhead. It's the primary artifact you produce as an engineer, the thing that makes your judgment accessible, improvable, and durable. Not because a manager needs to see it, but because your peers need to engage with it. And it's the structured practice through which engineering taste actually develops.
This doesn't mean documenting everything. If every engineer surfaces every thought in every ticket and PR, the result isn't organizational intelligence, it's noise. The discipline is making reasoning visible at the level where it can be engaged with productively: the assumptions that could be wrong, the tradeoffs that shaped the approach, the uncertainties that might matter later. Not a comprehensive record, but a selective practice of exposing the thinking that others need to see in order to challenge, refine, or build on it.
The Organizational Opportunity
None of this happens on its own. Visible reasoning doesn't emerge by default, and neither does taste. Someone has to build the conditions for both. That means creating environments where surfacing uncertainty is expected rather than penalized, where engaging with someone's reasoning is treated as seriously as reviewing their code, and where the team's capacity to perceive clearly is developed as deliberately as its capacity to deliver.
If you reward delivery and ignore legibility, you'll get engineers who deliver. You won't get engineers whose judgment scales.
But there's something more fundamental at stake than defense against invisible judgment.
Before AI, there was a hard tradeoff between speed and learning. An organization could ship fast or it could reason carefully, but doing both required extraordinary discipline because the reasoning had to happen at human speed. Every hour spent on a design discussion, a decision log, a structured investigation was an hour not spent shipping. The best organizations managed this tension, but it was always a tension.
AI dissolves it. If AI handles more of the production, the cognitive bandwidth that was previously consumed by implementation becomes available for reasoning, evaluation, and learning. An organization that uses AI primarily to ship faster is using it to do the same thing cheaper. An organization that uses AI to free its engineers to reason more deeply is doing something qualitatively different. It's investing in the capacity that makes the organization smarter over time.
This is what's genuinely new: not that visible reasoning matters more, but that AI makes it possible for organizations to learn from their own decisions at a pace and scale that was never before achievable. Every externalized assumption, every named tradeoff, every surfaced uncertainty isn't just protection against invisible judgment. It's organizational learning material. It compounds the way a culture compounds. The shared frames become more refined. The common language for tradeoffs becomes more precise. The team's collective capacity to perceive systems at multiple levels deepens. Each engineer who develops within that culture and contributes their visible reasoning back to it makes the culture itself more capable of developing the next engineer.
The scarce resource is no longer the time to reason. It's the organizational will to invest in a culture of reasoning, to treat visible thinking not as overhead but as the medium through which the organization develops its collective capacity for judgment.
The organizations that understand this won't just use AI to ship faster. They'll use it to build richer engineering cultures, teams whose reasoning compounds into shared perception, whose collective taste sharpens with every decision made visible, and whose capacity to develop the next generation of engineers outpaces their competitors' capacity to merely produce.
Even for organizations where velocity is the survival constraint, the question remains: velocity toward what? Shipping faster is a means. The organizations that compound their advantage over time are the ones that use AI not just to move faster, but to see more clearly.
From Individual Judgment to Collective Intelligence
I've watched an engineer go from someone whose excellent judgment was entirely invisible to someone whose reasoning shaped how a team navigated a complex, high-stakes system. Not because they learned new technical skills. The capability was already there. The visibility was the unlock.
But the real lesson wasn't about that one engineer. When one person's reasoning became visible, it changed how the rest of the team operated. Other engineers started engaging with that thinking, challenging it, refining their own perception against it. The team's collective model of the system became sharper than any individual's understanding. Decisions improved not because better information appeared, but because the information that was already distributed across the team became connected.
In an AI-native environment, the goal isn't just engineers who reason well individually. It's teams whose organizational capacity to reason exceeds what any single member could produce alone: where visible reasoning flows between people, where one engineer's framing sharpens another's perception, where the shared model of the system is continuously challenged and corrected. Where the collective capacity to see clearly is distributed, durable, and not dependent on any one person.
This is the difference between a group of good engineers and an engineering organization that actually thinks. And it only emerges when reasoning is the visible, shared, primary work product of the team, not a byproduct of individual effort.
In fast-moving systems, the teams that scale best are not the ones that ship the most code, but the ones that can still explain why their systems behave the way they do.
As we develop the next generation of engineers -- the ones who will build and direct systems more powerful than anything we've worked with -- it's worth asking: what are we actually building?
A collection of individuals who produce? Or an organization that can see clearly, reason collectively, and leave behind a shared understanding that outlasts any single contributor?
When your best engineers leave -- and they will -- what survives? Their code, which an agent could have written? Or the team's capacity to reason about what comes next?