My wife likes to tell the story about the time she had a 15-course meal at Charlie Trotter's in Chicago.

I'm reasonably certain it was closer to seven courses. Like a fisherman adding an inch to the size of a fish every time the story gets told, the meal seems to have grown a little with each retelling. But the number isn't really the point.

What she remembers is the experience of being served a succession of small, beautifully prepared dishes. You got to try a little bit of everything. Each course was good. Some were surprising. Some were things she would never have ordered on her own. And then there were the one or two that really stuck. Those were the dishes she talked about afterward.

That is increasingly how I think about building software with AI.

AI can put an astonishing number of things on the table. The interesting question is no longer simply whether we can make them. It is which ones are worth making.

For most of my career, software development has involved a fairly expensive translation process. A business has a problem. Subject matter experts explain how the organization works. Product managers work with them to turn that understanding into requirements and specifications. Developers translate those specifications into software. Eventually, the business gets to see the result and tell us whether we got it right.

That process isn't broken. In fact, it is necessary.

The people doing the work know things that developers cannot know simply by looking at a database or a ticket. They know where the manual steps are. They know which exceptions happen every Tuesday afternoon. They know that the field everyone thought was optional is actually the thing a supervisor checks before approving a request. They know how information really moves through the organization, rather than how someone thinks it moves through the organization.

Those people have always been part of good software development. The role of the SME isn't new, and neither is the collaboration between the business, product management, and engineering. What is changing is the cost of turning that collaboration into something tangible.

Consider a business process where information needs to move from Sales to Operations management, then down into operational service lines, with the underlying data eventually making its way into the organization's data warehouse.

There may be obvious opportunities to improve the process. Perhaps some of the handoffs can be automated. Perhaps some of the manual data entry can disappear. Perhaps information that currently lives in one system should be surfaced somewhere else.

But there may not be an obvious answer to what the software should actually be.

Maybe it is a PowerApp. Maybe it is a new operational dashboard. Maybe it is a conventional application that owns the workflow. Maybe the data is already available in the warehouse and the better answer is an AI interface that lets people interact with it conversationally.

All of those can be technically reasonable solutions. The hard part is determining which one actually fits.

This is where AI changes the equation.

We can now take an idea and get something representative in front of the people who understand the problem far more quickly than we could before. Not necessarily a production-ready application, and certainly not something we would trust with the organization's most important data on day one. It is a way to make an idea concrete enough to experience.

That distinction matters because requirements documents can describe a process, but they are not the process itself. You can explain a workflow in a meeting, agree on the fields and the steps, and still discover that something feels completely wrong when the person who actually performs the work sees it on a screen.

Put a proposed workflow in front of an operations manager and they may immediately notice that the sequence is wrong. Show a dashboard to someone who actually runs the process and they may realize that the information they need is buried three clicks too deep. Let an SME interact with an AI interface and they may discover that what they really wanted was not another report at all, but a way to ask questions of information they already have.

The software makes the conversation concrete.

This is where I think the word "taste" starts to mean something more than aesthetics.

Taste is not simply knowing that one interface looks better than another. It is the ability to recognize quality in context. It is knowing that a technically elegant solution may still be the wrong solution for the people who have to use it. It is recognizing when an automation removes an annoying task and when it removes a useful human checkpoint. It is understanding that the most sophisticated technology is not automatically the most appropriate technology.

Most importantly, taste is being able to recognize something good when you encounter it, even when you didn't know exactly what you were looking for.

That is where the tasting menu analogy comes back.

Imagine sitting down to that meal at Charlie Trotter's. You don't have to decide in advance which dish is going to be your favorite. You get a small portion of each, experience it, and compare it with everything else you've tasted. Some dishes may be technically extraordinary but simply aren't for you. Others may be familiar but executed so well that they immediately stand out. Occasionally, something arrives that you never would have ordered and turns out to be the thing you remember most.

Software can work the same way.

AI makes it increasingly practical to put several interpretations of a problem on the table.^[1] A workflow can be represented one way, then another. A dashboard can be built alongside an application. An existing data warehouse can become the foundation for a conversational interface. The goal isn't to build four production systems. The goal is to make the differences between four possible approaches tangible enough that the people involved can recognize what fits.

That changes the nature of the conversation.

Instead of asking only whether a solution satisfies the requirements, we can ask whether it feels right for the organization. Does it fit the way people actually work? Does it remove friction or simply move it somewhere else? Does it make the information more useful, or does it introduce another place for people to look? Does the technology solve the problem, or are we building something interesting because the technology happens to be available?

Those are judgment calls, and they have always existed. AI simply makes it cheaper to get to the point where we have something worth judging.

That may be one of the more important changes AI brings to software development.

The developer is no longer necessarily the only person who can turn an idea into something tangible. A product manager can explore a different interpretation of a requirement. An SME who cannot write code can interact with a working representation of a workflow and immediately identify where it doesn't match reality. A developer can bring several approaches to the conversation instead of spending weeks defending the first one that seemed reasonable.

AI isn't replacing the collaboration between the business, product, and engineering. It is lowering the barrier to participating in it.

And that changes what becomes valuable.

Coding still matters. Understanding software, data, architecture, security, and the realities of production systems is still what separates a useful POC from an expensive illusion. But the ability to produce code is becoming less exclusive, and the ability to produce large amounts of technically competent code is becoming less differentiating.

The developer who can only turn a specification into code is increasingly competing with a machine that is very good at turning a specification into code. The developer who can understand an ambiguous problem, see the organizational context behind it, recognize several possible approaches, and help the team determine which one actually fits is exercising a different kind of skill.

That skill isn't purely technical. It isn't purely business knowledge, either. It is the judgment that comes from understanding both sides well enough to recognize the difference between something that works and something that belongs.

And that is what I mean by taste.

As AI gets better at producing software, it will give us more possibilities to consider. The advantage won't necessarily belong to the person who can generate the most of them. It will belong to the person, or the team, that can recognize which possibilities deserve attention and which ones should be left on the plate.

AI can serve the tasting menu. It can produce the dishes, variations on them, and even things none of us thought to order. But it cannot tell the organization which one belongs on its menu. That still requires people who understand the problem, the people, the process, and the purpose, and who can exercise the judgment and taste necessary to recognize what deserves another course.

My wife may never remember exactly how many courses Charlie Trotter served that night. Seven, fifteen, or some number that has acquired a little family folklore over the years.

But she remembers the one or two dishes that stuck.

When you can taste almost everything, the valuable skill isn't simply being able to cook.

It's knowing what deserves another course.