If code gets cheap, what gets precious?

Airspace, where I lead product, moves time-critical shipments, the kind where a delayed package can mean a delayed surgery. During the company’s Innovation Week, I built Relax, It’s Airspace in a few days: a quiet, generative way to feel one day of that shipping. Routes arc around a spinning globe, pickups and deliveries find their place in a generative ambient score, and a promise normally communicated with the language of intense urgency feels a little calmer.

In the same stretch I made a second concept for a conference booth: an experience that tracks a hand, mine or a passerby’s, and lets it pull a floating network of nodes and lines around the screen. Both were built by me, but neither was made from nowhere. Airspace’s data and APIs, the people who had built them, the design standards, and a body of prior work were all already there. The new thing was that I could connect those ingredients into a working experience much more quickly than I could have expected a few years ago.

I have always known just enough code to be dangerous. jQuery and Framer taught me how to make cute, videogame-style interactions. But I knew where my abilities ended. Earlier in my career I worked at an ad agency whose developers built exactly this kind of thing, the experiences that make people stop at a conference booth. Back then, either of these would have taken a team of two or three of them six months to build, and the result would not have been as good as what I made alone in a few days.

Then I opened a capable coding model and the distance between an instinct and a prototype suddenly got very short. It was legitimately mind-blowing. The connecting code had become cheap.

Cheap code is not the same as a good idea.

“Cheap code” can sound like a diminishment of coding. It is not. Code still carries systems, constraints, and hard-earned technical understanding. And in my case, much of the underlying technology and the assets that made these experiments possible had already been made by other people at Airspace.

What changed was the cost of testing a connection between those pieces. I could move from “I wonder if this could feel like this” to something a person could actually see, hear, and react to. I could make a small external application with our API instead of waiting for a large, expensive product change. I could bring customer collaborators along on the same day with a working prototype rather than a description of what we might build later.

That is a profound capability. It lets a team make an idea concrete soon after it has listened carefully enough to have a worthwhile hunch. But the qualifier matters: after it has listened.

A model can make something pretty before it knows what is interesting.

AI is very good at producing an appealing thing. Ask it to make something I will like and it may correctly notice that I like synthesizers, then give me patch cables and knobs. That can be fun. It can also be a parlor trick: a surface-level version of my taste, not a true expression of it.

The difference is not always easy to name. A portrait from my wife carries something a portrait assembled by a machine may not, in much the same way musicians hope a song made from their tastes and emotions can matter differently from one predicted from likely tokens in a data center. The line is extremely blurry. I do not think the useful distinction is simply human-made versus machine-made.

For me, an AI-assisted thing earns its place through care and specificity. Its reason to exist is more particular than a list of aesthetic preferences: someone has made choices because they understand the situation, the people in it, and the effect they are trying to create, and is willing to stand behind those choices.

In music, the obvious sound is rarely the final sound.

The score in Relax, It’s Airspace makes this clear to me. The first versions did not sound musical enough. Other iterations were too eager to announce themselves with a familiar snare. The model could help make the bleeps, bloops, and chords possible, but it did not know which of them felt too obvious, too generic, or no longer like me.

That took a history of design work, some musical understanding, and a willingness to keep listening. Each sound had to earn its place. The goal was not to make a technically impressive audio system. It was to make something that felt well produced and still carried the point of view of the person who made it.

I expect the same dynamic to play out beyond conference experiences. As more people can make software, the bottleneck shifts toward the hard-to-automate parts of product work: discerning a real signal from a loud request, understanding enough context to set a useful constraint, and caring about the difference between the first plausible answer and the one that truly fits.