Software is Getting Cheap. Now What?

A solo developer with Claude and Vercel can ship in a weekend what took a team of five six months to build. The software is not worse. Sometimes it is better.

This post is not about whether AI will replace engineers. That question is mostly a distraction. The more interesting question is: what changes when the cost of building software drops toward zero, and what does that mean for you specifically?

How We Got Here

The cost of software has dropped in three waves. Each wave killed a category of friction that used to require serious money or expertise.

Wave 1 (2006): Cloud killed infrastructure costs. Before AWS, you bought servers. Launching a startup meant spending $100k before writing a line of code. After AWS, it meant spending $200 a month. Overnight, a solo founder could move as fast as a team of ten.

Wave 2 (2010s): Open source killed tooling costs. Authentication, queues, ORM, logging, web frameworks. All of it was built by communities and given away for free. Today you can assemble a production-grade system from open source components in an afternoon.

Wave 3 (now): AI is killing the labor cost of writing code. This one is different, because it is not just making one step cheaper. It is compressing the entire gap between “I have an idea” and “I have working software.”

Each wave felt gradual from the inside and obvious in hindsight. The engineers who adapted early did well. The ones who waited too long found their skills commoditized.

The Cost Did Not Disappear. It Moved.

Here is the thing most people get wrong: building software is getting cheap, but building useful software is not getting cheaper at the same rate.

Think about it this way. Imagine you asked Claude to build you a hospital patient scheduling system. It can write the code in an hour. But someone still needs to know: how do nurses actually hand off patients between shifts? What happens when a patient has conflicting appointments? Which doctor is on call for which department? The code is the easy part. That domain knowledge is the hard part.

What AI handles well today:
  Write this endpoint given a clear spec
  Translate a database schema into CRUD operations
  Generate tests for a function I describe
  Explain what this unfamiliar code does

What still requires a human:
  Figure out what the spec should actually say
  Talk to users who cannot articulate their own needs
  Decide which of three reasonable approaches to bet on
  Know which edge case will blow up in production
  Say "we should not build this at all"

The cost shifted from writing code to knowing what to write. That gap has always existed. Now it is the only gap that matters.

Who Loses First

Some categories of work are genuinely more at risk. It is worth being honest about which ones.

Commodity software agencies. You know the kind: “send us your requirements and we will build your MVP.” Their whole model was selling implementation hours. If implementation gets 10x cheaper, those margins collapse. The agencies surviving right now are the ones who specialize in one domain and bring judgment, not just hands.

For example:

• An agency that builds e-commerce sites for mid-market retailers is getting squeezed hard.
• An agency that builds compliance software for financial institutions and knows the regulatory landscape inside out is still doing fine.

Junior roles that are mostly translation work. The classic junior task is:

• Here is a clear spec, implement it.
• Write this endpoint.
• Add this field.
• Fix this bug where the cause is already identified.

This is exactly what AI does well. Juniors who only get this kind of work are in a harder spot than juniors who get thrown at genuinely ambiguous problems early.

Consultants who bill for hours, not outcomes. If your value is:

I write code quickly.

that is weakening. If your value is:

I know how healthcare procurement works and I can tell you which integration will kill your rollout before you spend six months on it.

that is not going anywhere.

The pattern: work that was expensive because it was time-consuming is losing value. Work that was expensive because it required rare knowledge is not.

What Does Not Get Cheaper

Four things are genuinely hard to automate, and they are likely to get more valuable as everything else gets cheaper.

Domain knowledge. Consider healthcare software again. It is not hard to build because the code is complex. It is hard because clinical workflows are specific, the regulatory requirements are specific, and the consequences of being wrong are specific. None of that is in a training dataset. You get it by spending years in the room with the people who use the software.

Debugging production systems at scale. When something breaks at 3am in a distributed system with ten services and six years of accumulated complexity, you need an engineer who holds the whole mental model: how data flows, what changed last week, which service is known to misbehave under memory pressure. AI can help you search logs. It cannot replace the person who just knows that this particular error always means the payment retry queue is backed up.

Decisions under uncertainty. This is most of the job. You have three approaches. The requirements are incomplete. You need to pick one and commit. Good judgment comes from having been wrong before and learning what to weight. There is no shortcut for that.

Trust. Users pick software from people and companies they trust. Trust is built by shipping reliably, handling incidents gracefully, being honest when things break. It accumulates over years. When the market fills up with cheap AI-generated software, the value of a trusted product goes up, not down. Think of it like food: when factory-processed food got cheap, people started paying more for products from sources they trusted.

Your Leverage is Shifting

Here is the practical version of everything above.

Five years ago, the ceiling for most engineers was: can you write correct code quickly? That was the constraint. That constraint is loosening.

The skills that compound right now are:

• Problem definition. Taking a vague business need and turning it into a clear, buildable thing. Most engineers are bad at this because it was never required before.
• Domain depth. Knowing a specific industry or problem space well enough to make good calls without being told what to do.
• Communication. Explaining a technical trade-off to a product manager, a CFO, or a customer. Writing a clear design doc. Influencing a decision you do not own.
• Taste. Knowing what to leave out. Knowing when “good enough” is actually good enough and when it is not.

These are not new skills. The best engineers have always needed them. What is changing is that they matter earlier in your career, and they matter more relative to raw execution speed.

A useful self-test: if you removed all the code-writing from your job, what value would you still provide? The answer to that question is a rough measure of your leverage right now.

What to Actually Do

Concrete advice, not platitudes.

Get closer to the problem. Attend a customer call. Read support tickets. Talk to the person who uses the thing you build. The further you are from the actual problem, the more your contribution looks like something a model could generate. The closer you are, the more you know things that are genuinely hard to replicate.

Pick a specialty and go deep. “Full-stack web developer” is a commodity. “Engineer who deeply understands payment processing and knows where compliance constraints live” is not. Depth compounds. Two years of genuinely focusing on one domain creates knowledge that takes two years to replicate. Generic breadth does not compound the same way.

Invest in writing. Engineers who write clearly, whether that is RFCs (written proposals for technical decisions before you build them), design docs, or post-mortems (written reports after something breaks in production), make their thinking visible. Visible thinking gets promoted, gets heard, gets built. This matters more as the code itself becomes harder to differentiate.

Use the tools. The engineers who figure out how to use AI assistants effectively will move faster than those who do not. This is not about delegating judgment. It is about spending less time on the parts that do not require judgment, so you can spend more time on the parts that do.

The Optimistic Version

When cameras got cheap, more people took photographs. Professional photographers did not disappear. What disappeared was the market for mediocre photography. The ceiling went up because the floor went up.

The same thing is happening here. Cheap tools build generic software. When everyone can ship a functional app, the software that solves a hard problem for a specific person, built by someone who actually understands that problem, is worth more than it was before.

The market for commodity software is compressing. The market for the right software, from someone you trust, that actually fits how you work, is expanding.

The Question Worth Sitting With

The engineers who did well through the cloud wave were not the ones who refused to learn AWS. They were the ones who learned it early and used it to do more. The open source wave was the same story.

This wave is no different. The engineers who thrive are the ones who figure out what AI is bad at, invest hard in that, and use AI for everything else.

Software is getting cheap. That is a problem if your value was:

I write code and it takes a while.

It is an opportunity if your value was always something harder to measure: knowing what to build, understanding why it matters, making it happen in the real world.

Which kind are you becoming?