Somewhere in a company right now, ninety people are building the same feature.
Not literally coordinated — that’s the point. Someone in marketing described what they wanted to a model and got a working version back by lunch. Two engineers each spun up their own take. A designer built a clickable one to argue for a direction. A PM made a rough one just to feel the flow. None of them asked permission, because none of them needed to: the thing that used to gate all of this — will building this be worth the engineering time — barely costs anything now. So instead of one carefully-scoped build, you get abundance. Ninety uncoordinated explorations of the same idea, most of them half-finished, several of them secretly good.
And now the actual hard question arrives, and it’s a new one: which of these is right, what do you fold together, how do you frame it, and how many of them should quietly die?
That question — not the building — is where the work went. This guide is about what that does to taste, to prototypes and documents, to how teams organize, to how you plan when the ground keeps moving, and to the increasingly strange idea that any of us has a fixed job title.
The inversion: implementation got cheap, curation didn’t
For as long as software has been a job, implementation was the expensive part, and almost everything we call “process” was built to protect it. Research, requirements documents, design reviews, prototypes, sign-offs — all of it existed to de-risk the build before you committed scarce engineering time to it. You planned carefully because building was the thing you couldn’t afford to get wrong.
Flip the cost of building to near-zero and that entire logic inverts. When standing up a working version of an idea is something anyone can do by describing it, building stops being the bottleneck. What becomes scarce is everything that used to be cheap by comparison: deciding which version is good, noticing what’s missing, understanding how a piece fits the whole, knowing what to cut. The constraint moved from production to curation — and curation turns out to be much harder to hand off to a machine than production was.
This is the same underlying economics we trace on the engineering side in writing got cheap, understanding didn’t: agents generate code faster than any human can read it, so the bottleneck slides downstream to the one step that didn’t get faster — a person being confident the result is right. This guide is the product-and-design half of that same story. There, the scarce skill is verification. Here, it’s taste. They’re two faces of one shift: when making things is free, judging things is the job.
What “taste” actually means
“Taste” is a slippery word, and it’s worth being precise, because the lazy version — taste means good aesthetics — is exactly wrong enough to lead you astray. Plenty of people with impeccable taste in product decisions dress like they got dressed in the dark. Taste as it matters now is not a single sense; it’s at least three, working together.
An aesthetic component. Does this look and feel right — the spacing, the motion, the restraint? This is the part people mean when they use the word casually, and it’s real, but it’s the smallest part.
A systems component. How does this one thing fit the wider product, and where is that product going? A feature that’s locally beautiful and globally wrong is a failure of taste, not a success of design. This is the part that lets someone look at one of the ninety explorations and say “this is the good one, but it belongs over here, and it needs to talk to that.”
A judgment component. Does the tone of an interaction match what it actually means? A destructive action that animates in playfully, a trivial confirmation dressed up like a serious warning, a celebratory flourish on something that isn’t an achievement — these are mismatches between an interaction’s feel and its meaning, and catching them is judgment, not decoration.
The thread tying all three together is this: taste is knowing what to work on, how to frame it, and which medium to use to communicate it. Notice that none of those are about the act of building. That’s why the skill generalizes so far beyond design — it’s becoming the scarce skill in every field where the cost of producing a first draft of anything collapsed.
Pick the medium for the message, not for your comfort
A fashionable claim right now is “PRDs are dead, prototypes are in” — why write a requirements document nobody reads when you can just build the thing and show it? It sounds right, and it’s mostly a mistake, because it confuses the medium with the goal.
Documents and prototypes are not competitors on a timeline where one replaces the other. They’re different tools for different jobs:
- A document is right when the goal is conceptual clarity on a vague or contested problem. When the hard part is what are we even trying to do and why, prose forces the thinking that a slick prototype lets you skip. You cannot hand-wave your way through a paragraph the way you can through a demo.
- A prototype is right when the goal is stress-testing an interaction. When the question is how does this actually feel to use, where does the flow snag — no amount of writing substitutes for touching the thing.
The real failure mode isn’t choosing the wrong one on principle. It’s choosing the one that’s easiest for you. Non-engineers reach for prototypes because they can finally build without waiting on anyone. Engineers write documents because writing is where they’re comfortable and building the “wrong” thing feels wasteful. In both cases the person picked the medium that suited them, not the point they were trying to make. Taste, again: knowing which medium fits the message is part of the skill, and defaulting to your comfort zone is exactly the tell that you’re not exercising it.
A polished prototype no longer means “ready to ship”
Here’s a subtler consequence, and it’s the one that quietly burns teams.
For decades, how finished something looked was a reliable signal of how far along it was. A rough sketch meant early. A pixel-perfect, fully-wired, production-styled build meant late — it meant someone had already done the research, made the trade-offs, and de-risked the thing, because nobody would sink that much implementation effort into an idea that hadn’t earned it. Polish correlated with process stage, and everyone read the signal without thinking about it.
That correlation is now broken. When implementation is cheap, a fully-polished-looking prototype can be a first-day thought experiment. The visual finish tells you nothing about whether the idea underneath it is validated, load-bearing, or even seriously intended. And so teams make a very natural, very expensive mistake: they see something that looks done and treat it as decided. An early exploration gets mistaken for a ship-ready feature purely because it renders nicely — and half-explored ideas slip into production wearing the costume of finished ones.
The defense is to hold onto stage-awareness even as the tools that used to signal stage disappear. You have to say out loud what a given artifact is — “this is a throwaway to feel out the interaction,” “this is a real candidate we’ve pressure-tested” — because the artifact itself no longer tells you. One concrete tactic teams use: a “baby” version of the real product — a deliberately simplified, fast-to-modify clone of the codebase whose only job is to explore interaction ideas cheaply, with no pretense that anything built in it is production. Naming the sandbox as a sandbox keeps the polish-equals-done confusion from ever starting.
Why AI is still worse at taste than at code
If models can now write most of the code, why can’t they just curate too — pick the good version, catch the tone mismatch, resist the generic? They’re getting better, but there are structural reasons taste lags well behind code, and understanding them tells you where the human stays valuable.
Design is much harder to grade than code. Code has a brutal, immediate feedback signal: it compiles or it doesn’t, the tests pass or they don’t. That gradeability is exactly what made code such fertile ground for training capable models. Design has no equivalent. “Is this good” routes through human taste — the very thing that’s scarce — so there’s no cheap, automatic reward signal to train against. You can’t gradient-descend your way to taste when the loss function is a shrug.
The tooling that got built first was the tooling that helped build more tooling. For years the capabilities that got prioritized were the ones that accelerated the work itself — better code generation makes everything downstream faster, so it got the attention. Good design doesn’t feed that same flywheel, so it waited.
Models trained to find the common pattern converge on the average — and taste is resisting the average. A model learns what’s typical by absorbing what’s overrepresented, and what’s overrepresented in design is a specific flavor of clean, safe, modern “best-practice” look. Ask for a design and you tend to get the statistical center of gravity of everything that came before: competent, generic, and indistinguishable from a thousand other products. But real design taste is often precisely the refusal to regress to the mean — the culturally specific, novel choice that a pattern-matcher is built to smooth away. The thing that makes the model reliable at code makes it bland at design.
The deepest gap is semantic abstraction. The unsolved layer is understanding the relationship between things that look different but are the same kind of thing. A rebrand isn’t “edit 263 components.” It’s knowing which of those components share an underlying interaction pattern or structural role, so that a change to the concept propagates correctly rather than being applied 263 times by hand. Humans hold this map intuitively — “these two screens are the same kind of moment” — and models still struggle to. Until that layer is cracked, a person holds the map of what-relates-to-what, and that map is a large part of taste.
Zone defense: how product teams are reorganizing
When curation is the scarce skill, the old way of organizing product people — a top-down roadmap that assigns each person a lane for the year — starts to fit badly. The teams furthest into this shift are reaching for a different model, borrowed from sports: zone defense.
The idea is simple. Instead of assigning people to features, you spread them across the space of the product and let them cover it. Each person acts as a taste-maker for their zone — shepherding ideas from inception, noticing gaps, filling them — rather than executing a pre-planned ticket. And the diagnostic signal is inverted from what you’d expect: if two product people are working too closely on the same area, that’s a bad sign, not good collaboration. It means a zone is over-covered while another sits exposed. You want spread, not clustering.
This reshapes who’s valuable. The most prized profile isn’t the deepest specialist in any one tool — it’s the high-agency, high-taste person who can take an idea from concept all the way to shipped, filling in whatever the idea needs along the way. (It’s no accident that former founders thrive here; running your own thing is a crash course in exactly that end-to-end ownership.) Narrow tool mastery ages badly on purpose: being the best in the building at some specific tool’s advanced features is a strange thing to optimize for when the model will soon be better at that tool than you. Agency and judgment don’t have that problem.
It also dissolves fixed titles — but carefully. On these teams, a person’s role is better described as the average of what they actually spend their time on than as a label on an org chart. If most of your week is product management, you’re a PM for now; that can shift. Designers write code, PMs are technical, and the boundaries blur.
But — and this matters — blurring is not erasing. The move some companies make, collapsing everyone into a single “builder” role and declaring specialties obsolete, is a real mistake. Each discipline carries hard-won best practices, and those quietly get thrown out the moment “I built something that works” becomes the only bar anyone’s held to. Using a tool doesn’t make you a domain expert. Writing code no more makes you an engineer than using a spreadsheet makes you a finance person. Expect the fluidity to keep increasing; don’t mistake it for the disappearance of expertise. This is the same tension we work through for engineering orgs specifically in engineering team structure in the AI era — smaller, more fluid, but with humans deliberately kept at the gates that matter.
Planning when the ground keeps moving
How do you plan a roadmap when the capability of the underlying model — the thing half your features depend on — is changing every few months? You still plan. But you plan differently, and the core rule is: detail should be inversely proportional to time horizon.
Near-term plans can be detailed, because you can see the ground. Nine-month plans should stay deliberately hazy, because false precision that far out is just wasted effort dressed up as rigor — you’ll re-derive it all when the situation changes anyway, which it will. Committing to specifics you can’t yet know is a way of feeling organized while producing nothing durable.
The deeper lesson is one most teams learn painfully: many features aren’t blocked by any product decision. They’re blocked by whether the model is smart enough yet. The product shape is fine; the idea is right; it simply doesn’t work reliably because the underlying capability isn’t there. And that changes what good planning looks like. The practical approach is:
- Prototype many candidate features — cheaply, because building is cheap now.
- Ship what’s ready today.
- Let the rest “sit and bake” — don’t kill them, don’t force them, just park them.
- Re-test the parked ones every time the model takes a capability leap.
Because a feature’s success can depend entirely on model timing rather than its design. The clearest version of this: a product that shipped and succeeded in one quarter would have flat-out failed a few months earlier — same design, same shape, same everything — purely because the model underneath couldn’t do the task yet. Nothing about the product was different. The only variable that moved was the capability floor beneath it.
Don’t kill a concept because the first version flopped
This deserves its own beat, because it runs against a deep instinct. When you ship something and it fails, the natural conclusion is that was a bad idea. Under fast-moving models, that conclusion is often wrong.
Think about the “agent that goes off, does a task on its own, and comes back” concept. It’s been attempted in many forms — some flopped, some landed — and the ones that worked didn’t win because they were designed better. They won because they matched what the model could actually do at that moment. The early, maximally-autonomous versions failed not because autonomy is a bad idea but because they were, to put it one way, too optimistic for the moment — they assumed a level of capability that wasn’t there yet. The versions that worked were more grounded: ask permission, stay with the user, do what the model was reliably good at right then.
The lesson: the shape of a feature and its readiness are different things, and you have to judge them separately. A concept can be right and simply early. Don’t retire the shape after one failed release — re-release it, unchanged, each time the capability catches up. The discipline is refusing to let a timing failure masquerade as a design failure. (This is also why “get married to the outcomes you’re uniquely able to deliver, and stay willing to change everything about your process to get there” is better advice than committing to any specific plan — outcomes are stable, methods are disposable.)
Supervised vs unsupervised is the real question
There’s a metric people love to quote — what percentage of our code is written by AI? — and it has quietly stopped meaning anything. The honest answer almost everywhere is approaching one hundred percent, so the number no longer distinguishes anyone from anyone.
The question that actually carries information is different: of the AI-written work, how much was supervised and how much was unsupervised? That’s the axis that separates a team shipping trustworthy software from a team accumulating a pile of code nobody has judged. It’s the product-side echo of the human-on-the-loop idea from writing got cheap, understanding didn’t: the point was never to write the code yourself, it’s to be deliberate about where a human’s judgment enters.
And this is why the “improve the product overnight, unattended” dream isn’t here yet. Fully autonomous loops still tend to increase complexity over time — models pile on rather than simplify — and they don’t yet reliably make the judgment calls that matter: which feature requests are worth doing, which to ignore, and what the right abstraction is. Those are taste decisions, and taste is exactly the thing that hasn’t transferred. So the frontier right now isn’t “remove the human.” It’s “put the human’s supervision in the highest-leverage place and let the machine do the rest.” The percentage of code that’s AI-written is settled. Whether a person was watching is the whole game.
One adaptable home base, not ten reimplementations
There’s a strategic pattern worth naming, because it keeps proving out and it’s counterintuitive.
The obvious way to serve different audiences is to build different products for them — a developer tool for developers, a friendlier version for everyone else. But teams keep discovering that when they build a “simpler” version for non-technical users, those users often prefer the powerful tool anyway — even when its interface is, frankly, hostile to them, showing raw internals and asking permission at every step. The complexity wasn’t the problem. The lack of a ceiling was the point. People would rather grow into one capable tool than be handed a padded-down one they’ll outgrow.
The pattern that works is one adaptable core that scales its complexity to the user — different presentational modes over the same engine, not different products — and that acts as a home base: the place work starts, ends, and gets automated, which then connects out to specialized tools rather than trying to reimplement them. It doesn’t rebuild the spreadsheet or the video editor; it reaches into them, drives them, hands work off, and pulls results back. The most striking version of this is when the tool, hitting the edge of what a connection allows, builds its own extension to talk to another running application directly — going further than it was asked to, because the goal was the outcome, not the specific pre-planned path. That’s the home-base instinct in miniature: own the outcome, connect to everything, reimplement nothing.
What to actually do
If you take one thing from all of this, take the reframe: the scarce skill moved from making to choosing. Here’s how that cashes out.
- Treat curation as the job, not the afterthought. When you can generate ninety versions of anything, the value you add is deciding which one is right, what to combine, and what to cut. Budget your time accordingly — less making, more judging.
- Choose your medium by the point you’re making, never by what’s easiest for you. Document to get conceptual clarity; prototype to stress-test an interaction. Notice when you’re reaching for your comfort zone.
- Say out loud what stage an artifact is at, because its polish no longer tells you. Keep a named sandbox for cheap exploration so nobody mistakes a thought experiment for a decision.
- Organize by zone, not by lane. Spread taste-makers across the product space; treat two people crowding one area as a warning, not teamwork.
- Plan with detail that fades with distance. Prototype widely, ship what’s ready, park the rest, and re-test the parked ideas on every capability leap.
- Judge shape and readiness separately. Don’t kill a concept because version one flopped — it may just be early.
- Ask “was it supervised,” not “was it AI-written.” The second question is settled everywhere. The first is where trust lives.
- Protect expertise while you blur roles. Fluidity is good; declaring every discipline obsolete because anyone can build is how you throw away the best practices you’ll wish you’d kept.
None of this is a story about humans becoming less necessary. It’s the opposite. When making things stops being the constraint, the distinctly human skills — knowing what’s worth building, telling the good version from the merely finished one, holding the map of how it all fits — become the entire game. Building got cheap. Taste didn’t. The teams that win the next few years won’t be the ones that generate the most; they’ll be the ones that curate the best.