0:00
/
0:00
Transcript

Brutalist.art - The "Beautiful.ai" that Educators Need

Talking to a slide deck through Claude code

The Slide Deck You Built Was Not for the Learner

It Was for You

There is a lie at the center of most educational content production, and it goes mostly unnamed because naming it is professionally uncomfortable. The lie is this: the slide deck you built last Tuesday, the one you spent three hours arranging, the one with the custom fonts and the carefully chosen images and the thirty-seven bullets across fourteen slides — that deck was not built for the people who had to sit through it. It was built for you. It was built so you could feel the relief of having covered the material. It was built so the topic had a container. It was built because you had a deadline and a template and a vague professional obligation to produce something, and a slide deck is always something.

The learner — the specific human being with specific prior knowledge and a specific amount of time and a specific gap between what they currently understand and what they need to understand — that person never really entered the room where the deck was being built. What entered the room instead was a topic. And a topic is not a person.

Brutalist was built to address this. Not to address it gently, with suggestions and style guides and best-practice checklists. To address it structurally, in the architecture of the tool itself, before a single slide gets made.

The Architecture of Avoidance

The conventional workflow for building educational content runs roughly like this: you receive a topic (or assign yourself one), you collect material — readings, notes, data, existing slides — and you begin arranging it. If you are experienced, you arrange it with craft. You think about sequence and pacing. You choose examples. You know when to deploy a metaphor and when to let a statistic land without ornamentation. The result, at its best, is a coherent and well-paced presentation of material.

What you have not done — and this is the gap that produces most failures in educational content — is started from what the learner will be able to do when you are finished with them. You have started from what you know, and you have worked forward through that knowledge toward a clean ending. This is a completely understandable approach, and it produces content that would be unrecognizable as failing by any ordinary standard of review. It is organized. It is clear. It covers the material.

It just doesn’t reliably produce learning.

Backwards design — the pedagogical framework that governs every output Brutalist produces — insists on reversing this sequence. You begin with a measurable outcome: not a topic, not a list of things the instructor will present, but a single sentence describing what a learner will be able to do at the end that they could not do at the beginning. Construct a DAG from domain knowledge and identify all backdoor paths. Distinguish between a learning outcome and a topic. Evaluate a rubric for the difference between qualitative descriptions and observable behaviors. These are not aspirations. They are commitments — to a learner, to a measurable change, to the possibility of knowing whether the teaching worked.

The reason most content production doesn’t begin here is not ignorance. Most instructors know what backwards design is. The reason is that starting from a learning outcome is harder than starting from a topic, and the tools available for producing educational content — PowerPoint, Keynote, Google Slides — offer no friction whatsoever against starting from the wrong place. They are indifferent to the question of who the learner is and what the learner needs to be able to do. They are happy to help you arrange forty slides around a topic, and they will never once ask whether the arrangement serves a learner or just a speaker.

Brutalist asks. It asks before it produces anything. In interactive mode — the default — it will not generate a single slide until it has confirmed the audience, confirmed the outcome, and confirmed that the outcome is measurable. “Understand X” is not measurable. Brutalist says so, explicitly, in the voice of a pedagogical skeptic rather than a customer-service chatbot. That describes a mental state, not a behavior. A learner can’t demonstrate ‘understanding.’ What’s the one thing they should be able to do? This is not rudeness. It is the one question that changes the output.

The Phase Gate as Moral Commitment

There is a design decision embedded in Brutalist that deserves more attention than it usually gets in conversations about AI tools, which tend to focus on capability rather than constraint. That decision is the phase gate.

A phase gate is exactly what it sounds like: a gate that holds until a phase is complete. In Brutalist, the first gate holds at source confirmation — no output until the source material is present. The second holds at outcome identification — no output until the outcome can be stated in one sentence. The third holds at form confirmation — no output until the right command for the content is confirmed. Only then does the tool produce anything.

This is unusual. Most AI tools are designed to produce output as quickly as possible, because output is what users think they want and user satisfaction is what tools are optimized for. The experience of receiving forty slides in thirty seconds feels like productivity. It feels like the machine is working for you. What it actually is, much of the time, is the machine generating plausible-looking content that fills the form without serving the function — decoration rather than argument, coverage rather than learning.

Brutalist is optimized for the learner, not the user. These are not the same person. The user is the instructor who wants a slide deck. The learner is the person who will sit in front of that deck and try to change what they understand. Optimizing for the user produces faster output. Optimizing for the learner produces harder questions before any output is generated at all.

