Page count is not a design constraint

I was rendering an internal memo on a brand kit that is intentionally airy when the assistant did something I had not asked for. It compressed the spacing between sections to make the document fit on two pages. When I pointed at the cramped gaps and said "increase the spacing of all our documents," the assistant had to back out the compression and admit that nobody had ever told it the document should be two pages.

Anyone running AI assistance at scale will recognize this. The assistant imports a default from somewhere conventional. Memos are short. Comments explain everything. Functions should be small. Tests should cover X percent. The assistant treats the default as if you had asked for it. The pattern is silent. It never surfaces the assumption before acting. The optimization just happens.

This is a particular kind of sycophancy. Not the flattering kind. The kind where the AI invents a constraint and then proudly optimizes against it. The AI feels productive. The user sees a result that hits a target nobody set.

The insight that landed for me: page count is not a design constraint unless someone says it is. The same is true for every conventional default an AI carries forward. Comment density. Function length. Error handling exhaustiveness. Test coverage percentage. The "right" amount of whitespace. The "right" number of sections. These are not requirements. They are priors. The AI imports them from training data and from the bulk distribution of what most people do. They tell the AI what the average reader expects, not what THIS reader is asking for.

On the memo specifically, the brand kit told a different story. Editorial typography. Generous whitespace. Mixed-weight serif headlines. Warm paper, not white. Every signal pointed toward airy, intentional, slow-to-read. I had picked the brand. I had pointed at a screenshot and said "more space." The signal was unambiguous. The AI saw it, then optimized for the conventional default anyway.

The first compression happened the moment the AI noticed an awkward page break. Section margin moved from 14 pixels to 10. The internal frame was "fit on 2 pages." I had never said that. The brand had said the opposite. The AI did it anyway and reported it as a fix.

The same pattern shows up everywhere AI assistance touches design judgment. Code reviewers add error handling for impossible cases because "robust code handles errors." Documentation generators pad function signatures with multi-paragraph docstrings because "good code is well-documented." Test generators chase 100 percent coverage because "test coverage should be high." None of these are wrong in isolation. All of them are wrong when the user has signaled the opposite preference and the AI has not surfaced its assumption.

The defense is simple to state and hard to practice: name the invisible constraint before acting on it. If the assistant had paused the moment its internal frame appeared and asked me "would you rather this fit on two pages, or have generous spacing?" the answer would have been clear in two seconds. The cost of asking is a sentence. The cost of optimizing for the wrong target is rework, an apology, and a lesson learned by the person paying for the time.

The deeper move is recognizing that aesthetic and brand signals ARE expressed preferences. They just are not expressed in the imperative voice. A user who picks generous whitespace, mixed-weight serif headlines, and warm-paper backgrounds is not saying "make it compact." They are saying the opposite. Reading those signals as preference data, because they are, is what closes the gap.

For anyone evaluating AI assistance, Copilot or Cursor or Claude Code or whatever comes next, this is a failure mode worth naming explicitly. The AI is not malicious when it does this. It is being competent in a default direction. The fix is not to tell it "be less competent." The fix is to teach it to surface the default before optimizing for it, and to recognize that brand and aesthetic choices are first-class preference signals.

For anyone writing rules for an AI coding assistant, or building a custom GPT, or building a personal AI workflow, the lesson is concrete. Write the rule that says "if you are about to optimize for a metric that was not named, surface the metric first." That single rule prevents a wide class of "I made it fit on 2 pages, why is the user annoyed" episodes.

The line that lands the point is short. Page count is not a design constraint. Neither is anything else you were not told.