One of the easiest mistakes to make in an AI-heavy moment is to confuse abundance with mastery. A team can now generate ten versions of a feature instead of one. A founder can spin up a prototype in a weekend. A product manager can produce a plausible spec without a formal writing cycle. A junior engineer can land patches that once took far longer. The system seems to remove friction everywhere.
Some of that is real; routine output really has become cheaper. But cheap output does not mean cheap judgment — except where the output is genuinely disposable. For a one-off script or a prototype nobody inherits, skip the judgment overhead. Where the work has to endure, the bill comes back.
In some ways, the opposite is happening. When code, copy, plans, tests, and glue work become easier to generate, the new bottleneck shifts toward deciding what should exist, what quality looks like, what tradeoffs are acceptable, what should be rejected, and how to tell the difference between elegant speed and expensive slop. The human contribution does not disappear. It becomes easier to see.
If Chapter 1 says the big shift is from suggestion to delegated execution, Chapter 2 says the human side of that shift is not less craft but more visible craft. Once a machine can produce more work than a human can carefully inspect by default, taste stops being a soft virtue and becomes part of the operating system.
Cheap generation raises the value of judgment
Matt Pocock captures the first principle cleanly: “software fundamentals matter now more than they actually ever have.” That can sound backward at first. Surely fundamentals matter less if a capable coding system can fill in the syntax, scaffold the endpoint, wire the form, and draft the tests.
But fundamentals here are not syntax; the machine fills that in. They are how you tell good output from merely convincing output — the leverage points a machine cannot resolve for you:
Which abstraction belongs here? Which dependency will quietly punish us six months from now? Which draft only looks polished because nobody asked whether the premise is right? Which shortcut is a useful prototype move and which one is a long-term maintenance trap? Which bug is local and which one reveals that the architecture itself is under-specified?
Those decisions were always important. What changes is their visibility. In a slower, human-only workflow, bad decisions were often partially hidden by the fact that all production was expensive. Teams naturally moved slower, touched fewer surfaces, and had more incidental review embedded in the cost of making anything. Cheap generation strips away that natural throttle. You can now produce a much larger amount of work on top of weak decisions.
This is why AI often behaves as an amplifier before it behaves as a replacement. Good operators get more leverage. Sloppy operators get more slop, faster.
The point is not that the tools are bad. The point is that they magnify what is already there. If the team has strong standards, explicit constraints, and people who can discriminate well, the new speed is extraordinary. If the team lacks those things, the same speed just means they can industrialize confusion.
Taste is not aesthetic preference; it is quality discrimination under abundance
Taste is the ability to notice the difference between output that merely works and output that fits. What that ability comes down to, in practice, is a recognizable set of tells: a patch that is technically correct but shaped wrong for the system around it, a component boundary that is too clever, a naming choice that will confuse the next person, a generated paragraph that says the obvious thing in the most generic way possible, a workflow with one hidden step too many, a prototype convenience about to become permanent structure. None of these trip a test. Each is the moment where merely working and actually fitting come apart, and recognizing them on sight is what taste actually buys you.
Tuomas Artman, reflecting with Gergely Orosz on craft at Linear, raises the right unsettling question: “What happens when agents are capable of doing everything immediately for you?”
The obvious answer is speed. Artman's is sharper: when a small AI-equipped team can match your feature set, he sees tasteful, high-quality software as a way to keep some competitive advantage. Speed changes what human excellence consists of.
If the machine can produce immediately, the scarce skill is less often the manual act of producing and more often the act of selecting, directing, constraining, sequencing, and refusing. Taste becomes the discipline of quality discrimination under abundance.
AI does not simply remove toil and leave the rest of engineering unchanged. In many cases it removes one kind of toil by placing heavier demands on another kind of work. Someone still has to know what “good” means. Someone still has to tell the difference between a local success and a systemic mistake. Someone still has to notice when the generated work optimizes for velocity in a way that quietly damages legibility, maintainability, or trust.
This is also why taste is inseparable from architecture. The strongest engineers are not just better at cleaning up generated output. They are better at shaping the conditions under which good output is likely to be produced in the first place.
There is a second reason to read generated code closely. When you wrote every line, comprehension came free with authorship. A model breaks that bundle: it hands you working code you did not build and therefore do not yet understand, and that understanding now has to be paid for separately, after the fact. Reading the diff stops being a courtesy and becomes the load-bearing step — reading it like an author, reconstructing why each choice was made rather than confirming the lines parse, tracing one path the tests do not cover to ask whether the design would survive it.
The friction is your judgment
Armin Ronacher and Cristina Poncela Cubeiro make the sharpest counterargument to frictionless shipping. Their talk, titled The Friction Is Your Judgment, argues for adding some friction back — not because speed is bad, but because some friction is judgment in disguise.
A lot of traditional software friction is waste. Slow builds, unclear ownership, handoffs nobody needs, cumbersome tooling, meetings that exist only because the system is poorly designed — none of that deserves romantic defense. AI can remove a lot of this, and good riddance.
But not all friction is waste. Some of it is exactly where quality gets made instead of lost:
The pause before merge. The question about whether this belongs in the system at all. The extra review pass on a security-sensitive path. The insistence on naming something precisely. The decision to rewrite a generated function because it violates the grain of the codebase, even if it passes today.
Those moments are easy to misclassify as inefficiency, especially when generation tools make everything else feel instant. Ronacher's is not nostalgia for slowness: the pause is where the judgment is, the point where experience gets inserted.
This is one of the deeper cultural adjustments AI engineering demands. Teams have to learn to separate needless friction from meaningful resistance. If they remove both at once, they often do not end up with a higher-performing system. They end up with a faster path to lower standards.
There is a test for which is which. Cut the pause if removing it only costs keystrokes — boilerplate, glue, scaffolding the model can regenerate on demand. Keep the pause if removing it costs a decision: whether the architecture can carry this, whether the draft is right or merely plausible, whether the frame is correct before the model executes it. The first kind of friction is waste; the second is where the judgment lives, and the cost of skipping it now scales with how fast the model executes the wrong frame.
The key phrase here is not “slow down.” It is “know what your pauses are for.”
Vibe coding is a mode, not a production philosophy
The phrase is useful partly because it is a little embarrassing. It names a behavior people recognize on sight: low-spec, high-speed, intuition-led building steered by momentum rather than explicit structure.
That mode is not worthless; it can be brilliant. For exploration, interface sketching, rough prototypes, internal tooling, one-off automation, toy apps, or situations where learning by doing is more valuable than formal design, can be the correct move. It can widen the top of the funnel. It can make experimentation cheap enough that more people discover what is actually worth building. It can give individuals a level of expressive power that used to require a small team.
The problem begins when a useful exploratory mode quietly hardens into a default production philosophy. Corey Gallon at Rexmore calls this the vibe-coding hangover: the app works on Friday, and “then Monday rolls around, you want to add a feature, and you realize that you don't understand it, you can't maintain it, and you have to throw most or all of it away.”
is not the enemy. Unexamined is.
A strong manuscript should avoid the lazy reaction of treating all AI-native building as unserious. That would miss the real shift. But it should also avoid the equal and opposite mistake of treating momentum as a substitute for engineering. Chris Kelly at Augment Code is blunt about it. AI code is still code, and vibes do not cut it in production — where production means four-nines uptime, thousands of users, and gigabytes of data, the moment a mistake is paid by people who never saw the prompt. It still has to live somewhere. It still interacts with systems, constraints, users, security boundaries, and future maintainers. The machine does not repeal software reality.
So the right stance is not anti-vibe but mode-aware, and being mode-aware comes down to one switch: use where the cost of being wrong is low and the goal is discovery, and leave it behind the moment the output has to endure. The tell is the Monday that Gallon described — the app still works, but now it has to change, and no one understands it well enough to change it safely. If that Monday is coming, the exploratory mode has already outlived its usefulness.
The new scarce skill is problem framing
For work that has to be trusted, stronger generation tools do not repair weak framing; they expose it faster, and at higher cost.
If a human engineer receives a vague task, progress may be slow enough that the ambiguity surfaces early. Questions emerge. A meeting happens. The task gets reshaped before much damage is done.
A machine can take a badly framed prompt and sprint in the wrong direction with alarming competence. This makes problem framing more valuable, not less. Sean Grove at OpenAI puts the point directly: the new scarce skill is “writing specifications that fully capture the intent.”
Framing a task well comes down to answering a specific set of questions before the work is delegated — a gate it has to clear, not a courtesy.
What exactly is the task? What counts as success? What constraints matter? What should the system optimize for: speed, clarity, correctness, extensibility, reversibility? What is allowed to remain rough, and what must be production-grade now? What would make this output unacceptable even if it looks superficially complete?
These questions used to be signs of seniority. For work that has to be trusted they are now the gate: with them unanswered you do not have a task, you have a prompt.
Once we say the future is delegated work, the immediate human consequence is that directing work becomes a first-class technical skill. The manager, staff engineer, founder, designer, or individual developer who can frame a problem well suddenly gains disproportionate leverage because the system can execute rapidly against that frame.
The inverse is also true. A badly framed task can now waste far more time than before because the generator will happily produce large amounts of plausible but misaligned output. In a high-output environment, the quality of the question increasingly shapes the quality of the answer.
Review becomes more important because generation outruns intuition
A subtle danger of AI-assisted work is that it can generate artifacts faster than human intuition can responsibly validate them. This matters in code, but also in strategy docs, product copy, research notes, customer communication, and operational plans. Humans are easily seduced by fluency and completion. A thing that looks finished exerts psychological pressure to be accepted. A thing that arrived quickly can feel like found value. The system does not merely save time; it changes the emotional texture of review.
That is why review shifts from a step teams pass to where quality is decided:
Not review as bureaucratic blockage. Review as quality discrimination. Review as the moment the team asks whether the artifact is fit for purpose. Review as the place where tacit standards become visible.
Chris Kelly at Augment Code puts it bluntly: “code review is by far the most important skill” — and one the industry under-trained, because it interviewed for solving leetcode puzzles rather than for reading someone else’s code and judging why it is good or bad. It is the skill agents now demand at volume, because every line they write is a line you did not, and therefore have to evaluate cold.
This is where swyx’s “war on slop” is useful. Slop is not just bad code or generic writing. It is output that consumes trust faster than it creates value. It is work that looks done but transfers the cost downstream. It burdens the next person with confusion, cleanup, or false confidence. In a world of cheap generation, slop is not a side effect. It is the default failure mode.
Anti-slop discipline is not elitism. It is economic realism.
Cheap output that requires expensive cleanup is not actually cheap. Fast drafts that hide slow confusion are not actually fast. A system that creates reviewer fatigue is not scaling intelligence; it is scaling cognitive debt.
The human reviewer is therefore not an obstacle to AI productivity; the reviewer is how standards survive abundance. A rule of thumb, mine: when generation outruns review, the loop is not fast, it is unreviewed.
Constraints are a form of care
One of the recurring mistakes people make with powerful models is to imagine that creativity and constraints oppose each other. In reality, constraints are often what allow useful creativity to emerge.
Itamar Friedman at Qodo frames the problem through confidence — “ with confidence,” he calls it — asking how teams can move fast while staying grounded in the codebase and its standards. The confidence does not come from the vibes; it comes from the verification wrapped around them, high-quality tests and a reviewing pass on the generated diff before it merges. The answer is not to remove constraints but to make the right ones explicit.
Constraints do several jobs at once: they reduce wasted search, make evaluation clearer, preserve local quality norms, let work be delegated without the delegator hovering over every step, and turn taste from a private opinion into something operational.
This is true for codebase rules, product principles, review checklists, domain boundaries, writing standards, and architectural decisions. The team that can state its constraints well can more safely than the team that relies on vibe, memory, and implied context.
Once judgment becomes more valuable, the question is where to keep it. Taste kept only in a senior engineer's head is easy to lose in delegation; taste written into a , a spec, or a repo rule is harder to lose.
The software factory still needs adults in the room
The recurring software-factory case makes this concrete. A team begins with exciting outputs from coding agents. The first lesson is that the repo needs more structure. The second lesson is that even a better does not eliminate the need for human standards. Someone still has to decide what the should teach. Someone still has to define acceptable tradeoffs, review boundaries, and quality bars. Someone still has to distinguish changes that merely compile from changes that improve the system.
The same is true in the High-Stakes Colleague case. A legal or tax workflow can be given better retrieval, better tools, validation passes, and trajectory review. But none of those layers removes the need for domain judgment. They are ways of making judgment scalable and inspectable.
AI does not make seniority irrelevant; in many contexts it makes seniority more leveraged and more legible. The senior engineer, strong editor, careful researcher, or domain expert is no longer valuable mainly because they can personally grind through more output. They are valuable because they can define standards, frame problems, reject seductive nonsense, and shape systems so that more of the generated work lands inside the right quality envelope.
The human job is shifting from production to direction
It would be too simple to say that humans now only direct while machines produce. People still produce a lot, and manual work is sometimes the fastest or safest path. But the direction is real. A larger share of human value moves toward:
- framing tasks well
- defining constraints
- choosing abstractions
- sequencing work
- reviewing outputs
- preserving coherence across many generated artifacts
- deciding when to trust the system and when to narrow its scope
The better the generators get, the more dangerous it becomes to confuse typing with thinking. What stays scarce is not producing tokens. It is directing production toward something coherent, durable, and worth keeping.
Closing move
When code gets cheaper, many people instinctively ask what happens to programmers.
A better question is what happens to standards.
If the cost of generation collapses while the cost of bad judgment remains stubbornly high, then the defining skill of the next era is not mere production. It is the ability to know what should be produced, under what constraints, to what quality bar, with what review discipline, and with what willingness to throw seductive garbage away.
That is what taste means here. Not luxury. Not style. Not personal branding.
Judgment under abundance.
And once that becomes the scarce resource, the next technical question follows naturally: how do you build environments where that judgment can survive delegation?
Practical checklist
Put this chapter's argument to work on whatever you're delegating this week:
- Run the framing gate first. Before handing anything to a model, answer what the actual task is, what counts as success, which constraints are real, what's allowed to stay rough, and what would make the result unacceptable even if it looks finished. Can't answer that last one? Not ready to .
- Read every diff like its author, not its skimmer. Reconstruct why each choice was made; trace one path the tests don't cover and ask whether the design survives it.
- Sort your friction before you cut it. Remove a pause if it only costs keystrokes. Keep it if removing it costs a decision — whether the architecture holds, whether the draft is right or merely plausible.
- Know which mode you're in. is fine where being wrong is cheap and the goal is discovery. The moment an artifact has to be maintained by someone who didn't prompt it into being, switch modes — don't wait for the Monday that proves you should have.
- Write your constraints down. A team that states its standards explicitly can safely. A team that relies on vibe and shared memory can't, no matter how good the model gets.