Cheap Code Changes Everything

AI didn’t invent the idea that code is a thinking tool. It just made it cheap enough that everyone can finally agree.

Phil Boyd recently wrote a piece called The Buffer We Accidentally Deleted (which I found via Dave Verwer’s excellent iOS Dev Weekly) that really resonated on a couple of levels. His argument is simple: AI made engineering roughly twice as fast, but the thinking work upstream didn’t speed up. Product thinking requires an incubation period that can’t be parallelized or A/B’d. The old timeline had slack baked in. The new timeline doesn’t because AI compresses the time it takes to build software to be much shorter than our ability to design it.

Every engineer should already know the incubation period that Phil is talking about. Countless times I’ve sat with a problem late at night, refusing to stop because I have to finish this while I still have the context loaded in my head. Burn three more hours only to crash, no closer to solving it. Wake up the next morning, sit down to code, answer hits me in five minutes.

But the problem remains the same. When work moves so fast that you need more time to direct it than it takes to produce it, you’ve destroyed the buffer that time spent building used to give you.

What this feels like on a real project

I’m living this on our current project, codenamed Argo. We’re a little over two months in, working in a space we’ve never operated in before. The domain requires substantial research; we couldn’t work off intuition because intuition either didn’t apply or would lead you precisely in the wrong direction. We didn’t just start at zero with no comps and no strategy; we started a step further back, at we first need to understand the space. Comps, tickets, functional specs are all still coming together.

But the engineering team wasn’t going to stop while we worked it out. They’ve been building POCs. Building basic features without final styling. Laying down architecture, tests, docs. As the product side of the work, this has created a permanent low-grade pressure — a feeling that we’re holding the engineers back, that we owe them a level of specification we don’t have and can’t manufacture by working harder.

That’s the compression Phil is pointing at, and it’s real.

Another way to look at the same shift

Phil’s two recommendations — engineers picking up the work we’ve always deferred (accessibility, performance, observability) and engineers moving upstream into product and research — are both spot on.

But there’s another lens on this same shift that I think is just as important.

It isn’t only that engineering is faster. It’s that code itself has gotten cheap enough to change what we use code for.

Working software has always been a better thinking tool than comps. You can stare at a Figma frame all day and miss what becomes obvious the moment you actually touch the thing — swipe it, tap it, feel how the interaction sits in context. Sometimes you take a good-on-paper idea to a prototype and just recoil. Oh no, that does not work. A lot of times you only know what needs to get better because you bump into the edge a few times while using it.

This isn’t a new idea. Smart small teams have always known it. Working software wasn’t a luxury — it was the actual point. The reason most teams didn’t operate this way wasn’t disagreement, it was economics. Code was expensive. You couldn’t afford to write a working prototype just to learn one thing. You had to be reasonably sure about what you were building before you started.

That’s the part that’s changed. Not the value of working software. The cost of producing it.

What that looks like in practice

On Argo, our entire first sprint of engineering POCs was intentionally throwaway. We weren’t building anything we planned to ship. We were investigating: how good is this text-to-speech engine for our use case? What can ARKit’s facial recognition actually do at the fidelity we need? The point was to push the limits of different APIs without worrying about UI or app architecture, then later fold the working technology into the real product once we knew what worked.

Our Director of UX has been doing the same thing in a different register — vibe-coding web POCs to test interface approaches. She’ll spin up a working prototype of an interaction model, get real feedback on real software (not on a static comp), and iterate. None of those POCs will ever ship. By the time we get to final comps, we’ve got a much more grounded approach, because the working software was cheap enough to be disposable but realistic enough to be valuable.

So while the obvious truth everyone is learning is “we can ship faster now”, the harder, more interesting move is we can use code to think. Because thinking through code now costs about what thinking through a comp used to cost.

Even if you already believed this, the magnitude is real

Even for those of us who’ve always preferred working software over comps and small senior teams over large process-heavy ones, the size of this cost change is hard to overstate. Tasks that used to be expensive — exploratory implementations, throwaway prototypes, “let me just try this” investigations — have become cheap. The frontier of what’s worth prototyping shifts dramatically when a working prototype costs hours instead of weeks.

I think this is something worth leaning into. And I feel like I’m still getting a feel for it. I talk a lot about the value of senior engineer intuition and rightfully so. But this is something I think we have to push against our experience. Places where you’d hesitate to “waste” engineering time trying something highly speculative or things that feel like too big of a lift to take on are now well within reach.

This is an invitation to embrace the joy of small teams, iterative development, and collaboration. Phil’s right that the buffer is gone. The exciting part is figuring out how to better deploy code as part of our thinking process. Instead of thinking ahead of coding we can think with, during and through coding.