Addy Osmani recently shared something that caught my attention: "AI users are working longer because, for the first time, our tools can finally keep pace with our imagination.

But speed doesn't matter if you lack a destination."

That pair of lines captures a tension I have been seeing everywhere in AI product work. We have more capability at our fingertips than ever, and yet many of us feel busier, not freer. Addy then lands the point that, to me, is the real thesis: when output is cheap, the leverage is not in building more, it is in having the taste to know what is worth building, and the rest to see the difference.

In other words: AI increases your velocity, but it does not choose your direction. And when direction is unclear, velocity turns into thrash.

The new paradox: faster tools, longer days

If AI tools "keep pace with our imagination," why do people report working longer? Because imagination is not a queue that gets emptied. When the cost of producing a first draft drops, we simply generate more drafts. When prototypes are easy, we build more prototypes. When refactors are suggested instantly, we attempt more refactors.

The bottleneck moves. It used to be typing, syntax, scaffolding, and basic implementation. Now the bottleneck is deciding:

What problem is real and worth solving?
What quality bar matters for this context?
What tradeoffs are acceptable?
When is it done, and when is it just more?

"Speed doesn't matter if you lack a destination."

Addy's line reads like a warning label for modern knowledge work. Without a destination, speed simply helps you arrive at the wrong place sooner, or arrive at many places that do not matter.

When output is cheap, judgment becomes expensive

Addy wrote: "When output is cheap, your greatest leverage isn't how much you build, but the taste to know what is worth building." That is a shift in competitive advantage.

In the pre-AI era, teams could win by sheer execution. If you could ship reliably, you outpaced teams that could not. Execution still matters, but AI compresses the gap on execution for a lot of tasks: drafting, boilerplate, test generation, initial UX copy, even early research summaries.

So the differentiator becomes judgment. Not just "can we build it?" but "should we build it?" and "what should it feel like when it is built?"

Think of it like this:

Cheap output increases volume.
Increased volume increases noise.
More noise increases the value of filters.

Taste is a filter. Strategy is a filter. A clear destination is a filter.

What "taste" looks like in AI product development

Taste can sound mystical, but in practice it is observable. It shows up in decisions like:

1) Choosing the right problem, not the loudest one

AI makes it easy to spin up features that demo well. But users do not live in demos. Taste is recognizing when a flashy capability is not a meaningful improvement to a workflow.

Example: A team can generate ten different "AI assistant" variants in a week. Taste is realizing the real constraint is user trust, permissions, and failure modes, then narrowing to one assistant that is safe, scoped, and deeply integrated.

2) Knowing the difference between "possible" and "valuable"

AI expands the space of the possible. Product strategy narrows it to the valuable.

A practical question I use: if this feature worked perfectly, what would it make measurably better? Time to complete a task? Error rate? Confidence? Adoption? Retention? If the best-case answer is "it would be cool," taste says no.

3) Picking constraints on purpose

In AI systems, constraints are not limitations, they are product decisions. Limits on scope, allowed actions, sources of truth, and escalation paths all shape quality. Taste is selecting constraints that create reliability.

4) Editing ruthlessly

AI makes more text, more code, more options. Taste is the willingness to delete. The best teams I know are not the ones generating the most artifacts, they are the ones curating the smallest set of artifacts that clearly move the work forward.

When generation is abundant, curation is the craft.

The "rest" Addy mentioned is not optional

Addy also pointed to "the rest required to see the difference." I read "rest" in two ways, and both matter.

Rest as recovery

If AI increases throughput, it can also increase cognitive load. More choices require more evaluation. More iterations require more context switching. That drains you. Without recovery, your ability to judge quality degrades.

This is a subtle trap: you adopt AI to go faster, you skip breaks to capture the speed, and then you lose the discernment that makes the speed useful.

Rest as distance

Rest is also creative distance. The ability to step back and ask, "Is this actually good?" and "Is this aligned with the destination?"

Some of the best quality control mechanisms are time-based: sleep on it, review tomorrow, run it by a teammate, test with a real user, revisit after you have forgotten the details. AI can accelerate creation, but it cannot replace perspective.

A simple workflow: destination first, then speed

If you want to apply Addy's idea in day-to-day work, here is a lightweight workflow that keeps AI as an engine, not a steering wheel.

1) Write the destination in one paragraph

Before prompting, write:

The user: who is this for?
The job: what are they trying to get done?
The constraint: what must be true (privacy, cost, latency, accuracy)?
The metric: what improves if we succeed?

If you cannot write this, speed will not help.

2) Ask AI for options, then pick with criteria

Use AI to broaden, but not to decide. Generate 5-10 approaches, then score them against your criteria (risk, impact, effort, maintainability).

Taste often looks like the ability to say: "Option 7 is the only one that respects our constraints."

3) Use AI to draft, but require a human edit pass

Whether it is code, copy, or a design spec, institute a rule: nothing ships without a human edit focused on clarity, correctness, and coherence with the destination.

A good edit checklist:

What did we remove?
What assumption did we verify?
What failure mode did we design for?
What did we choose not to build?

4) Build the smallest test that answers the question

When output is cheap, overbuilding is easy. Instead, define the question and build only what answers it. Prototype to learn, not to impress.

5) Schedule "rest" like it is part of the system

Put a review gap into the plan. Add a pause before launch. Encourage shorter loops with real users instead of endless internal iteration. Your judgment is part of the product pipeline. Protect it.

Closing thought: AI amplifies you, including your drift

Addy Osmani's post resonates because it reframes the AI moment. We are not just getting more productive. We are getting more amplified. If you have a destination and taste, AI helps you move with surprising force. If you do not, it amplifies drift, busywork, and endless iteration.

So the question is not "How fast can we generate?" It is "What are we trying to become true, and what quality bar will we accept on the way?"

If you can answer that clearly, then yes, let the tools keep pace with your imagination. Just do not confuse motion for progress.

This blog post expands on a viral LinkedIn post by Addy Osmani, Director, Google Cloud AI. Best-selling Author. Speaker. AI, DX, UX. I want to see you win.. View the original LinkedIn post →