When AI Starts Making Fire
I grew up learning to start a fire by stacking kindling just so, nursing a spark with careful breath. That was the old way—the interface was the fire itself. You had to understand the materials, the airflow, the sequence. Every step was visible, tactile, and slow.
Now, we have AI that can analyze a pile of damp wood, assess wind conditions, and tell you exactly where to place the tinder. Some systems can even control a robotic arm to build the fire for you. The interface is shrinking. Instead of learning firecraft, you just say, "Make me a fire that lasts through the night."
But here's the catch: the experience of firecraft isn't disappearing. It's moving underground, into the invisible rules that govern what the AI does before, during, and after the flame catches.
The Interface Thins: From Human Seeking Fire to AI Understanding Intent
Traditional firecraft was about human mastery. You learned the names of woods, the angles of the wind, the stages of a flame. You navigated a complex system of knowledge. The interface was thick—every piece of knowledge was a step you had to climb.
AI flips that. Now, the system tries to understand you first. You don't need to know that birch bark is better than pine needles; you just say, "I need a fire that won't smoke too much." The AI interprets, selects, and acts.
This shifts the design problem. It's no longer just about teaching the user the steps. It's about designing for intent—what the AI thinks you meant. The old cost was the effort of learning. The new cost is the cost of being misunderstood.
Experience Thickens: Fewer Pages, More Rules
It's tempting to think that fewer visible steps mean simpler design. But in firecraft, the complexity just moves into the system's behavior.
Take the command: "Handle the fire." Does the AI add a log? Adjust the airflow? Put it out entirely? Each choice has consequences. The real design questions are now:
- When should the AI act on its own, and when should it ask?
- What information must it show me while it works?
- How do I undo a mistake—like when it douses the embers I wanted to keep?
These rules aren't visible in a single screen. They live in the system's behavior, and they're what make the experience feel safe or chaotic.
From Usability to Delegability: Can You Trust It With Fire?
Usability used to mean: can you operate this thing? In firecraft, that meant knowing how to strike a flint or arrange a log cabin. But when AI acts for you, the question becomes: Can I trust it to do this without me?
I call this delegability. An AI might be brilliant at building a fire, but if you can't see what it's doing, if it might burn down the shed, you won't let it anywhere near your campsite. Smartness determines how far the AI could go. Design determines how far you let it go.
Sometimes the Right Move Is to Ask One More Question
In the old days, fewer steps meant better design. You wanted the shortest path to a roaring fire. But with AI, that's not always true.
Imagine you say, "Put out the fire." The AI could instantly douse it. Efficient, yes. But what if you meant "bank it for the night"? The cost of a wrong guess is high. So good AI design sometimes adds a step—a quick confirmation, a clarifying question—to buy certainty.
This is what I call boundary design: deciding what the AI can do, where it should stop, and when it must ask. As AI capabilities grow, the hard part isn't whether it can do something. It's whether it should.
Designing the AI's Behavior, Not Just the Interface
If old interface design was like arranging a campsite—placing the logs, the kindling, the fire pit—then AI experience design is more like directing an actor. You decide when the AI speaks, when it stays silent, when it suggests, when it acts, and when it steps back.
This is AI behavior design. It's not about what the AI looks like. It's about how it behaves in context. For firecraft, that means: Does it offer to adjust the airflow when the smoke gets heavy? Does it warn you before it adds a log that might cause a flare-up? Does it know when to just let the fire be?
Managing Expectations: Let the User Know What's Coming
With traditional firecraft, actions were predictable. If you add a log, you know roughly what happens. But an AI might take a series of steps—gathering wood, preparing kindling, setting up a windbreak—before you even see a flame. That uncertainty is uncomfortable.
Expectation design is about making the AI's intentions clear before it acts, and confirming what it did afterward. Not a constant narration, but enough to keep you oriented. If the AI is about to do something drastic, you should know in advance. If it just finished a subtle adjustment, you should be able to see that too.
Designing the Escape Hatch: Reversibility Beats Brilliance
Why are people hesitant to let AI handle a fire? It's not because the AI is dumb. It's because they don't know if they can undo a mistake. That's why reversibility matters more than raw intelligence.
In firecraft, that means: If the AI accidentally smothers the flame, can you bring it back? If it adds too much wood, can you remove some? If it starts a risky burn, can you stop it mid-action? These aren't flashy features, but they're what make an AI feel trustworthy. A good AI doesn't just do things—it lets you change your mind.
From UI Standards to Experience Governance
Companies used to focus on making their interfaces look consistent—matching colors, buttons, and layouts. That still matters. But with AI, a new kind of consistency is needed.
For firecraft tools, that might mean: Do all AI actions use the same confirmation system? Is there a clear boundary for what the AI can do without permission? What happens when the AI fails—is there a human override? Can you see a log of everything it did, and undo any step?
This is experience governance. It's about setting rules for how the AI should behave, not just how it looks. As AI gets more involved in physical tasks like firecraft, these rules become as important as any design system.
Design Value Moves, It Doesn't Vanish
AI will definitely eliminate some traditional design work. I'm not going to pretend otherwise. Standard layouts, repetitive visuals, basic prototypes—these are getting easier to automate. But that's not the interesting question.
The interesting question is: when production gets cheaper, what new experience problems appear?
In firecraft, the shift is clear: from pages to intent, from operations to behavior, from efficiency to boundaries, from usability to delegability, and from visual consistency to behavioral consistency. The core skill isn't making a prettier screen. It's turning powerful AI into something that feels clear, controllable, and worth trusting.
Conclusion: Shaping Trustworthy Intelligence
If you think of design as making things look good, AI is indeed eating that job. But if you think of design as deliberately shaping the relationship between people and systems, then AI is expanding the design space, not shrinking it.
We used to design how humans operate software. Now we design how software understands humans. Next, we'll design how humans and AI work together on real tasks—like building a fire that keeps a family warm all night.
The real design task isn't a button, a page, or a conversation. It's understanding, expectations, boundaries, action, feedback, escape hatches, and trust. The future of firecraft design isn't about simplifying complex skills into easy interfaces. It's about shaping powerful intelligence into something people can understand, control, and hand over their fire to.
Comments (0)
Please sign in to post a comment.
Don't have an account? Create one
No comments yet. Be the first to comment!