$

$ teds read --post what-ai-builders-can-learn-from-painters

What AI Builders Can Learn from Painters

A practical essay on why models are colors, not masterpieces, and why AI products need composition, constraints, technique, and taste.

What AI Builders Can Learn from Painters

TL;DR

  • Models are colors. The product is the painting.
  • More tools do not create better work by themselves.
  • AI builders need composition, constraints, technique, and taste.
  • The masterpiece is not the model. It is the solved problem.

Abstract

Generative AI gives builders a huge palette.

Text models. Image models. Vision-language models. Embeddings. RAG. Agents. Fine-tuning. Quantization. Tool use. Multimodal inputs. Synthetic data.

The palette is impressive.

But a palette is not a painting.

Good AI products do not come from using every color. They come from choosing what belongs, what does not, where attention should go, and what the user should be able to do when the work is done.

This post uses the painter analogy to make a simple product point: models are materials. The product is the composition.

Table of Contents

  • The Palette Problem
  • Why Raw Capability Is Not Enough
  • Composition as Problem Framing
  • Technique as Engineering
  • Taste as Product Judgment
  • Builder Checklist
  • Summary
  • Next Steps

The Palette Problem

AI builders are surrounded by options.

There is always a new model, framework, benchmark, inference trick, agent pattern, or multimodal demo. Each one adds a new color to the palette.

That abundance creates a subtle problem: teams mistake options for direction.

They ask:

What can we build with this model?

The better question is:

What problem deserves this much machinery?

Painters do not use every color because it is available. They choose. They leave things out. They create contrast. They decide where the viewer should look.

AI builders need the same discipline.

Why Raw Capability Is Not Enough

More colors do not make better art.

More models do not make better products.

A large model can produce fluent text and still be wrong for the workflow. A vision-language model can describe an image and still fail the user’s decision. A RAG system can cite sources and still retrieve the wrong ones. An agent can take actions and still lack a reason to exist.

Capability matters. But capability without composition becomes noise.

This is the core argument behind generative AI is not the product. The model is a material. The product is the useful system built around it.

Composition As Problem Framing

Composition starts with deciding what the work is about.

For AI products, that means problem framing.

Ask:

  • Who is this for?
  • What pain are we reducing?
  • What belongs in the workflow?
  • What should be left out?
  • Where should the user’s attention go?
  • What should happen when the model is wrong?

Without composition, AI products sprawl.

They become assistants that can do everything badly, dashboards with chat boxes, agents with unclear authority, or demos with no durable workflow.

Strong composition narrows the system. It makes the product easier to explain, evaluate, and trust.

Technique As Engineering

Technique is the craft underneath the visible work.

In AI products, technique includes:

  • model choice
  • prompting
  • retrieval
  • data preparation
  • fine-tuning
  • evaluation
  • UX
  • monitoring
  • deployment
  • safety review

Good technique should make the final product feel simpler, not more complicated.

The user does not need to see every layer. But the layers need to be there when the product depends on them.

A painter may understand pigment, light, surface, and brushwork. A viewer may simply feel that the image holds together.

An AI builder may understand eval sets, retrieval quality, latency budgets, and failure modes. A user may simply feel that the product helps.

Taste As Product Judgment

Taste is the ability to notice what is wrong before users have to suffer through it.

In AI work, taste means being intolerant of:

  • vague product promises
  • magical demos with no evaluation
  • outputs users cannot verify
  • features that exist only because the model can do them
  • workflows that hide uncertainty
  • content that explains less than it claims

Taste is not decoration. It is judgment.

It tells you to cut the feature that makes the demo flashier but the product weaker. It tells you to narrow the audience. It tells you to show failure modes. It tells you to use rules instead of an LLM when rules are enough.

This is also why technical content is a product surface. Explanation reveals taste. If you cannot explain the product clearly, the product may not be clear yet.

Builder Checklist

Before building, ask:

What Is The Canvas?

What workflow, environment, or user surface will this live inside?

Who Is It For?

Which user has the pain, and what do they already know?

What Should The User Do?

What decision, action, or artifact should become easier?

What Should Be Removed?

Which features, claims, or model capabilities do not serve the user?

What Can Fail?

Where can the model, data, retrieval, UX, or expectation break?

What Must Be Explained?

What does the user need to understand before trusting the system?

We help teams turn AI palettes into working systems. The work is choosing what belongs and making it hold together.

Summary

AI gives builders more colors than ever.

That does not remove the need for composition. It increases it. The best AI products are not the ones with the most capability. They are the ones where the capability serves a clear problem.

The masterpiece is not the model. It is the solved problem.

Next Steps

Take one AI product idea and remove three things:

  • one feature
  • one claim
  • one technical flourish

If the product becomes clearer, you are closer to the real shape.

Need help turning an AI idea into a working system? We build, break, and explain AI. Then we hand it back working.