25 January 2026

How is AI Raising the Quality Bar for Software Development Instead of Lowering It?

AI Raising the Quality Bar for Software Development

Ben Thompson wrote something in his essay "Regretful Accelerationism" that has shaped how we think about every project we take on: "I suspect we humans do better with constraints." He was discussing the internet's evolution, but after working on 200+ software projects across four continents, we've watched this principle play out in software development. AI tools are removing the production constraint that shaped our industry for decades. What's replacing it is more challenging than most founders realize.

Why Fewer Constraints Can Increase Difficulty
The Quality Floor Set by Past Constraints
Lessons from Removing Content Constraints
The Software Flood Has Already Arrived
Where Competitive Advantage Truly Resides Today
How the Quality Bar Has Shifted
Taste as the New Bottleneck
What to Build for in Today’s Reality
Choosing the Right Constraints

Why Does Removing Constraints Often Make Things Harder?

Thompson traced how the internet progressively removed constraints that had shaped media for generations: the constraint of physical distribution, the constraint of editorial gatekeeping, the constraint of production costs. Each removal was celebrated as democratization. Each also created new problems.

The removal of distribution constraints gave us infinite content but made it impossible for quality to reliably find audiences. The removal of editorial gatekeeping gave us diverse voices but made it impossible to distinguish signal from noise. The removal of production costs, now accelerating with AI-generated content, threatens to flood the internet with material that is technically content but practically worthless.

Thompson's framework applies directly to what is happening in software development. AI tools are removing the production constraint that shaped software for decades: the requirement that building software requires engineers. This constraint limited what got built. It also, without anyone intending it, maintained a quality floor.

As this constraint disappears, we need to think carefully about what replaces it. Because the history of constraint removal suggests that what follows is not simply more of what came before at lower cost. What follows is a fundamental reshaping of what success requires.

What Quality Floor Did the Old Production Constraint Create?

For most of software's history, building an application required either engineering skills or money to hire engineers who had those skills. This was such a fundamental fact of the industry that we rarely examined its implications.

One implication was scarcity. Because building software was hard, relatively little software got built. This scarcity meant that functional software had inherent value. If you managed to build something that worked, you had accomplished something that most people could not accomplish.

How Did Difficulty Act as a Quality Filter?

Another implication was filtering. The difficulty of building software meant that only the most motivated and well-resourced attempts succeeded. This filtered out casual efforts, half-formed ideas, and projects that nobody really believed in. What made it through the filter tended to represent genuine commitment.

When we worked with Premier Construction Software, they had spent years building their platform the traditional way. That investment forced discipline. Every feature had to justify the engineering time required. Every design decision carried weight because changing it later was expensive. The production constraint created a quality correlation that nobody deliberately designed but everyone benefited from.

What Happens When Building Software Becomes Easy?

AI tools are removing this constraint. Building software is becoming accessible to people without engineering backgrounds. The investment required to produce a functional application is dropping dramatically. The filtering mechanism that kept casual efforts from reaching completion is weakening.

This is celebrated as democratization, and in some ways it is. But democratization of production does not automatically mean democratization of success. It often means the opposite: when everyone can produce, production provides no advantage, and success depends entirely on other factors.

What Can We Learn from Content's Constraint Removal?

Consider what happened to written content when production constraints disappeared.

Publishing used to require printing presses, distribution networks, and substantial capital. These constraints limited who could publish, which meant that publishers served as gatekeepers. Getting published was an achievement that conferred credibility.

How Did the Internet Change Content Production?

The internet removed these constraints. Anyone could publish anything. Initially, this was liberating. Important voices that traditional publishing had ignored found audiences. Information became more accessible. The gatekeepers lost their power.

But then the flood came. With no constraint on production, the amount of published content exploded. Most of it was mediocre or worse. The signal-to-noise ratio collapsed. Readers could no longer use "it got published" as a quality filter because everything got published.

What emerged were new filtering mechanisms: social media algorithms, search rankings, recommendation engines. These filters replaced human editorial judgment with engagement optimization. The result was not the cream rising to the top but the most engaging content rising, regardless of quality. Engagement and quality turned out to be very different things.

Is the Software Flood Already Here?

Apply this framework to software and the implications become clear. We are seeing the early signs in our own work.

We are in the early phase where the removal of production constraints feels liberating. People who could never build software before can now build functional applications. Ideas that would never have been implemented are finding their way into the world. There is genuine excitement about the possibilities.

What Will Abundance Do to Software Quality?

