"We could just make something up in our bedrooms and thousands of people would buy it."
— Philip and Andrew Oliver (The Oliver Twins) about video game development for PCs in the 1980s
"Release early. Release often. And listen to your customers. Given a large enough beta-tester and co-developer base, almost every problem will be characterized quickly and the fix obvious to someone."
— Eric S. Raymond in his 1997 essay about the open source movement"The Cathedral and the Bazaar"
"How to build a blog in 15 minutes with Rails."
—2005 Talk by David Heinemeier Hansson about the new programming language Ruby and the new web development framework Rails.
These are snapshots of how product development has changed – "sped up" over multiple decades. Software used to be incredibly expensive and time-consuming to make. The Computers of the 1960s needed special rooms, access granted by the hour. The development languages and tools of the time were bare-bones, requiring lines and lines of code to simply put text and an input field on the screen. One of the most significant projects of the time – the software for the Apollo Lunar Lander – was developed at MIT over five years with 1,700 engineers.
David L. Chandler | MIT News Office
If you spend time creating software, the first question from the team, customers, executives, and shareholders is always, "How do we go faster?" The reality is that every era has made the actual creation of "bits" faster than the ones before. Some of those changes were driven by innovation in coding languages – Assembly gave way to C, abstracting away complexity. It was akin to building your own bookshelf by sawing and nailing raw lumber, to buying a flatpack from IKEA.
Innovations came in the form of process changes. We stopped writing specification documents that ran to hundreds of pages, and we stopped trying to perfect every release before the first customer saw it. What Eric S. Raymond referred to in his essay was often called "internet time," a magical period when new software releases came out every few months. This wasn't a technical change but one of approach – we built iteratively, enrolling our customers in the feedback loop, and prioritized early feature use over perfection. It was the time when "waterfall" or "MethodOne" gave way to Agile development, when massive teams gave way to "pods."
And then innovation came in the form of pre-made parts. It turns out that a date picker gadget on a page was pretty much the same everywhere, so let's just reuse one that was already written. Or that the basics of a weblog were common, so just use the Rails framework to stand up a site in a few minutes. We went from an IKEA flatpack to getting a fully assembled cabinet, and your only job was picking the cabinet from the catalog and deciding what vase to place on top.
An Embarrassment of Software Riches
While a few of the non-technical people I've worked with might disagree, the fact is that software has become faster and (mostly) cheaper to make every single year. And while the appetite for "apps" is seemingly insatiable, every year from the "internet era" through today, companies build features, modules, even entire applications that are launched to great fanfare... and then sit unused. Worse, some users enter into a masochistic relationship with the software – forced to use it because there are few other options, but struggling with its design or quality. The constraint used to be throughput. Now it's "taste."
AI has supercharged the creation of software. Building more things used to be a function of hiring more human engineers – and as an industry, we got really good at that in the 2010s. Having tools to manage product development teams of hundreds or thousands of people. Today, we're putting "coding agents on the team," using Anthropic's Claude Code or OpenAI's Codex agents as engineers to write features or clear backlog items. AI also continues a trend that dates back to the advent of BASIC as a programming language: letting non-engineers write software. AI has so lowered the bar to creating software that 2026 has seen an exponential rise in the number of new apps. To extend the furniture metaphor, it's as if we gave everyone a 3D printer and they could press a button to get a custom table.
But a curious thing happened along the way to radically democratizing app creation: no one is using them. This chart made the rounds recently showing the widening gap between the number of new mobile apps in Apple's AppStore and the number of apps with significant usage. The number of apps doubled in a year – but the number actually used declined.
You Can Build It, But They May Not Come
I would argue that even before AI, good design and a strong product mindset have always been the limitations in creating software. Before AI, we could brute-force development with people. It's why bootcamps, offshore Global Capability Centers ("GCCs") all became popular in the previous decade. It may not have been the cheapest solution to the problem of "more stuff, faster," but it was a solution available to many companies. What was much harder to solve was building what users actually wanted: the apps, tools, and services that brought great experiences.
For most of the PC era, the pacesetters have been Microsoft and Apple. Since the late 1980s, in terms of the number of people working on products, Microsoft has always been the far larger company. More engineers, more product development teams, more R&D. But Apple receives far more plaudits for its products. By all the usual measures – NPS, customer satisfaction, "most loved" brands – Apple wins out. Apple's cofounder had his own diagnosis:
"The only problem with Microsoft is they just have no taste. They have absolutely no taste. And I don't mean that in a small way, I mean that in a big way, in the sense that they don't think of original ideas, and they don't bring much culture into their products."
—Steve Jobs, Triumph of the Nerds PBS interview (Cringely). And this was before Microsoft Teams.
The complicated rivalry between Apple and Microsoft is well known for the places (more often Microsoft than Apple) where one tried to follow the other into a product category with disastrous results for the other: music players (iPod vs Zune), mobile phones (iPhone vs Windows Phone), tablets (iPad vs Surface). It's not that Microsoft products didn't work or that they didn't offer core functionality; it was the way they offered that functionality. There was a huge gap in perceived intuitiveness, in the interconnectedness of the experience. Microsoft could build code faster (and often did), but Apple built better products. Where Microsoft did win, where throughput helps, is on distribution and unit economics. But taste wins on devotion. And building products people love is the key to long-lived, sticky customer relationships.
The Speed Mirage
A question I often like to ask in product development discussions is "to what end?" What will the end result be if we're successful? What does "good" look like for our user? Because – to paraphrase Marty Cagan – it's not output that is critical in product development but outcome.
But lots of companies worship at the altar of output. There are teams that build "strategic goals" around lines of code written or the percentage of engineer time on technical tasks. Putting aside for the moment that these "goals" violate Goodhart's Law about metrics becoming goals, as any first-time developer could tell you, writing huge volumes of code isn't hard – you just have to be really bad at the work. Only one goal matters: are we building what our current or prospective users find valuable?
This isn't to say that building more or building faster is bad. Quite the contrary – in well-run product orgs, there is always more meaningful work to do than the team can absorb. But increasing the output of code is only part of the equation. I love Claude Code. I find the ability to treat it as an engineering partner and let it handle everything from writing logic for features to handling cloud ops tasks shockingly empowering. But it's only as good as the context it's given, only as good as the human directing what the features do and how they form the holistic workflow.
This is especially true with design. It's easy to create UI these days, easy to point a form at the underlying data and display it. But it's damn hard to make an elegant UI, one that displays information intuitively and makes it easy for users to operate. Software isn't any different from physical objects like appliances or cars. If one microwave made reheating pizza a multi-step process, it won't sell very well – it's complexity vs simplicity. There was a trend for a bit with microwaves in creating a button for every common food (pizza, frozen dinners). But in the end, people just mashed the "+30 seconds" button for as many times as they needed to get the right temperature. The buttons were a waste and made the panel more complicated.
Taste in software is also focusing on the essential elements. If you ask 100 users what they want, you likely get 100 different items. With the massive increase in code throughput, there will be a temptation to add every feature request to the backlog. But software isn't a shopping mall Christmas tree where we just keep adding lights and tinsel. All good software has an underlying theme of how and why it works, a cohesive experience that follows from form to form. Constraints are incredibly valuable. Prioritizing this cohesion over "more stuff" is a vital part of creating good products.
And taste is also how software works beneath the features. Good software is performant; it's organized in a way that makes changes easier and reduces brittleness. It's secure. Architecture and thoughtful technical design aren't outmoded with AI; they're even more essential. Taking the time to create detailed, long context files for coding agents that describe the overall system architecture and principles, rather than just jamming commands into the prompt window, is the right way to use coding agents. It takes more time. But it also requires judgment, experience...you know, "taste."
Move Fast...with Taste
AI is the realization of something we've built toward in engineering for decades: producing logic and infrastructure fast and at scale. Gone are the days when it would take months to build, debug, and deploy an app to do something like manage customers and their preferences. Now we can make it in an hour. One enormous constraint is now gone. The hype is real with AI coding agents — manifold throughput improvements are real.
But taste is a different part of the creation process, and it resists automation in a way code never did. Taste is accumulated judgment — built over years out of thousands of small decisions, many of them wrong, none terribly useful in isolation. It's why you can't put it in a prompt – the person who has it usually can't fully explain it either. Code generation parallelizes because patterns inherent in it the machine can run with it. Taste doesn't parallelize, because discernment is a quality that lives in a human with experience.
Which is why throughput is no longer a moat. Having an army of trained engineers used to be an advantage; now it's just a question of how many tokens you have. The constraint moved. It puts the weight back on the things that were always the real work: architecture, UX design, customer-obsessed product management.
And it means the most important — and most easily overlooked — thing we can do is keep growing the people who hold that judgment. Taste is grown in the iteration of products, in the give-and-take with real users. It's knowing what to do... and what not to do. The code got cheap. The person who knows what to do with it didn't.
We spent decades optimizing how fast we could build. It turns out that was the easy problem. The hard one — the one that was always the real work — was taste.
Member discussion: