AI × Judgment × Taste = Mega Software

A few days ago, I sent a message to Michael, my co-founder:

AI + good judgment + taste = mega software

The more I thought about it, the more the plus signs felt wrong. Multiplication describes it better because AI amplifies the judgment and taste you bring to it.

AI × judgment × taste = mega software.

AI is an incredible accelerator. I am extremely bullish on it. It has completely changed how quickly we can turn an idea into working software. But faster production does not automatically result in a better product.

If you point AI at the wrong problem, it helps you get to the wrong result faster. If you accept the first reasonable output, you will end up with software that works but feels generic. Combined with good judgment and taste, however, it gives small teams a level of leverage that would have been impossible only a few years ago.

Why AI Slop Is So Easy to Recognize

There is a lot of software being produced right now. AI made plausible results incredibly cheap.

A first version can work, look acceptable, and come with professional sounding copy. But after using it for a few minutes, you notice that something is missing. The workflows feel generic. Every action seems equally important. Features exist because they were easy to add, not because somebody decided they should be there.

People have developed a feeling for this. They might not call it AI slop, and they might not be able to explain exactly what is wrong, but they recognize the absence of intent.

I don't think the bar for a good experience has increased that much. Clarity, coherence, usefulness, and care have always mattered. What changed is the quantity of software people encounter. We now see more software, compare more software, and recognize much faster when nobody held a high standard while building it.

Judgment Starts With Whom You Serve

For me, mega software is not software that tries to do everything for everyone.

It is software built for a clearly understood group of users. It is shaped around their everyday work, their problems, and the way they think. It improves their quality of life because somebody took the time to understand what matters to them.

Judgment decides whom the product is for, which problems are worth solving, which trade-offs to accept, and what to leave out. AI can help explore all of these questions. With enough context, it can propose very good solutions. But somebody still needs to decide which customer conversations matter, how to reconcile conflicting needs, and what the product should become.

AI can participate in that process, but a team first needs to develop and articulate its own judgment. Otherwise there is nothing meaningful for AI to work with.

Opinions Inside a Customizable Platform

At Vendure, we intentionally built a highly customizable ecommerce platform. Our users bring their own opinions about how their final solution should work and look, and we do not prescribe one universal commerce experience.

Our opinions live one layer lower. We care deeply about how developers reach their desired outcome. The primitives, extension model, workflows, and boundaries are our responsibility.

I have been thinking about this a lot while working on the next iteration of our design system and adopting it in the Vendure Admin Dashboard. The dashboard has many extension surfaces where developers can add their own components and actions. In the past, we placed very few restrictions on these surfaces. You could put almost anything almost anywhere.

That sounds flexible, but flexibility without constraints often transfers the design burden to every extension author and, eventually, to every user.

Take an action bar that allows extensions to add buttons. Previously, an extension could add another primary button. And another. The result was a busy interface where users could no longer tell which action mattered most.

With the new design system, extensions can still add actions, but they cannot add primary ones. Our opinion is simple: every view should have one clear primary action.

Developers still have the extension point, while the dashboard retains a clear hierarchy.

AI is excellent at accelerating the implementation of this migration. It can find extension surfaces, convert components, apply established patterns, and produce convincing interfaces. Deciding that unrestricted primary actions were a product-level design flaw required more than code context.

That conclusion came from context beyond the code: experience with the product, conversations with users, and a clear opinion about how the interface should behave.

Taste and High Benchmarks

Taste is harder to define because it is subjective. I see it almost as a character trait, something you develop over time through everything you have seen, built, rejected, and learned to care about.

Over time, you develop a feeling for details that are technically acceptable but do not fit the product you want to build.

Taste shows up in visual hierarchy, behavior, language, consistency, restraint, and hundreds of small details. But it also shows up in the benchmark you hold. It means not accepting the first plausible idea simply because producing another one is easy.

AI makes the first acceptable answer almost free, which makes it tempting to stop there. Taste shows in the willingness to keep questioning and improving that answer.

Taste cannot be fully captured in a checklist, but its consequences can be shared. A team can turn past decisions into design principles, strong defaults, component APIs, examples, naming conventions, and constraints. The rule that every view gets one primary action is one small example. Once encoded in the system, future developers and agents benefit from it without having to revisit the same discussion.

Good DX Helps Agents Too

The same thinking applies to developer experience. Agents write a lot of code today, but humans must still be able to read it, understand it, maintain it, and make confident decisions about it. Clear APIs, strong conventions, good names, explicit contracts, and understandable architecture make that possible.

Interestingly, the things that improve DX for humans usually improve it for agents too. A well-designed system contains less ambiguity. Agents can produce better code, navigate the codebase more reliably, and answer questions more accurately.

Software now has human and non-human users. The best experience is not identical for each group. A human might need a clear workflow and strong visual hierarchy. An agent might need predictable APIs and explicit boundaries. In both cases, good judgment begins by understanding who is using the product and designing around their needs.

A Better Way to Build With AI

I want us to use AI as much as possible while bringing more context, judgment, and taste to the process.

The loop I aim for looks like this:

Give AI the product context and constraints, not only the task.
Use it to explore several credible approaches.
Apply human judgment to choose the right trade-off.
Apply taste through critique and iteration until the result meets a high benchmark.
Encode the decision into the system so future humans and agents inherit it.

This changes the role of a product builder. More of our time can go into understanding users, translating their problems, setting the standard, and deciding what good means because AI takes on more of the implementation.

There Is No Universal Best

AI will become much better at proposing context-sensitive and tasteful solutions. I expect it to participate in more of these decisions over time.

But there is no universal best product. Best is different for every group of users, human or non-human. It depends on whom you choose to serve, which trade-offs you accept, and what you believe their experience should be.

As AI takes on more judgment, we will still have to choose which opinion it should follow and which outcome is worth pursuing.

That is why I am so optimistic about what comes next. Small, thoughtful teams have unprecedented leverage and can build exceptional software faster than ever before. To use that leverage well, they need to understand their users deeply, hold strong opinions, reject output that is merely plausible, and encode what they learn into the product.