But the flood is coming. As AI tools mature, the number of applications in the world will explode. Most of them will be mediocre or worse. The fact that something is "an app" will cease to mean anything. Users will need new ways to filter, and those filtering mechanisms will reshape what succeeds.

This is the transition from scarcity to abundance, and abundance changes everything. In scarcity, existence is value. In abundance, existence is noise. The thing that was precious becomes worthless precisely because it is no longer scarce.

When we built Cortex for construction drawing management, being able to build software was not the competitive advantage. Dozens of generic document management systems existed. The advantage came from deeply understanding construction workflows, anticipating specific industry pain points, and designing for the actual chaos of job sites.

For founders, this means that simply building an app provides zero competitive advantage. Your competitors can build apps too, just as easily, just as quickly. The advantage must come from somewhere else.

Where Does Competitive Advantage Actually Live Now?

If production provides no advantage, where does advantage live? After a decade of watching what succeeds and what fails, we've identified four sources of durable advantage.

Why Is Deep Problem Understanding Irreplaceable?

The first source of advantage is understanding the problem. When building was hard, you could succeed with a mediocre solution to a real problem because better solutions did not exist. When building becomes easy, mediocre solutions face competition from other mediocre solutions and from good solutions.

This understanding cannot be purchased or automated. It requires spending time with users, observing their behaviour, understanding their frustrations, and recognizing the gap between what they say they want and what would actually change their lives. This work is inherently human, inherently time-consuming, and inherently valuable precisely because it cannot be shortcut.

Our UX research process exists because we learned this lesson repeatedly. When Opus Platform wanted to transform job search in Saudi Arabia, AI could have generated a generic job platform in days. But only months of understanding Saudi hiring culture, employer expectations, and job seeker behaviour could produce something that actually worked in that market.

What Makes Design Excellence a Competitive Moat?

The second source of advantage is design excellence. User experience is not about aesthetics. It is about reducing friction, anticipating needs, and creating flows that feel inevitable rather than constructed.

Design excellence requires taste, which is accumulated judgment about what works developed through experience. AI can implement designs, but it cannot make design decisions that reflect genuine understanding of human psychology and behaviour. The designer who has spent years observing how people interact with software brings judgment that AI cannot replicate.

How Does Strategic Positioning Create Defensibility?

The third source of advantage is strategic positioning. In a crowded market, being slightly better is not enough. You need to be different in ways that matter to specific users. This requires understanding not just your users but your competitive landscape, recognizing the gaps that exist, and positioning your product to fill them.

Strategic positioning requires synthesis across many inputs: user research, competitive analysis, market trends, technological trajectories, business model considerations. This synthesis is exactly the kind of work that remains stubbornly difficult for AI systems. Our digital strategy practice focuses on this synthesis because it cannot be automated.

Why Does Technical Quality Determine Long-Term Success?

The fourth source of advantage is technical quality that enables evolution. Software is not a static product. It evolves over time as requirements change, users grow, and markets shift. The technical decisions made at the beginning determine whether the software can evolve gracefully or becomes a burden.

When we took over Electrosmart from spreadsheet chaos, the challenge was not building features. It was building architecture that could scale with their arbitrage business model. AI-generated code tends to solve immediate problems without considering long-term implications. It creates technical debt invisibly. It builds structures that work today but resist modification tomorrow.

Experienced engineers make decisions that account for futures that AI cannot anticipate. This is why our DevOps and infrastructure approach emphasizes maintainability and evolution over quick wins.

How Has the Quality Bar Actually Changed?

Here is the paradox of constraint removal: when production becomes easy, quality becomes harder.

Under the old constraints, quality was somewhat correlated with effort. If you put in the work to build something, you probably put in some work to make it decent. The effort required for production created a natural quality floor.

What Happens When the Quality Floor Disappears?

When production becomes effortless, this correlation breaks. You can now produce low-quality output as easily as high-quality output. The quality floor disappears. The variance in what gets produced explodes.

For users, this means their filtering challenge intensifies. They need new signals for quality that do not rely on production effort. They will develop these signals, and those signals will reshape what succeeds.

For builders, this means that quality is no longer about exceeding a floor. It is about standing out from a sea of mediocrity. The standard is not "is this good enough?" but "is this noticeably better than the abundant alternatives?"

When Valley Insurance Associates needed a CRM, generic insurance software existed. AI could have generated another generic solution. What made their system valuable was obsessive attention to their specific workflows, their specific compliance requirements, their specific pain points. That level of specificity requires human judgment, not AI generation.

