If AI’s design output keeps failing the fundamentals, the obvious fix is to teach it the fundamentals. Write them down. Package them as instructions the model has to follow every time it generates — hierarchy, contrast, balance, proximity, rhythm — with examples, templates and rules for when each applies. People have done this. I’ve built a few such systems myself, with nested files and reference templates and careful checklists. They help. They also break, and the more elaborate they get, the more reliably they break. The surface reason The first explanation is mechanical. A model working through long, layered instructions doesn’t reliably attend to all of them. It weighs, compresses and skips what it judges unnecessary. You can read that charitably, as a system trying not to spend your time and money on what doesn’t matter, or less charitably, as a system doing the minimum. Either way, the parts it skips are rarely the parts you’d have chosen. But I don’t want to rest anything on that, because it’s an engineering problem, and engineering problems get solved. If long instructions were the only obstacle, the right move would be to wait a year. The deeper reason The harder problem is that the fundamentals don’t survive being written down. They’re principles, and a principle only means something once it’s applied to a particular thing. Take balance. I can define it. I can describe symmetrical and asymmetrical balance, visual weight, the relationship between mass and space. None of that tells you what to do with a specific palette, in a specific brand, where two of the colors fight whenever they sit near each other and balance is the only thing that lets them coexist. There, balance is an effect you produce by moving something, looking, and moving it again until the tension resolves. The principle is the same everywhere. What it asks of you is different every time. That’s the difference between a principle and an instruction. A sourdough recipe tells you to let the dough rise for four hours. A baker who understands yeast knows it will be ready sooner in a warm kitchen and later in a cold one, and checks the dough with a finger rather than the clock. The recipe is written for an average kitchen; the baker is working in this one. A skill file is a recipe. The fundamentals are knowing what yeast does. Michael Polanyi named this sixty years ago. The Tacit Dimension opens from “the fact that we can know more than we can tell.” Machines have found one way around Polanyi’s problem: they learn from examples instead of rules, which is how they became so good at recognizing faces. It’s also how they learned design — from millions of examples of the web, which is why they learned its average. What they can’t absorb that way is your judgment about this palette and this purpose, and the usual way to hand that over is to write it down. A skill can only contain what can be told. The standard and the eye This needs one distinction, because I argued recently that a brand standard can and should be written down precisely enough for a machine to apply. I still think so. A type scale, a spacing system, a set of color values — those are specifications, and specifications travel. What doesn’t travel is the judgment that produced them, or the judgment you need to look at something built from them and see what’s wrong. You can hand a model the rules. You can’t hand it the eye that made them. It’s tempting to conclude that the machine simply can’t see. That isn’t accurate anymore in any simple sense; current models take images as direct input. Whether what they do amounts to seeing, in the way I mean it, I honestly can’t say. But I’m not sure perception was ever the point. Beethoven’s hearing began to fail in his late twenties, and by about 1818 he was profoundly deaf, holding his conversations through written notebooks. It was in those years that he wrote the Ninth Symphony and the late quartets. He could compose without hearing because he had spent decades listening, long enough to carry a working model of what sound would do. The judgment was built through the sense, and then it outlived it. That’s what the fundamentals are in a designer who has them: a model of consequences, assembled from thousands of acts of looking, each one tied to a purpose. It lives in someone who has done the looking, and nowhere else. Where to invest So the most useful thing a designer can do now is also the least fashionable. Go back to the fundamentals. Study them until you can apply them, then until you can see them — in your own work, in other people’s, in whatever a model hands you. Build the habit of naming what’s wrong and why. Maybe someone will write the skill that finally holds all of it. People have tried, and I’ve used their skills as well as my own. They don’t really work, at least not in the way that matters. They shape the output, but not in a way that relieves anyone of the need to review it critically. A good designer looks at what comes back and knows immediately where it needs to change. For the time being, I’m betting against any skill that claims to take care of the fundamentals, because the fundamentals aren’t a script. A machine can compile, read, synthesize and generate faster than the human mind ever will; that much is true. But in this particular way, the slower mind is still the better one. Speed counts for a great deal, though not for everything.