Taste looks subjective until experienced practitioners converge. The convergence comes from shared constraints — and AI is removing them.
In 1980, Abbie Conant auditioned behind a screen for a trombone position with the Munich Philharmonic. The jury selected her. When the screen was lifted, the orchestra’s music director, Sergiu Celibidache, reportedly said: someone made a mistake here.
No one disputed the playing. The dispute was about everything else.
Behind the screen, the jury’s ears converged. They tracked real qualities — tone, phrasing, structural command of the piece — without knowing who held the instrument. When the screen came up, identity returned: gender, expectation, the accumulated weight of who was supposed to hold that chair. The ears had measured something. That something wasn’t the only force acting on the judgment.
Calling it objective ignores what happened after the screen came up. Calling it subjective ignores the convergence that happened before. Taste sits in a space that neither word reaches. By taste I mean something specific: discrimination trained under consequence — the capacity to notice which differences matter before they become failures.
What convergence looks like
By the mid-2020s, a pattern had become visible in software architecture. A decade earlier, the industry had embraced microservices — breaking large applications into dozens of small, independent pieces that could be built and deployed separately. The pitch was autonomy: each team owns its service, deploys on its own schedule, picks its own tools. Engineers who had independently built and operated these systems — at different companies, with different technologies, over different decades — arrived at overlapping conclusions about where the pitch broke down.
The convergence wasn’t on what to do instead. It was on what hurt. A retry loop in one service silently doubled charges in another. A schema migration that passed every test corrupted data under real traffic because two services disagreed about what a field meant. The independence each team was supposed to gain was consumed by the effort of keeping everything consistent — and the worst failures were the ones where dashboards stayed green while the system quietly drifted out of truth.
These engineers hadn’t coordinated. They’d never been in the same room. The architecture taught them all the same things.
They still disagreed about alternatives — when to split, how far to consolidate, whether the monolith was a destination or a starting position. But the band of disagreement was narrow compared to the spread among developers who had read about both approaches and operated neither at scale. You see the same thing in surgery, in structural engineering. People who have done the work long enough start noticing the same hazards, even when they can’t always name them.
Scar tissue with opinions
An editor’s ear for prose wasn’t educated by studying grammar. It was educated by reading thousands of manuscripts under conditions where the judgment carried weight — an author’s career on the line, a print run committed before the final pass. Each cut that turned out to have been load-bearing left a residue. Less a rule than a sensitivity. You learn, eventually, that a sentence can be correct and still be wrong for the paragraph it sits in — and you learn it because you once let one through and watched it flatten everything around it.
Engineering works the same way. Every senior developer carries the memory of systems that broke in ways they should have seen coming. The abstraction that looked elegant until it met production traffic. The caching layer that saved forty milliseconds and created a week of stale-state debugging. The “temporary” workaround that survived three years because nobody understood it well enough to remove it. These aren’t lessons from a textbook. They’re more like weather you’ve lived through.
I’ve watched it happen in code review. Someone stops scrolling, stares at a line that looks fine, and says something like “I don’t love this.” Pressed for a reason, they reach for a principle — separation of concerns, maybe, or coupling — but the principle isn’t really what’s talking. What’s talking is a night two years ago when something shaped exactly like this silently broke a queue, and they spent four hours on a call with infrastructure trying to understand why messages were dropping.
These failures don’t teach principles. They teach flinches. Not every flinch is wisdom — some are overcorrections, souvenirs from a single deployment that went sideways in a way that was never going to repeat. But reality keeps showing up. The false flinches wear away over time. What survives is something harder to name than a best practice but more useful in the moment it matters. The engineer who has been burned by premature optimization doesn’t apply a rule against it. She feels the weight of it differently. The code looks the same on screen. It doesn’t feel the same in her hands.
Taste is what you have after the constraints have done their work on you.
But if taste is personal — built from individual failure — why does experience produce agreement rather than idiosyncrasy? Because the constraints are shared. Gravity is the same for every architect. Memory allocation punishes every systems programmer along the same axes. The human body breaks along predictable lines for every surgeon. Each practitioner carries their own failures, but the failure space has structure. The scars are personal. What caused them is not.
Removing the teacher
This is where the argument turns from observation to problem.
AI is removing the low-level encounters with failure that used to build practitioner judgment. That is part of its value — and possibly part of its cost.
Consider a junior engineer who joins a team using an AI coding assistant. She writes a migration that adds a NOT NULL constraint to the organization_id column on the invoices table. The assistant catches it immediately — flags that 200,000 existing rows have null values from before the column existed, that the migration will lock the table for the duration of the backfill, and that the payments service reads from this table every thirty seconds. It suggests a three-step approach: backfill the nulls, add the constraint, then update the application code. She follows the suggestion. Takes about twenty minutes.
She never sees what would have happened. The table lock during peak hours. The payments service timing out. Alerts firing. The senior engineer on the team — the one who’s been there four years — getting paged at dinner, laptop open on the kitchen counter, running queries to figure out how many rows are affected and whether the billing pipeline has already started reading nulls. That particular silence while you wait for a count query on a production table you probably shouldn’t have touched. She never has the quiet conversation the next morning, the one where that engineer explains, with a patience that is clearly hard-won, that constraint migrations on hot tables are the kind you plan over lunch, not the kind you push before standup. The assistant was right. And the thing that would have taught her to feel the weight of a table other services depend on — to hesitate before touching shared state — never happened.
Six months later, she reviews a pull request the model wrote. A service that caches user permissions in memory and refreshes them every five minutes. Tests pass. The invalidation logic is clean. She reads through it carefully, finds nothing to flag. It will work perfectly until the team ships a feature that requires permissions to update in real time — a role change during a live session, say — and someone discovers a five-minute window where a revoked admin can still access everything. An engineer who had lived through a stale-permissions incident would have felt something looking at that TTL. Not a rule violation. More like a weight in the chest — the residue of having been the person who found the security hole and had to explain it to compliance.
She doesn’t feel that weight. She approves the PR. Both she and the model produced the right output that day. The distance between them won’t be visible until a day the model’s judgment doesn’t cover the gap, and there is no flinch left to catch what the tool missed.
The honest case
Calculators were supposed to destroy mathematical intuition. Spell-checkers were supposed to kill the instinct for language. GPS was supposed to atrophy the sense of direction. None of that quite happened. The tools shifted where judgment formed instead of eliminating the conditions for it. Maybe AI is the same kind of shift — constraints migrating rather than vanishing.
But those tools arrived slowly. Calculators didn’t appear in every classroom simultaneously. GPS adoption took decades. Each transition left overlap: a generation that learned without the tool teaching the generation that learned with it. AI is compressing that overlap. The junior engineer hired next quarter may never work without an AI pair. She will produce competent code from the start. She will pass review. She will ship. And she may reach positions of architectural responsibility without ever having been the person who stayed up debugging a failure that no model anticipated — the failure that would have become the scar that would have become the taste that would have caught the next one.
I keep coming back to this and finding it hard to dismiss. Not because the calculator analogy is wrong — it might be roughly right — but because the speed is different in a way that might matter structurally. A decade of overlap between tool-assisted and unassisted practice is a different thing from no overlap at all. Maybe the profession adapts. Maybe new forms of consequence emerge that aren’t visible yet. But the optimistic version requires trusting a process that hasn’t started, and the pessimistic version only requires noticing what’s already happening.
There’s a sharper objection, though. Maybe what looks like convergence among experienced engineers is just conformity — shared training, shared conference talks, shared war stories calcified into instinct. The engineer who flinches at the microservice split might be flinching at a wound that no longer applies. Paradigm shifts do make old taste obsolete. The mainframe programmer’s instincts were actively harmful in the client-server era. Some scars should fade.
But even when those scars became obsolete, the practitioners who carried them had been shaped by some constraint. They had developed the capacity for taste — the ability to be marked by experience — even if the specific content needed updating. The question is not whether old taste is sometimes wrong. It is whether you can develop the capacity for taste at all without the pressure that produced it. If it cannot develop without pressure, the task is to design new forms of consequence — deliberate apprenticeship, structured exposure to the right failures — strong enough to produce judgment without demanding the same waste.
Behind the screen, the jury converged because each member had spent decades listening to thousands of performances under conditions that punished bad judgment. A principal chair shapes an orchestra’s sound for years. Their ears weren’t gifts. They were residues — of attention, of error, of consequence.
Remove those conditions. Replace them with a system that selects well every time. Within a generation, the selections are still sound. The ears are gone. Not because anyone decided to discard them, but because the thing that built them — the long, inefficient, failure-laden process of developing judgment — was quietly optimized away.
The orchestra still sounds good. What the system cannot do is notice the moment its own selections begin to narrow — when the distance between good and good enough closes, and there is no ear left in the room that can hear the difference.