Why Does Taste Become the New Bottleneck?

Thompson's "regretful accelerationism" suggests that removing constraints often harms more than it helps. But his regret is not a call to restore old constraints. It is a recognition that we need to develop new capacities to navigate a world without them.

What Is Taste and Why Can't It Be Automated?

In software, the capacity we most need to develop is taste. Taste is the accumulated judgment that allows someone to recognize quality, to distinguish what works from what merely functions, to see what is missing when everything seems present.

Taste cannot be automated because it is inherently about human experience. It cannot be scaled because it resides in individual judgment. It cannot be purchased because it develops only through practice and reflection.

This makes taste the new bottleneck. AI can produce unlimited software, but humans with good taste are finite. The ability to evaluate, curate, and refine becomes more valuable as production becomes cheaper. The person who can look at an AI-generated application and see exactly what is wrong with it, exactly what would make it excellent, becomes essential.

For agencies and development teams, this suggests a shift in value proposition. The value is not in producing software. The value is in shaping software: guiding what gets built, evaluating what emerges, refining until it reaches genuine quality. This is why our content strategy and brand identity services have become as critical as our technical capabilities.

What Should You Actually Build For in This New Reality?

If this analysis is correct, what does it mean for founders building software products today? After watching hundreds of products launch, succeed, and fail, we've identified five principles.

Why Must You Invest More in Understanding Before Building?

First, invest more in understanding before building. When building was expensive, you could justify starting with assumptions and learning through iteration. When building is cheap, iteration is also cheap, which sounds good but is actually dangerous. You can iterate forever without converging on something valuable. Better to invest upfront in genuine understanding so that what you build addresses real needs.

When C&R Software modernized 40 years of legacy systems, we spent weeks just understanding before writing code. That understanding prevented the endless iteration that AI-assisted development makes dangerously easy.

How Do You Design for Excellence Instead of Function?

Second, design for excellence, not function. Function is table stakes. Your competitors' apps will also function. What will distinguish yours is how it feels, how it anticipates needs, how it makes users' lives better in ways they did not expect. This requires design investment that goes beyond making things work.

Why Does Strategic Positioning Matter More Than Ever?

Third, position strategically, not generically. A generic app in a category with abundant generic apps has no future. A specifically positioned app that owns a particular niche has defensibility. Think carefully about who exactly you serve and what exactly you provide that alternatives do not.

What Makes Architecture More Important Than Code?

Fourth, build for evolution. The code matters less than the architecture. Will your software be able to grow as requirements change? Will it accommodate features you cannot yet anticipate? Will it remain maintainable as the world evolves? These questions require engineering judgment that AI cannot provide.

How Do You Develop Taste Within Your Team?

Fifth, develop taste within your team. Hire people who can recognize quality. Build evaluation capabilities. Create feedback loops that surface problems before they ship. The team's collective taste determines the quality floor for everything you produce.

What Constraints Should You Choose?

Thompson wrote that we do better with constraints. The production constraint is disappearing, and we cannot bring it back even if we wanted to. But we can choose other constraints.

We can constrain ourselves to only building things we genuinely understand. We can constrain ourselves to only shipping things that meet quality standards we define and enforce. We can constrain ourselves to only pursuing markets where we have genuine insight and advantage.

These chosen constraints are harder to maintain than imposed constraints. Nobody will stop you from shipping mediocre software. Nobody will prevent you from chasing markets you do not understand. The discipline must come from within.

But this discipline is exactly what will separate successful products from the flood of AI-generated mediocrity. When anyone can build anything, the builders who exercise judgment, who impose standards, who constrain themselves to excellence, will produce the products that matter.

The end of the average app is not a lament. It is a clarification. Average was never actually a strategy. It worked only because scarcity protected it. In abundance, average disappears into the noise. What remains is excellence. The bar has been raised. The work of meeting it begins with understanding that production is no longer the challenge. Everything else is.

Related articles

Keep reading

Software Development

What is Technical Debt? A Guide for Non-Technical Founders

13 January 2026

Software Development

What Should a Software Discovery Phase Actually Include?

10 January 2026

Design

Why Do Cheap Architectural Renderings Cost More Than Premium Visualization?

14 December 2025

Software Development

What Do Investors Evaluate in Technical Plans Before Funding Startups?

08 December 2025

Software Development

What is a Product Feasibility Study and Why Do 90% of Startups Fail Without One?

18 November 2025

1/5