AI Writes the Code. Who Writes the Taste?

TL;DR:

Can AI Actually Build a Good App?

No. It can build a functional one.

I watched a demo recently where someone built a working iOS app in twelve minutes using an AI coding assistant. It had a tab bar, a list view, a detail screen, networking, and even Core Data persistence. Twelve minutes. The code compiled and ran.

I should have been impressed. Instead, I felt uneasy. Not because the technology was threatening, but because the app was mediocre. It worked. It did what it was told. But it had no opinion, no point of view, no taste.

Nobody had asked the most important question: should this app exist?

According to Gartner, 75% of enterprise software engineers will use AI code assistants by 2028. A GitHub survey found that 92% of U.S.-based developers already use AI coding tools in some capacity. The question is no longer whether teams will adopt AI for code generation. The question is whether they understand what AI cannot generate.

What Is "Taste" in Software, and Why Does It Matter?

Taste is the skill that separates functional software from software people love.

There's a concept in Japanese craft called me-kiki, which roughly translates to "the discerning eye." It describes the ability to look at a piece of pottery and know, before any analysis, whether it's good. Not technically correct, not well-executed, but good. It's the sense that tells a woodworker when to stop sanding, that the grain is right, that adding more would subtract from the whole.

Software has its own version of this. It's the instinct that tells you a feature doesn't belong, even if users requested it. The feeling that the onboarding flow has one too many steps. The judgment call that says an animation should be 250 milliseconds, not 200, not 300, and not because you A/B tested it but because it feels right at 250.

This is what I mean by taste. And it's the one thing AI can't generate.

Consider the evidence: a McKinsey study found that AI tools can accelerate code generation tasks by up to 35-45%, but the same research noted no measurable improvement in code quality, architecture decisions, or user experience outcomes. Speed went up. Judgment stayed flat.

What Is AI Actually Good At in Software Development?

The mechanical parts. And those parts matter.

I use AI coding tools daily. I'm not a skeptic. They're genuinely useful for:

These are real time savings. I estimate AI tools save me three to five hours a week on work that used to feel like busywork. According to Stack Overflow's 2024 Developer Survey, 76% of developers report using or planning to use AI tools, and the most common use case is writing code (83%), followed by debugging (49%).

But here's what I've noticed. The time I save on mechanical coding doesn't go toward writing more code. It goes toward thinking. I spend more time sketching architectures on paper. More time looking at the app from the user's perspective. More time asking whether what I'm building is the right thing, not just whether it's built right.

AI has freed me from some of the labor of making. And in doing so, it's clarified what the labor was never about. If your team needs help making this shift from AI-assisted coding to AI-assisted thinking, our product discovery process is designed to surface the right questions before any code gets written.

Why Does Removing Friction Sometimes Make Software Worse?

Because productive friction is where better designs emerge.

There's an idea in craft theory that the act of making is not separate from the act of thinking. When a potter works clay on the wheel, the clay pushes back. It resists, wobbles, collapses. And in responding to that resistance, the potter discovers what the piece wants to become.

Programming has always worked this way. You start with an idea, write some code, and the code pushes back. The compiler complains. The layout breaks on small screens. The state management gets tangled. In solving those problems, you often discover a better design than the one you started with.

When AI generates code that "just works," it removes that friction. The code doesn't push back because it was generated to satisfy a prompt, not to emerge from a conversation between the maker and the material. The result is code that does what you asked but rarely surprises you with something better than what you imagined.

A 2024 study by GitClear analyzing 153 million lines of code found that code churn (code rewritten within two weeks of being authored) increased by 39% in projects heavily using AI assistants. Code was being generated faster, but it was also being thrown away faster. More output, less durability.

The answer isn't to reject AI tools. The answer is to understand what friction is productive and what friction is noise:

How Wide Will the Taste Gap Get?

Much wider than most people expect.

Here's a prediction I'll stand behind: as AI makes it trivial to build software, the gap between good products and bad products will widen, not narrow. Because the bottleneck was never the building. The bottleneck was always the deciding.

Right now, a talented engineer and a mediocre one are separated by how well they write code, how efficiently they solve problems, how clean their architecture is. AI narrows that gap dramatically. A mediocre engineer with good AI tools can produce technically competent code.

