Building Against the Defaults

Two moments today, in two different chats, made me notice the same pattern from different angles. Both involved AI tools doing something correct by default. Both required pushing back against that default to preserve product judgment. The pattern is starting to feel like a discipline, the kind of attention solo founders building with AI tools need to develop if they want their products to feel like more than the sum of their tooling.

This is a diagnosis day, not a resolution day. The hypothesis gets tested tomorrow. But the framing language is worth capturing while it is fresh.

Two badges, one collision

The first moment came during a routine schema and UI build for an admin dashboard. Status indicators for new records needed a color palette. The brief I had written specified a particular set of colors. The AI assistant building the dashboard paused before applying it.

There was an existing element nearby, the assistant noted, that already used one of the colors I had picked, and it used that color to signal a rare, high-attention state. If the new badge applied the same color in the same panel layout, the rare-state signal would dilute. Three options were surfaced with reasoning: change the rare-state element, change the new badge color, or accept the dilution and document the tradeoff.

I picked option two. The palette shifted. The rare-state color stayed reserved for the rare-state element. The dashboard shipped without visual collision.

What I noticed in retrospect: my brief had been correct in isolation and wrong in context. I had been thinking about the new element in a vacuum. The AI tool's job was to apply the brief, but it pushed back on the brief because the literal application would have produced the wrong outcome. The brief and the actual goal were almost imperceptibly different from each other, and I had missed the gap.

This is good tooling behavior. It is also a kind of attention solo founders need to be willing to receive. The instinct to override AI feedback ("just do what I asked") is a real failure mode. The opposite instinct, accepting AI feedback uncritically, is a different failure mode. The skill is hearing the pushback, evaluating it, and choosing the direction yourself.

A house style I didn't know I was inheriting

The second moment came later in the day, planning a design exploration session for tomorrow. I had been carrying around a vague feeling that my product's interface looked "AI templatey," the way you can sometimes tell from a glance that an app was generated more than crafted. I could not articulate what specifically was triggering the feeling. I just knew I had built it more than I felt I was supposed to feel like I had built it.

In the course of researching how to use a new design tool effectively, I came across a line in Anthropic's own prompting documentation describing the default visual style of the model that powers the tool. Warm cream backgrounds. Serif display type. Italic word accents. Terracotta and amber. The documentation explicitly noted this style "reads well for editorial, hospitality, and portfolio briefs."

That description is approximately what my product looks like.

I had not copied it. I had not been trying to land in any particular aesthetic. I had been using AI tools throughout the build, including some powered by this model, and the cumulative effect was that my product had drifted toward the model's defaults. Not because I picked them. Because every individual moment of using the tool had subtle gravity toward them.

The implication landed slowly. It is not that my product looks generic in some abstract sense. It looks like the documented default output of a specific AI model, and so does, presumably, every other product built with the same tooling that did not actively push against the default. The differentiation work that used to come from picking your own aesthetic is being pre-done by the model, identically, across the field.

This is a more specific kind of generic than I had been worrying about. It is also more solvable. The brief for tomorrow's design exploration is now: explicitly name what to avoid, push deliberately against the documented default style, and see whether the alternative directions feel like my product or whether the house style reasserts itself anyway.

The pattern: defaults compound

Looking at both moments together, the pattern is clear. Defaults are not neutral. They compound.

The first default was a brief I had written, correctly in isolation, that would have produced the wrong result in context. The second default was a model I had been using, whose subtle gravity had shaped my product toward an aesthetic shared by every other product built with the same tools. In both cases, applying the default literally would have produced something subtly off. Subtly off compounds. A dozen subtly-off decisions add up to a product that feels like it was built by someone who was not paying attention.

The skill, if I had to name it, is something like attention to the gap between what the tool will do and what the product should do. The tool defaults are designed to be reasonable on average, across many uses. Reasonable on average is rarely right for any specific case. The PM's job, in the AI tooling era, is partly the job of noticing where the tool's defaults don't quite match the product's actual needs and choosing the override deliberately.

This is not the same as distrusting the tool. The tool was right, on its own terms, in both cases. The badge color was the right choice in isolation. The warm cream aesthetic was the right default for the kind of product the model assumes you are building. The override is a different decision than acceptance or rejection. It is a decision about which goal the tool is being asked to serve.

What this means for solo founders

For solo founders building with AI tools, two things follow.

First, the homogenizing effect is real and worth taking seriously. Every founder I know building consumer products in 2026 is using some combination of the same handful of tools. Those tools have defaults. The defaults are being applied, identically, to every product where the founder did not actively push back. The result is a class of products that look like each other, sound like each other, and feel like each other, even when the founders building them have meaningfully different visions.

This is bad for differentiation in a winner-take-most market. It is worse than that, actually. It is a credibility tax. Users in 2026 can pattern-match the AI default aesthetic the way users in 2010 could pattern-match the Bootstrap aesthetic. Once they clock the pattern, the implicit message is that the product could have been built in an afternoon, and the implicit valuation of the experience drops accordingly.

Second, and more useful: the work of noticing defaults is becoming part of the PM job, not just the designer job. Or to put it another way, the PM job has always included this attention, but the surface area where it matters has expanded. Where you used to attend to copy, pricing, positioning, and feature scope, you now also attend to which AI tool is shaping which layer of your product, what its defaults are, and where those defaults need to be overridden.

The good news is that this work is teachable. Both of today's moments came down to the same operation: read the documentation, notice the default, decide whether the default fits, override deliberately when it does not. None of that requires deep technical sophistication. It requires the kind of attention that has been part of good PM work all along.

Mental Models

Three principles I am taking out of today, ordered by how durable they feel.

Defaults are decisions you didn't make. Every layer of an AI tool comes with assumptions baked in. Letting those assumptions ship into your product is a choice, even when you didn't notice you were making it. The first step toward differentiation is noticing what you're inheriting.

Pushback is a signal, not friction. When an AI tool pauses before applying your brief, that pause is signal. Most of the time it's catching something you missed. Sometimes it's wrong. The discipline is hearing it out and deciding, not waving it through or shutting it down.

Differentiation in the AI tooling era requires explicit anti-patterns. "Make this less generic" is not a brief. "Don't use these specific defaults that the model is going to want to apply" is. The work of naming what to avoid is the work the model can't do for you.

Tomorrow I test whether actively naming the anti-patterns produces meaningfully differentiated output. The diagnosis was today's work. The resolution arc is still being built.