Coherence Is the Bottleneck

The hardest part of AI-assisted building was keeping the work coherent.

Making things got strange quickly. A screen could appear. A function could appear. A content model could appear. A test could appear. A respectable little draft of almost anything could arrive before I had fully decided what standard it should be held to.

Visual consistency mattered, but I mean coherence in a bigger sense: product intent, system behavior, evidence, language, constraints, and human judgment all pointing in the same direction after the tools had generated a dozen new artifacts that looked confident enough to be mistaken for decisions.

A generated screen can decide what entities exist. A generated function can decide what state matters. A generated content object can decide which user problem is primary. A generated schema can decide what the product is allowed to remember. A generated workflow can decide when a human gets asked for judgment.

Sometimes those decisions are useful. Sometimes they are just defaults with better posture.

The risky part is that they do not always look like decisions. They look like reasonable filler. A status value. A placeholder role. A clean abstraction. A demo state. A helper function. A table name. A line of copy that sounds right until someone asks whether the product actually behaves that way.

Hidden decisions start living inside the product this way.

The problems I ran into were usually small and specific.

Invented entities. Fake completeness. Abstractions that sounded right but did not map to the product. Demo states mistaken for product logic. Old decisions repeated because they were present in the wrong context. Agents extending a concept no one had actually agreed was correct.

None of that feels catastrophic in the moment. It feels like normal product fuzziness. Then the fuzziness compounds.

A card refers to a workflow that does not exist. A spec assumes a review gate that never got designed. A prototype treats a temporary reset state as if it were a real user path. A model reuses yesterday's terminology because yesterday's document was easier to find than today's source-of-truth note.

The dangerous version is a product that feels coherent only because the prose is smooth.

Spec-driven coding helped me slow the system down enough to see what it was doing.

A good spec can name the goal, the constraints, the data objects, the edge cases, the acceptance criteria, and the review gate before the code starts moving. That matters. It gives the tool something sturdier than vibes. It also gives the human a place to notice when the product logic is undercooked.

But a spec is not magic. It can still smuggle in a bad assumption. It can be too broad. It can preserve an old decision because nobody remembered to remove it. It can describe a workflow beautifully and still fail to say what happens when the user does not trust the output.

The best specs I wrote started to look less like handoff documents and more like small operating agreements. Here is the noun we are using. Here is the fake demo state we are not allowed to confuse with product logic. Here is the query parameter that only exists for testing. Here is the review gate that has to stay human. Here is the thing the system should not infer, even if it can produce a very plausible guess.

The spec helps. The judgment still has to be there.

The word guardrail can sound grand. In practice, the useful ones are often plain.

A glossary that says what a thing is called and what it is not called. A schema that uses nouns the user would recognize. Source-of-truth docs with timestamps and owners. Eval loops that check whether the product still behaves the way the team says it behaves. Review gates before consequential actions. Changelogs that make drift visible. Source checks that answer where a claim came from. Routines that catch stale assumptions before they spread.

None of this is glamorous in the portfolio sense. A glossary will not make a dramatic hero image. A changelog rarely gets applause.

But these are the pieces that keep generated work from becoming a pile of plausible fragments.

I used to think of maintenance as the boring part after the work.

I do not think that anymore. In AI-assisted systems, maintenance is how the work stays true.

The product changes. The docs drift. The model remembers an older shape. The prototype keeps a fake state because it was useful for a demo. The team changes a term in a meeting and forgets to change it in the prompt, the schema, the onboarding copy, and the eval rubric.

Maintenance is the discipline that catches those gaps before they become product behavior.

Maintenance is one of the ways the real work remains real.

The design work changed for me when I spent less time making pictures of the product and more time pressure-testing the product itself.

That shift had a cost. Some visual work would have been stronger with more dedicated Figma time. There are screens I would still like to make quieter, sharper, more composed. I do not want to pretend that moving closer to behavior automatically makes every visual decision better.

But the legibility was real. Working prototypes showed where the interaction collapsed. Live data showed where the story got too neat. Non-deterministic screens showed where confidence, uncertainty, and recovery had to be designed as first-class product states. Evals showed where a flow looked reasonable until the system had to explain itself.

A static mock can show intention. A working artifact can reveal behavior.

Design keeps intent legible as it moves through product, code, data, docs, agents, and people.

That makes the designer's job more editorial and more systemic. What belongs? What is a duplicate? What is a temporary demo shortcut? What does this term mean in the user's world? What evidence does this claim need? What should the system be allowed to do without review? What should it never do without a human stopping to think?

Designers do not need to become more technical for the sake of it. We need to help the product keep its meaning as more of the work becomes generated, summarized, retrieved, and acted on by tools.

Someone still has to notice when the thing sounds right but does not belong.

One person can hold a lot of context for a while. Many teams run on that. It works until it does not.

AI-assisted work makes that failure arrive faster. More artifacts exist. More drafts circulate. More agents can act from partial context. More polished output can be produced from stale assumptions. The team can look productive while slowly losing the thread.

Coherence cannot live only in one person's head. It has to live in the system: the glossary, the schema, the product principles, the critique routine, the source-backed docs, the eval loop, the review gate, the changelog, the boring little places where current understanding gets recorded and corrected.

The product keeps its shape when those records move as fast as the work does.

I am skeptical of any AI workflow that celebrates generation and treats maintenance as an afterthought.

More output is not automatically more progress. More artifacts can mean more ways to forget what the team actually decided. More screens can mean more places for fake logic to hide. More summaries can mean more confidence attached to context nobody checked.

The goal is to make sure what gets generated still belongs to the product, the user, and the decision the team is actually trying to improve.

When generation gets cheap, coherence becomes the work. It makes the real design work harder to ignore.