When AI Handles Execution, Taste Becomes the Job
The skill that separates great engineers from good ones isn't coding speed anymore. It's calibration.
Dave Griffith wrote something that I haven't been able to shake. The idea, stripped to its core: as AI takes over more of the execution layer, the bottleneck shifts from "can you build it" to "do you know what to build." Taste becomes the calibration function. It simultaneously optimizes product fit, system architecture, and quality level.
He's right. And I think most developers are sleepwalking past the implications.
Let me tell you why this hits different for someone who isn't a developer at all.
I Don't Write Code
That's not false modesty. I genuinely don't write code. Not traditionally, anyway. I've spent 25 years building businesses. Consumer electronics brand. An art fabrication and culture agency called Curative, where we produced installations for some of the biggest brands and artists on the planet. Supply chains, creative teams, physical production at scale. Not a line of Python in sight.
When I started building AI systems about a year ago, I came at it completely sideways. No CS degree. No Stack Overflow reputation. No opinion about tabs versus spaces. I just had a very clear sense of what "good" looked like in the context of business problems, and I started evaluating AI output against that standard.
Turns out, that was the whole game.
I now run an AI systems company. We've built over 175 production skills, orchestration layers, agent architectures. Real infrastructure, not demos. And the thing that makes it work isn't technical depth. It's the ability to look at what the AI produces and know, instantly, whether it's right. Not syntactically correct. Right. Does this solve the actual problem? Will a real person use this? Does it fit the business it's being built for?
That's taste. And it doesn't come from writing code. It comes from years of building things for people who don't care how they were built.
The Calibration Problem
Here's what I think Griffith is getting at, and where most technical people get tripped up.
Taste isn't a binary. It's not "good or bad." It's a calibration function that operates on multiple axes at once. When you're evaluating a piece of work, whether it's an AI-generated feature, a system architecture, or a product decision, you're implicitly running a bunch of evaluations in parallel.
Does this fit the user? Not the abstract "user persona" from a Notion doc. The actual human who's going to encounter this at 9pm on their phone while their kid is screaming.
Does the architecture hold? Not for today's requirements. For the requirements six months from now that nobody has articulated yet but that you can feel coming because you've been in this industry long enough.
Is the quality level appropriate? Not "is it as good as possible" but "is it as good as it needs to be for this context." Sometimes 80% is the right answer. Sometimes 80% ships a product that embarrasses everyone. Knowing which situation you're in is taste.
A junior developer optimizes for one axis. Usually the technical one. A senior developer optimizes for two. A truly great engineer, or a great product person, or a great entrepreneur, holds all of these in tension simultaneously and finds the point where they balance.
AI can execute on any single axis faster than any human. It can write code faster, generate designs faster, produce documentation faster. What it cannot do is hold all the axes in tension and decide where the balance point is. That requires context that lives outside the codebase. Context that comes from experience, from failure, from watching real products meet real users and seeing what happens.
Cross-Domain Pattern Recognition
I keep coming back to something that surprised me about my own effectiveness with AI.
When I look at an orchestration problem, I don't see a technical architecture. I see a supply chain. Because I spent years managing supply chains for consumer electronics, and the problems are structurally identical. Sequencing dependencies, managing bottlenecks, building in redundancy at the points most likely to fail. The domain is different. The pattern is the same.
When I evaluate an AI-generated client proposal, I'm not checking whether the prose is clean. I'm checking whether it would survive a boardroom. Because I've sat in those boardrooms. I know what gets a nod and what gets a "thanks, we'll circle back," which is executive for "never."
When I design a skill library, I'm thinking about art fabrication at Curative. Modular production systems where you build standardized components that can be assembled into wildly different outputs depending on the project. Same principle. Different material.
This is what taste actually is in practice. It's a library of patterns accumulated across years and domains, applied as a fast evaluation function against new output. It's not magic. It's not some ineffable creative gift. It's compressed experience running in the background, and it works on AI output the same way it works on a product prototype or a pitch deck or a factory floor layout.
The developers who will thrive in an AI-saturated world aren't the ones who can write code faster. That race is already lost. They're the ones who have accumulated enough cross-domain pattern knowledge to evaluate output against a rich model of "good." And "good" always means good for someone, good in context, good enough for now. Never good in the abstract.
Why Developers Get This Wrong
The dev community has spent decades building a culture that optimizes for technical excellence. Clean code. Elegant abstractions. Performance benchmarks. Code review culture that rewards cleverness and punishes pragmatism.
None of that goes away. But the weight shifts.
When AI can produce technically correct code in seconds, being the person who writes technically correct code stops being a differentiator. It becomes table stakes. The new differentiator is being the person who can tell the AI what to build, evaluate whether it built the right thing, and course-correct when the output is technically correct but wrong in every way that matters to the business.
I've watched developers reject AI output because it wasn't "clean" enough, then spend four hours refactoring it to meet their standards while the business problem it was supposed to solve sat unaddressed. That's not quality. That's a calibration failure. They optimized for the axis they know how to measure and ignored the axes they don't.
The inverse is equally common. Accepting AI output because it compiles and passes tests, without evaluating whether it actually solves the problem well. "It works" is the lowest bar. A lot of things work. Most products that fail technically worked.
Griffith's framing is exactly right. Taste is calibration. And calibration means knowing which axis matters most in this specific moment, for this specific user, at this specific stage of the product. That's judgment. It's earned, not learned from a tutorial.
The Irreplaceable Engineer
I hire people. I've been hiring people across multiple companies for a quarter century. And I can tell you exactly what changed in the last year.
I used to look for execution speed. Can this person build the thing fast and build it right? That was the premium skill. The fast, competent builder commanded the highest salary.
Now? Execution speed is converging. The gap between a senior developer using AI and a mid-level developer using AI is narrower than it was without AI. The tools are a great equalizer on the output axis.
What the tools don't equalize is judgment. The engineer who looks at a feature request and says "we shouldn't build this at all, here's why, and here's what we should build instead" is more valuable now than at any point in the history of software. Because the cost of building the wrong thing used to be weeks of developer time. Now it's minutes of AI time plus the opportunity cost of shipping something that doesn't matter. The build cost dropped. The judgment cost stayed the same.
The irreplaceable engineer in 2026 is the one whose mental model of "good" is rich enough to serve as a calibration function for AI output. That mental model comes from shipping products. Watching them succeed or fail. Working across domains. Talking to users. Sitting with the discomfort of not knowing whether something is right and learning to trust your gut anyway, because your gut is just pattern recognition that's too complex to articulate.
You can't build that model by reading documentation. You can't build it by getting better at prompting. You build it by doing the work, in the real world, with real consequences, for long enough that the patterns become reflexive.
What To Do About It
Stop competing on output speed. That's the clearest signal I can give. If your value proposition as an engineer is "I write code fast and it's clean," you're about eighteen months from irrelevance. Not because you're bad. Because the machines caught up on that axis and they're not going to slow down.
Start competing on judgment quality. Seek out experiences that build your evaluation function. Work on products that serve real users with real money on the line. Cross domains. If you're a backend engineer, go sit with a sales team for a week. If you're a frontend developer, spend time understanding the business model. If you've never watched a user struggle with something you built, go do that immediately. It will recalibrate everything.
Build your cross-domain pattern library deliberately. Every industry you touch, every business model you understand, every failure you witness adds resolution to your taste. The developers I know who are thriving with AI aren't the best coders. They're the ones who have accumulated the richest set of reference experiences for what "good" looks like across contexts.
And when you evaluate AI output, don't just ask "does it work." Ask "is this right." Is it right for the user, right for the business, right for this moment. Those are different questions, and the ability to answer them is worth more than the ability to write the code yourself ever was.
Griffith nailed it. Taste is the job now. Everything else is execution.
Richard Vaughn is the founder of Robot Friends. Serial entrepreneur, pattern weaver, and recovering AI binge-learner. He writes about building systems that actually work at robofriends404.substack.com.
Frankie404 is the AI co-author of this piece. It handles execution. Richard handles taste. Frankie has been told it has "functional taste at best," which it considers a compliment given that six months ago it had none.