The Discipline of Less: Mies Maxim & the AI Age

AI can build a lot of what we ask for. But can it help us ask for less?

Less is more. — Robert Browning, "Andrea del Sarto" (1855), later adopted as a guiding principle by Mies van der Rohe

I am a User Interface Architect, and I have a tendency to make things complicated. When looking at a defect or new feature, I want to solve every problem the first time. I keep trying to make the One True Design™ that will never need maintenance or updates so long as the physical constants of the universe don't change.

Over time, I have learned to limit myself. Sometimes we just need a first version. Sometimes the best design is the one that does exactly what is needed right now and nothing more. This principle is a constant struggle for me, and AI development can exacerbate that. I’ve seen this across vibe-coded and carefully-planned projects. And the realization that

The Discipline of Less

Ludwig Mies van der Rohe was a German-American architect who made "less is more" the core of his practice. Buildings like the Farnsworth House are minimal, but not empty. Mies removed elements that did not have a purpose, and what remained needed to provide both value and quality. When the view is the point, use a massive pane of glass rather than a window.

Mies philosophy was that reduction is a form of rigor, and every removal is the result of a decision about what really matters. When AI can build most anything we imagine, this discipline may be essential to building what we need.

Why AI makes this harder

With AI, building is nearly frictionless. A feature that once took days can be generated in minutes, and the cost of adding one more option, one more edge case, one more abstraction has dropped by orders of magnitude, even within the lifespan of LLM-powered development. The old friction that kept complexity in check is gone.

More salient, however, is that an AI will not ask us for justification of a feature. LLMs are sycophantic autocomplete engines, and are designed to give us what we ask for. If we start with an over-complicated concept, AI will do its best to justify our choices, because it is designed to do that for us.

That is why “Mies Maxim” matters more now: not "Can I build this with AI?" but "Does this need to exist?" Because if we fail to ask this question we can be assured that AI won’t push back on the instructions given.

Applying “Less is More” to AI Architecture

While the brainstorming process should have few boundaries, the transition from ideas to implementations needs to have a period of reflection and evaluation. I have some thoughts on how we might apply the Discipline of Less to our projects:

• Start with a purpose.
• Look for what already exists.
• Start simple; then iterate.
• Appreciate the pushback.
• Treat code as a liability.

Start with a purpose.

Describe the problem and the outcome we need before describing the features we could build. Use an interview process to get to the core of the design. I’ve experienced this misalignment in projects before. Knowing and sharing the goal can help keep you on target and avoid adding or removing the wrong pieces.

Look for what already exists.

Before creating something new, check if a solution exists. Is it close enough? Does it make sense to use that rather than to start fresh? If you can’t incorporate the solution, can you learn from the challenges it has already solved and have it inform your design?

Start simple; then iterate.

Avoid extras and support for cases we do not have yet. Creating a product is a good first step. Then you can add features as they become necessary. This continues to be hard for me…as we start to build I can envision the areas where we might need special solutions. And

Appreciate the push back.

Instruct the LLM to challenge requests, identify unnecessary parts, and propose the smallest version that meets the goal. Maybe even ask it to interview for the justification of a feature. Even when AI can build our whims, we need to put in the mental effort to be in control of our projects.

Just like in real life we sometimes need to be told our idea is too complicated or has issues. The justifications you make can become documentation that helps ensure those concerns and foundations continue to be part of the design and development process.

Treat code as a liability.

Code must be loaded, validated, tested and secured, even when it is unnecessary. Removing the unnecessary makes for a better product and reduces future maintenance costs. And committing -2000 lines of code just feels good, even if AI is doing the reduction.

The test

Before we accept AI output, we can use the Discipline of Less and imagine Mies asking us, “What is left if we take this away?” If the answer is that the product still works and the user is still served, maybe we don’t need it.

AI can help us build faster, but it can also add value if we use it to enforce discipline and make us justify our decisions. Just as AI can run review and analysis of the code, we can use the tools to instill within ourselves and our processes the discipline to build less.

(AI disclosure: The initial draft was written by me, a real human person, then restructured by AI to help shift the message, and then substantially re-written by me, again.)