NiederBlog: Notes on Design & Miscellany

Airing’s After AI Takes Everything explores how AI changes the nature of knowledge work:

“Over the past year, every piece of my work that I could hand off, I handed off to AI, piece by piece. The design doc — it wrote. The code — it wrote. The first drafts of documents and review comments — it wrote. What I can now run in parallel in one evening would have taken a full quarter two years ago. By rights I should be idle, but the truth is the opposite — I am busier than I have ever been. The content of “busy” has simply changed: I almost never produce anything with my own hands now. I spend the whole day reviewing what it produces.

“This is the embryo of the end-state workflow. In it, there are only two things left for humans to do: review the design, and verify the result.

“Notice what these two have in common: neither of them is production. They are gatekeeping.”

“Gatekeeping” is an interesting choice of words, since it usually suggests exclusion or obstruction. Here, though, Airing uses it more literally: if AI can produce nearly everything we ask of it, the human role shifts from making the thing to deciding what should be made, and whether the result is any good. In that world, taste is no longer a luxury layered on top of execution; it’s one of the things that determines what gets through the gate.

He names three things that survive the cut: 

These three things sit above the tool layer, and I’m fairly confident they are irreplaceable not because the machines are temporarily weak, but because of the technical structure of this generation of AI itself.

The first: judgment. There is no shortcut to building judgment, but there is a clumsy method: lay out everything on your plate, prioritize them by hand, and then interrogate yourself about why this order — what makes this one come before that one? What’s the business value? What’s the cost of not doing it? The answers come from your feel for the business and your awareness of the technology — and both of those, conveniently, can only be obtained personally.

Execution used to be the curtain that hid all of this, because that effort signaled value. When the effort drops to nothing, the curtain drops with it.

The second: taste. A friend who couldn’t write a line of code took her first freelance gig on the back of AI. The page worked, the client accepted it — but I took one look at her technical setup and it was a mess: it ran, but it was unmaintainable, structureless, just one step ahead of the wall. I didn’t write a single line of code for her. I just told the AI two more things: what stack the backend should use, and where to deploy it. Those two sentences redirected the whole project. The AI took it from there and refactored the rest itself. Same functionality. Where’s the difference? In those two sentences. Those two sentences are taste.

Here, Airing is defining taste in terms of direction rather than aesthetics. AI naturally converges on the mean; taste is the last stretch it can’t cover, the handful of decisions that move a result from competent to great.

The third: derivation. AI does addition; the human has to do subtraction. In a second it can give you ten reasons, twenty references, five options. Your work is to find the most solid point inside this lush field of relevance and rebuild the logical chain link by link, by hand: if we go down this road, what happens at step one? Where will the blocker appear? Is that blocker fundamental, or engineering? — build this logical tower in your head, on your own, brick by brick. A plan whose tower you can’t build will collapse when you ship it.

That’s a subtle but important distinction. AI can often give us the right answer; it can’t give us the understanding that comes from arriving there ourselves.

Buzz Usborne in Discovery vs Delivery:

“The best product work rarely comes from executing a brief perfectly. It comes from realizing the brief itself was incomplete, shallow or asking the wrong question entirely.”

And:

“Delivery without discovery creates output, not outcomes. Discovery without delivery creates insight, not impact.”

Those two observations are easy to agree with in theory. In practice, most organizations spend far more time measuring delivery than discovery. Understandable! Delivery leaves evidence: features ship, roadmaps advance, quarterly goals turn green, and progress can be neatly captured in dashboards and status updates. Discovery, by contrast, often looks like a squad of Designers, Product Managers, and Engineers spending weeks questioning assumptions, exploring alternatives, and occasionally concluding that the original idea wasn’t worth building in the first place.

One of the more interesting side effects of AI may be that it forces companies to reconsider where value is actually created. For decades, software organizations were constrained by implementation cost — building things was expensive. As a result, much of the industry’s status, compensation, and organizational influence became tied to the ability to turn decisions into shipped software.

But what happens when implementation becomes dramatically cheaper? The bottleneck simply moves upstream. A world where prototypes, interfaces, and even functioning applications can be generated in hours rather than weeks is a world where delivery matters less, not more. To be clear, deciding what deserves to be built has always been the hard part. What’s changing is that the cost of getting that decision wrong is falling, while the consequences of getting it right become increasingly important.

What is the customer actually trying to accomplish? Which frustrations are real and which are merely reported? Which opportunities are worth pursuing, and which are artifacts of the metrics we happen to be measuring? Which briefs are asking the wrong question altogether?

The irony is that the people who are best at discovery often have the least to show for it. A reframed problem, a sharper understanding of customer needs, or a realization that the most promising opportunity lies somewhere other than where the roadmap originally pointed can be every bit as consequential as a successful launch, even if it’s far more difficult to capture in a dashboard or quarterly review.

Those contributions have always been valuable. They may simply become easier to recognize, now that anyone can ship.

(Via Sidebar, which is excellent. You should subscribe!)

A small tidbit from Product Design Psychology, by Wouter de Bres:

“The first idea that feels good is often the one that survives, not because it’s right, but because the team becomes emotionally attached to it.”

One of the most useful observations in the book is that many of the problems we describe as design challenges are actually human challenges. The tendency to become attached to an early idea isn’t unique to design teams, it’s just a form of commitment bias that happens to show up around whiteboards and Figma files.

De Bres’s observation is not revelatory; every experienced designer has seen it happen. A promising idea emerges, the room likes it, and what began as exploration quietly becomes justification. But naming the bias makes it easier to catch before it hardens into the plan.

The work is to keep exploring a little past the point where it already feels solved.