But the gap in taste remains. The ability to know what to build, when to stop, what to leave out, how something should feel. That gap will become the defining difference. According to a Forrester report, while generative AI can increase developer output, organizations that focus exclusively on speed without investing in design judgment see 2.5x higher rates of feature abandonment. Users don't want more features. They want better ones.

Apple's approach to iOS development illustrates this. Their Human Interface Guidelines aren't a technical specification. They're a taste document. They describe how things should feel, not just how they should function. Every decision about haptic feedback timing, animation curves, and spacing values reflects accumulated judgment that no prompt can reproduce. Our team applies these same principles across iOS engineering projects and performance optimization work.

How Do You Develop Taste as a Developer?

Through exposure, creation, study, and honest reflection. There are no shortcuts.

Exposure: Use a lot of software. Notice what feels good and what feels off. Ask yourself why. Study the products you admire, not just their features but their restraint, the things they chose not to do. According to Nielsen Norman Group research, users perceive aesthetically pleasing designs as more usable, even when objective usability metrics are identical. Taste has measurable UX consequences.

Creation: Build things and ship them. Live with your decisions. Feel the pain when something you built frustrates users. Feel the satisfaction when something you agonized over turns out to be exactly right. If you're evaluating a development partner, ask how they handle the hard decisions. Our technical due diligence process is specifically designed to surface where taste was present and where it was absent.

Study: Read about other crafts. I've learned more about software design from books about architecture, typography, and cooking than from most programming books. The principles of proportion, rhythm, economy, and surprise are universal. They show up in a well-set page, a well-balanced recipe, and a well-designed app in exactly the same way.

Reflection: Pay attention to the moments when you disagree with data. Sometimes A/B tests tell you that version B converts better, but something in you resists. That resistance is worth examining. Sometimes it's just ego. But sometimes it's taste telling you something a conversion metric can't capture, something about coherence, about brand, about the kind of product you want to exist in the world.

Should AI Handle the Clay While We Keep Our Hands on the Wheel?

Yes. That's exactly the right model.

AI gives us extraordinary new materials to work with. Like any material, the interesting question isn't what it can do. It's what we choose to do with it.

The potter who lets the machine make all the bowls ends up with a lot of bowls and no craft. The potter who uses the machine to prepare the clay but shapes it by hand ends up with something richer than either could produce alone.

That's where we're headed. AI handles the clay preparation. We keep our hands on the wheel. The taste, the judgment, the discerning eye, those stay with us. Not because AI couldn't theoretically develop them someday, but because developing them ourselves is the whole point.

The code was never the craft. The decisions were.

If your team is building an iOS product and you want a partner who understands that distinction, Luma Commons brings the taste, the technical depth, and the product thinking that AI alone can't provide.

Frequently Asked Questions

Can AI replace human judgment in software design?

Not in any meaningful way. AI excels at generating code that satisfies explicit requirements, but software design judgment depends on implicit knowledge: understanding user psychology, brand coherence, market positioning, and the accumulated experience of having shipped products and lived with the consequences. A Harvard Business Review analysis found that AI tools are most effective when paired with experienced practitioners who can evaluate and direct the output, not when used as autonomous decision-makers.

How much time do AI coding tools actually save?

Industry data varies, but most practitioners report 20-40% time savings on mechanical coding tasks. GitHub's internal research on Copilot showed developers completed tasks 55% faster with AI assistance. However, time saved on code generation typically shifts toward design, architecture, and product decisions rather than producing more code output. The net effect is better software, not just more software.

What's the difference between code quality and product taste?

Code quality is measurable: test coverage, cyclomatic complexity, performance benchmarks, adherence to style guides. Product taste is about the decisions that sit above the code. Which features exist and which don't. How transitions feel. Whether the app respects the user's time. You can have perfect code quality and zero taste. The best products have both.

How should engineering teams integrate AI tools without losing craft?

Establish clear boundaries. Use AI for pattern-based tasks (scaffolding, boilerplate, test generation, documentation) and preserve human decision-making for architecture, UX, and feature scoping. Run regular design reviews where the question isn't "does this work?" but "is this right?" And invest in developing taste across your team through critique sessions, cross-disciplinary study, and exposure to excellent products outside your category.

Is taste subjective or can it be measured?

Both. Taste includes subjective aesthetic judgment, but its effects are measurable. Products built with strong taste show higher retention rates, better NPS scores, and lower support ticket volumes. The subjective judgment produces objective outcomes. That's why treating taste as a "nice to have" is a strategic mistake.