Writing

I wanted to provide my perspective here based on the recent discourse around design as it relates to building software.

architects don't sketch free from physics then invite gravity later. they think through materials from the first line because they understand that the material is where truth lives. the sketch works because it's compressed material knowledge, not fantasy protected from reality. software should be the same. understanding the system deeply – the primitives, the data models, the capabilities – doesn't limit your imagination, it expands it. it shows you what's actually possible instead of what's merely conceivable.

"architects don't sketch free from physics then invite gravity later." Ah yes let me just design and build this cantilevered block of concrete suspended in mid-air one iteration at a time.

Different mediums surface different concerns.

With modern tools, coding lets us move faster and understand constraints sooner. That was true pre-AI, and it's more true now. Code gives form to reality. Those constraints don't suffocate creativity—they give it something to work with.

Before AI, I wasn't coding much. Now I ship and prototype with code almost every day. I can communicate intent faster, test ideas immediately, and see where I need to change course.

A huge part of this is working directly with models. Simply understanding what a model outputs and how to steer it opens up novel directions you wouldn't have arrived at from a spec or a diagram. The same can be true when sketching on paper. The difference is how reality responds.

Many of these ideas are grounded in the reality of the medium. They may not solve the core problem, but they serve as signal. They teach you something about the space. When you design a building, you always consider the site first.

What I've come to realize is that this creates a feeling of being close to the source. Working with code generates ideas you wouldn't have had otherwise.

As I've progressed in my craft, I've noticed that the more I work directly with a material—paper, code, clay—the more ideas emerge near the edges of its limitations. Once you understand the box, you can step outside of it more deliberately and see what happens. That's where things start to take shape in a way that reflects how you see the world and what you want to make. It builds momentum.

• Paper → you learn how pen or pencil meets the surface
• Clay → you feel how it yields and resists
• Code → you internalize its limits and affordances

I see building with code today as less about execution and more about thinking. By working directly with systems and models, you learn which directions are cheap or expensive, viable or fragile, beautiful or overdone. You uncover ideas you never would've designed up front, and you get unexpected outputs that may not directly solve the problem, but still teach you something important about it.

Anything that exists with intention — a building, a workflow, a product — operates. When the purpose is clear, the operating system underneath reveals itself.

In software, this is how we teach application: we expose the system through the medium that makes it legible. Sometimes that's a GUI. Sometimes it's voice. Sometimes it's something more ambient — sound, touch, the subtle feedback loops that signal state and direction.

But across every medium, one principle stays constant: you need to feel close to the source.

Designing well means standing at the edge of something alive. It's the sensation that the system has a pulse — that you can hear the forest breathing around you. When you're that close, you understand what must be built, how it should behave, and where it needs to evolve. You sense the architecture not as a blueprint, but as a living substrate ready to respond.

Great design comes from listening to that pulse.