Code Too Cheap to Meter

In 1954, Lewis Strauss, chairman of the Atomic Energy Commission, famously predicted that nuclear power would make electricity "too cheap to meter." Although it never happened, the phrase has remained for anything where the cost tends towards 0. We seem to be heading there for custom tools written by AI.

As LLMs become increasingly skilled at writing code, I see a flood starting. First, the people who just started coding or have always wanted to but never learned, jump in. You're telling me this computer is better than me at coding, and I can just ask for what I want in plain text? Then the junior engineers, the interns, they give in when they see a task done in 5 minutes that would've taken them hours. Over time, LLMs' coding will become the new norm. For many people, seeing Andrej Karpathy go all-in on vibe coding was the turning point. If someone as good as Andrej is giving in, am I too late to the party? Finally, the skeptics will see everyone around them moving faster, getting more done, and their hands will be forced.

But what about the lowly hardware engineer? We used to rely on software to build us tools, libraries, and drivers. Now we can just use English, breaking these dependencies. Not only that, but hardware engineers are starting to learn what's possible with software, and just how high-leverage it is. Recently, a colleague of mine wrote a full systems check of our robot. Whenever someone gave him a feature request, he simply requested it — feature creep is only limited by your imagination. Without the low-bandwidth bottleneck of a request from hardware to software, hardware engineers can move faster than ever, implementing things they wouldn't have even thought about when scoping the project.

A few months ago, I needed to calculate the deflection of a cantilevered beam with a complex loading pattern. The kind of problem that would normally require me to either dig through my old notes, fire up MATLAB, or just approximate it by doing some napkin math. Instead, I described the problem to Claude and, within minutes, had a working Python script that not only solved my specific case but also generated a visualization I could actually use to present to my team. The whole interaction took less time than it would have taken me to find my old textbook.

This is what I mean by disposable software. I didn't commit that script; I don't think I even saved it. If I need something similar again, I'll generate a new one. The economics of software have fundamentally changed, and I don't think we've fully internalized what that means.

Death of the General Purpose Tool

Think about how we use software today. We buy subscriptions to massive general-purpose applications, Microsoft Office, MATLAB, SolidWorks, and then we use maybe 10% of their features. We bend our workflows to fit the tool because the tool is expensive, and learning a new one is even more expensive; we compromise constantly.

But what if you could have a tool that does exactly what you need, nothing more, nothing less? Not a Swiss Army knife, but the perfect screwdriver for this particular screw. And when you're done, you throw it away and make a new one for the next screw.

This is already happening. I've watched my coworkers generate one-off data analysis scripts, custom file converters, and specialized calculators, all things that would have been "not worth the time" to build before. The threshold for "worth building" has collapsed from days to minutes.

What This Means for Engineers

As a mechanical engineer, I've spent countless hours wrestling with tools that were almost right. I once spent two weeks writing MATLAB scripts to analyze thermal expansion in a multi-material assembly. Today, I could describe that problem in plain English and have a working solution in an afternoon, with interactive visualizations, parameter sweeps, and Monte Carlo analysis for uncertainty quantification. Things I never would have attempted before because the activation energy was too high.

This isn't about replacing engineers. It's about removing the friction between having an idea and testing it. The bottleneck used to be implementation. Now the bottleneck is imagination. Every engineer can have their own personal army of specialized tools, perfectly tailored to their problems, generated on demand.

I think about all the calculations I've approximated because doing them properly would have taken too long. All the sensitivity analyses I skipped. All the visualizations I never made were because the effort-to-insight ratio was too low. That ratio just changed by orders of magnitude.

Information Wants to Be Free

Stewart Brand said "Information wants to be free" back in 1984. He was talking about the tension between the value of information and the decreasing cost of distributing it. But there's a corollary that's becoming apparent: computation wants to be free too.

For most of human history, if you wanted to simulate something, analyze data, or automate a calculation, you needed either expensive software licenses or the ability to write code. This created a massive barrier. An electrical engineer in Lagos and one in San Francisco had the same physics, but wildly different computational tools to study them.

That barrier is dissolving. Anyone with access to an AI assistant can now generate the tools they need. A high school student working on a science project can have the same quality of analysis tools as a PhD researcher. A small manufacturer in Vietnam can have custom quality control software that only a huge product design company might have. A farmer can have crop rotation optimization. The democratization of computation is happening faster than we realize.

Second Order Effects

It's not entirely obvious where this leads, or what the second-order effects of this may be - but I think we can make some predictions using some initial principles:

• There will be much tighter integration between hardware and software
• The cost of adding new features to software will drop to 0
• Code will become disposable

Software companies that sell general-purpose tools might be in trouble. Why pay for a subscription when you can generate what you need?

The skills that matter are changing. Writing code will become less important. Understanding what to build becomes more important as the ability to think at a higher level. The ability to clearly specify a problem, to know what good looks like, and to validate that a solution actually works are crucial skills.

I suspect we'll see an explosion of niche applications. Things that were never worth building because the market was too small, or it didn't make sense to pay someone to make it. A specialized calculator for a specific manufacturing process used by four companies worldwide. Custom simulation tools for obscure engineering domains. Software for problems we don't even have names for yet, and even one-off use cases.

And perhaps most interesting: What happens when everyone can automate their own workflows? When the friction of automation drops to zero, what does work look like? What do we spend our time on when the tedious parts evaporate?

The Optimistic View

I keep coming back to a simple thought: Tools make us more capable. Better tools make us even more capable. And infinitely customizable, instantly available tools make us capable of things we can't currently imagine.

The history of technology is the history of removing barriers. The printing press removed the barrier to distributing text. The internet removed the barrier to distributing information. AI coding assistants are removing the barrier to intelligence. Each time a barrier falls, we underestimate what the second-order effects are

I'm writing this using a tool that didn't exist a few years ago, running on infrastructure that would have been inconceivable a few decades ago. The tools I'll be using five years from now probably haven't been imagined yet, let alone built. But someone will describe them in plain English, and there they will be.