The effort and time it takes to produce high-quality software has radically collapsed before our eyes. The collapse has been so fast that many of our peers still don’t believe that AI coding tools like Claude Code, Cursor, and Codex can write much more than a single, useful unit test, let alone a full-scale web application.

Whether you’ve tried Cursor or not, you’re still our peer—and if you haven’t touched these tools since October 2025, the next few paragraphs may sound like far-fetched hyperbole. It’s not. There is plenty of hype, but it’s not too late to separate what’s real from what isn’t. That speed still demands human judgment: security, maintainability, and whether you built the right thing still need your eye.

I drafted this post in two apps I built the same afternoon I wrote it. That’s the point: when effort collapses, taste and curiosity decide what gets built.

Starting around October 2025, developers on teams who had estimated work in weeks, months, and quarters began seeing the same features land in minutes, hours, and days.

Time to value is a blunt but useful measurement: how long did a person or team spend building something before a consumer could use it? Until 1913, assembling a Ford Model T took twelve hours; the introduction of the assembly line cut that to ninety minutes—a 7× collapse. We’re watching the same pattern in software.

That shift changes the economics of a unit of work.

Unit economics of work

We’ve seen this before. Agile, DevOps, and CI/CD collapsed ship time from Golden Masters on cassette and disk to continuous delivery. AI is compressing build cycles again—faster than any of those movements.

Until recently, ideas were cheap, and execution was expensive. When that’s the case, it’s important to pick the right things to work on. Otherwise, you can put a team to work for months and quarters, only to find the software isn’t what the customer needed. Or worse, the software doesn’t work the way customers expect, and you kick off a full rebuild.

With delivery cheap, effort is no longer the bottleneck. What remains is taste and curiosity.

Taste

“Ultimately it comes down to taste.” – Steve Jobs, 1995.

Merriam-Webster defines taste as “critical judgment, discernment, or appreciation”.

Taste is subjective, not arbitrary—and it’s what will separate the next generation of app builders. It includes, but is not limited to, understanding why the software exists, user experience, and user interface design.

You might not be an expert in Figma, and you may well feel that visual design sits outside your wheelhouse. Taste still shows up in copy, defaults, API shape, and what you accept from an AI-generated diff.

Taste involves constraint and restraint. Understanding how constraints the system imposes on users will feel is important. Knowing how a user might react when a checkout cart suggests they can check out with 101 items, when the basket only permits 100 items.

Restraint is knowing what not to do. What to leave on the table. The things you don’t ship. The film strip on the cutting room floor.

Pay attention to small details—they’re usually a good sign of taste. Place an iPhone on the corner of a MacBook Pro and notice how the rounded corners match.

“Selection, taste, and discernment make you and the product of your work stand out.” — Sarah Gibbons and Kate Moran

Sarah Gibbons and Kate Moran wrote in May 2024 about Design Taste vs. Technical Skills in the Era of AI. Talk about being ahead of the curve: AI coding tools have leaped forward in the past two years, yet the authors already argued that taste—not tooling alone—would define who stands out.

Stripe is a useful example. The Collison brothers built for developers who had wrestled with payment gateways: opaque errors, opaque IDs, little help when something failed.

Human-readable errors and prefixed IDs—acct_ for an account, and so on—are small choices that signal taste. The system tells you what went wrong and what you’re looking at. That helped Stripe’s own engineers and everyone integrating their APIs.

The same bar applies to the next change your agent proposes: taste is the bar. Do you like what it's proposing. Is it working within the constraints you had in mind? Is it functioning how you might have intended? Is it directionally correct?

Curiosity and prototypes

“Be curious. Read widely. Try new things. What people call intelligence just boils down to curiosity.” — Aaron Swartz

Get curious about problems. Get creative about solutions. Solutions don’t have to be forever. When a prototype costs minutes instead of sprints, you can try an answer and see if it moves you forward.

In The Value Flywheel Effect, David Anderson uses the phrase Next Best Action repeatedly. Can you name yours? Can you see how it advances the solution? Can you build a quick version—a prototype—and try it? Does the result match your taste?

Prototypes are how curiosity meets the keyboard. With tools like val.town, Lovable, Replit, and others, a toy-like prototype can exist in under five minutes. That might sound like a stretch until you’ve done it once.

Let’s be clear. Prototypes can range from paper sketches right through to a fully working Formula 1 car that can race around a track at 350 km/h. You don’t enter that car in a Grand Prix, and a customer doesn’t wire money from a sketch. Prototypes are approximations; each iteration should teach you something new. Taste decides whether the approximation is good enough—or whether you spin another version in the time it used to take to schedule a meeting.

With AI coding agents, UI prototypes can pull from real design systems, exercise assistive technology paths, and surface edge cases—all from a few sentences. Before agents, those layers rarely made it into throwaway builds because prototypes were expensive. Now you can shift that reasoning left and test earlier.

What’s next

Speed is largely solved. Judgment and experimentation are not.

You can develop taste: watch what works on the web, build small things, notice patterns worth stealing. You can feed curiosity the same way—pick one annoyance in your workflow, prototype a fix tonight, and judge the result with taste, not velocity.

This post is my own proof. I drafted it across a desktop app and a Progressive Web App for Mobile I built with AI coding tools while writing—because nothing off the shelf fit my workflows, and because I wanted to learn a couple of platforms and tools along the way.

Just Write is what I called the app: two keyboard taps, a few words, another shortcut, and the window is gone—thought saved for later. Restraint (don’t ship a bloated editor) and curiosity (try until something fits) in one small tool.

If effort is cheap, the question isn’t can we build it? It’s should we—and does it feel right when we do?