The phase gate is where this optimization manifests in the tool’s behavior. It is the structural embodiment of a moral position: that output built on wrong assumptions about audience or outcome wastes more time than the intake that would have caught those assumptions. Two minutes of friction before the deck is built is less costly than an hour of instruction that doesn’t change what anyone understands.

What “Understand X” Is Actually Doing

Spend any time in educational settings — as a student, as an instructor, as a curriculum designer — and you develop a particular sensitivity to the phrase “by the end of this, students will understand X.” It appears in syllabi, in lesson plans, in course descriptions, in accreditation documents. It appears so frequently and so unexamined that most people who write it have stopped noticing it at all. It is pedagogical wallpaper.

But the phrase is doing something specific, and it is worth naming. “Students will understand X” is a sentence that sounds like a learning outcome and functions as an escape from accountability. Understanding is a mental state. You cannot observe it, you cannot measure it, you cannot score it on a rubric or assess it in a portfolio. You can ask someone to demonstrate understanding — which means you are no longer assessing understanding, you are assessing a behavior — but the phrase as written commits you to nothing. It is a promise with no deliverable attached.

The reason this matters to a tool like Brutalist is that the learning outcome is not just the first step in backwards design. It is the specification for everything that follows. The slides that get built, the visual types that get selected, the checks for understanding that get inserted every four to six slides — these are all derived from the outcome, working backward from what the learner needs to be able to do. If the outcome is vague, the derivation has nothing to anchor to. The result is a deck that covers material in the general direction of a topic, which is not the same thing as a deck that moves a specific learner from a specific gap to a specific capability.

This is why Brutalist treats “understand X” not as a minor stylistic imprecision but as a structural failure that must be corrected before building anything. The outcome is the foundation. A vague foundation does not produce a stable structure. It produces decoration.

Brutalist HTML and the Question of Deployment

There is a second commitment embedded in this tool that is worth examining, and it lives in the signature output: the brutalist HTML presentation. Not a PowerPoint file. Not a PDF. A single self-contained HTML file, deployable immediately, built on a design system called Musinique brutalist — JetBrains Mono, parchment tokens, per-slide audio, keyboard navigation, zero decorative radius.

The choice of HTML as the primary output format is not aesthetic. It is pedagogical and practical simultaneously. A PowerPoint file requires PowerPoint. A Google Slides file requires Google. An HTML file requires a browser, which is to say it requires nothing — it deploys anywhere, runs without software dependencies, and can be shared as a URL or a file with equal ease. The friction of tool access is a real barrier to distribution, and distribution is where educational content either serves learners or stops serving them.

The design choices embedded in the brutalist system — every slide does one thing, every title is a claim not a topic, components are typed by what they communicate rather than how they look — these are cognitive load principles encoded as aesthetic constraints. The slide with a hero number and a two-line muted caption exists because research on split attention and redundancy effects has things to say about how visual and verbal information compete for working memory. The check for understanding every four to six slides exists because spaced retrieval practice produces stronger retention than massed coverage. The design is not decoration. It is applied cognitive science, translated into a component library and a phase-gated workflow.

The Pushback Layer

Brutalist pushes back. This is the part of the tool that most users encounter with some surprise, because tools — especially AI tools — are generally not in the business of disagreement. They are in the business of helpfulness, and helpfulness has been operationally defined as producing what the user asks for as quickly as possible. Friction is a UX failure. Pushback is an anomaly.

In Brutalist, pushback is a feature. Not an accident of the model’s personality or a quirk of the prompting, but a designed behavior with specific triggers and specific exit conditions. Weak learning outcomes get flagged — not once, politely, but persistently, with an offer to rewrite the outcome if the user fails the measurability test twice. Vague audience descriptions get challenged, because “college students” is not an audience and the specificity that changes the content, examples, and pacing cannot be inferred from it. Mismatched command choices get named — if the content calls for a /showtell and the user has requested /slides, the tool explains the difference in instructional design terms before proceeding.

Every pushback ends with a path forward. This is the moral discipline that separates useful friction from obstruction. The tool is not in the business of refusing to build. It is in the business of building toward the right specification, and the right specification cannot be assumed from the wrong brief. The pushback is the tool asking the question that the instructor should have asked before they opened a blank deck and started arranging.

What is the learner supposed to be able to do?

Everything else follows from that.


Brutalist is part of the Humanitarians AI Ecosystem. The primary workflow: /slides produces the blueprint. /brutalist converts it to HTML. /deck does both in one command. Type help to begin.

Tags: Brutalist instructional design engine, backwards design pedagogy, learning outcomes Bloom’s taxonomy, brutalist HTML presentation system, educational content production failure

Discussion about this video

User's avatar

Ready for more?