The fear: LLMs will do everything. There won’t be any need for anyone to ever write a new product again! The world will be ruled by bespoke software products written by every Tom, Dick and Harry with a laptop! R.I.P. Good Times!

Wow. Just wow.

Relax folks. Deep breath. Step back from the ledge.

Yes, our world is changing but the need for software development doesn’t end here. First things first, the act of software development is the act of describing a product in unambiguous detail*. Most people can’t do this. Being extremely detail oriented is a trait found in few professions, software development being one of them.

Second, while LLMs may be able to write code, they can’t invent the idea out of thin air. That still comes from you. You, dear software developer, still need to own the initiative and still need to own the outcome. You need to make sure you get what you asked for. And guess what? Verifying that takes extreme focus on detail.

Third, Jevons Paradox states that when a technology makes a resource more efficient, the total consumption of that resource often increases rather than decreases. Applied to software: will we get the same code with far fewer developers, or far more code with the same or more developers?

Now, Jevons describes consumption, not employment — cheaper coal didn’t save coal miners. But software’s bottleneck has never been typing. It’s judgment: knowing what to build, describing it precisely, verifying it works. LLMs accelerate the typing, not the judgment. So when typing gets cheaper, judgment becomes the constraint — and that’s what developers do.

Let’s be clear, none of this means what counts as economically viable software won’t change and change drastically. Before the web, the norm was apps that ran on your computer and didn’t talk to anything else. Many of them made great money. After the web, that model was generally unviable — the winners were apps built around communication and connection.

The availability of LLMs will also change this. Apps that used to be economically viable will no longer be so. But that’s a far cry from no software will ever be economically viable again.

We already have hints. The pattern: “LLMs do reasoning. Apps do execution.”

How do we know this? Because the business model requires it. Each of the LLM purveyors makes their money by selling tokens. Anything deterministic, anything involving execution, does not sell tokens. So they specifically defined the method by which we call external systems to circumvent this problem. This is admitting, straight up, that Claude, ChatGPT, and Gemini won’t do everything and won’t try. It’s not an accident; it’s admitting to their business model.

We’ve seen this pattern throughout software’s history. There is a long history of dominant platform companies choosing to partner with liability-heavy and customer-specific companies rather than develop their own, especially when orthogonal to their own business models.

• AWS could have built payment processing. They didn’t and deferred to Stripe. PCI compliance, chargeback liability, and regulatory exposure are all things a general-purpose platform doesn’t want.
• Salesforce easily could have absorbed DocuSign but instead chose to partner. E-signatures require ESIGN Act compliance, evidentiary burden and jurisdiction-specific legal exposure.
• Microsoft, which owns business communication, could have bought Twilio but telecom regulatory compliance is a specialty and the company didn’t want the burden.
• Google, organizers of the world’s information, could have purchased Plaid, the owner of massive amounts of financial data. Financial data aggregation carries bank and compliance obligations orthogonal to Google’s business model, though.

You might reasonably ask: doesn’t this change now that AI makes building these things cheap? No. The build cost was never the hard part. The liability was, and liability doesn’t get cheaper because code gets cheaper. A Claude-generated payment processor still needs PCI compliance, chargeback infrastructure, and a legal team. The partnerships are durable because the regulatory moat is durable.

I believe the same will be true here – and full disclosure, I’m betting on it. TrueMath is designed to guarantee mathematical execution for regulated and high stakes businesses. LLMs reason, TrueMath executes. That’s the partnership.

—
* I love this definition. Thanks, Kevlin Henney and John Siracusa!

Over the past few years I’ve had the opportunity to observe a lot of AI-assisted software development. In my experience there was a clear shift in November 2025 when Claude Opus 4.5 launched. What we can trust AI systems to do changed materially.

While I have a day job managing a few teams and little opportunity to write code there, I do spend a lot of time observing and talking with my team about how they use LLMs in the development process. It’s been fascinating watching each person adopt this technology at their own pace.

To stay current, I write a lot of code on TrueMath in my evenings and weekends. This post outlines what has changed in my development process—and what has not—in my 40 years of writing software.

Before Claude Opus 4.5

I started developing with ChatGPT in early 2024. Of course compared to today’s models it was very primitive and often wrong. Nonetheless, I found a pattern that worked:

1. Start with a general prompt about the structure of the project and copy into ChatGPT the code it needs to start.
2. Work together on a plan. Go back and forth as long as necessary to make sure we are aligned and all corner cases are covered at a high level. Copy that plan off to Asana (which I use for task management).
3. Have it tackle each phase, writing code in ChatGPT. Sometimes we needed to break the current phase into sub-phases. I reviewed every line of code as I copied it into the code base, copying code back to ChatGPT so it could review what I did.
4. Review every test it writes, run them, and also test every phase or sub-phase manually.

As the project grew I found myself copying more and more code into the prompt. Eventually the model would start struggling earlier and earlier in the development cycle as we ran past the context window.

After Claude Opus 4.5

When the reviews of Claude Opus came out, I started thinking more and more about bringing Claude into VSCode and let it do more. I was seeing the efficiency gains from those at my day job who were embracing new approaches. We had seminars from leading companies in the space walking us through how to use their systems.

Time for a change! So just a couple of weeks ago I got around to installing Claude Code in VSCode and signing up for an account. Now my process looks like this:

1. I use CLAUDE.md to define the project overview and actually have Claude updating and maintaining it.
2. I start any body of work with Claude in plan mode and we work back and forth on the plan until I’m happy with it. This includes breaking it down into small phases of work. Every phase should be small enough for me to review and manually test.
3. Once I have a plan I like and broken down, I copy it off to Asana (which is what I use for tasks but even a text file will do) and have Claude save it to memory.
4. For each phase of work I start a new chat and try hard to keep the context from overflowing and needing to condense. If I need to break down the task further so it is reviewable I do that as sub-phases.
5. I tell Claude to write the code, during which I watch its thinking mode and often multitask on something else.
6. When done I review the code. I run the automated test suite, which it should have just done. I review the code coverage metrics. I review all the code. I manually test. If there is any code smell, any code I can’t really follow easily, any code that looks duplicative, I just point it out to Claude and ask it if this is the best way to do this. It usually says it can do better and does.
7. I work back and forth with Claude on any issues until complete, at which point I have it update its memory, save to my branch, and move on to the next chunk or sub-chunk.

In short, exactly as before except almost no copy and paste.

I never let Claude do anything destructive, especially data migrations. It prepares the code commit but I’m the one who hits the button. It’s my safety valve to make sure I’m properly testing.

How We Wrote Code Before LLMs

How I use Claude now isn’t that different from how I have written code for 40 years. Back then, though, I did all the planning myself and wrote every line of code. Now, I work with Claude to plan and have it write the code. Every other step in this process is still me.

Efficiency Gains

I’m working on a capability right now that would have taken me 3–4 weeks full-time to build by hand. With Claude Code it took 2–3 days. (Note to my boss: it actually took longer since I’m only working evenings and weekends on TrueMath.)

This is incredible efficiency gains! I’ll be honest: I feel like I’ve been given a super power using AI for software development. Before, there were many things I would have never taken on. Now, any idea I have can be realized in working code.

That’s a remarkable shift in what an individual developer can accomplish.

We’ve seen wave after wave of layoffs across the tech industry over the last two years. In many cases, the explanation is some variation of the same theme: AI-driven efficiency.

That’s an interesting claim because if you look closely, most AI systems today are not autonomous execution engines. They are advisory tools. They draft, summarize, analyze, and suggest. They do not reliably replace mission-critical human judgment at scale.

So what’s really happening?

I’ve learned over time that when something doesn’t quite add up, it helps to follow the incentives.

For over a decade, capital was cheap, growth was rewarded more than efficiency, and hiring was aggressive. If you weren’t hiring, you weren’t competing. So tech companies hired. Amazon doubled its workforce, Meta grew more than 90%, Google 60% and Microsoft over 50%. That’s a lot of new employees!

By 2023, the party was over. Rates rose, capital tightened and efficiency became fashionable again. Suddenly, boards wanted operating leverage instead of growth stories. That shift alone explains a large percentage of what we’re seeing. It doesn’t require a technological revolution to explain a financial correction.

But “we overhired during an unprecedented zero-rate environment” is a backward-looking narrative. It admits miscalculation.

Leadership, though, is about crafting a path for the future. “AI is increasing productivity, and we are restructuring for the future” is a forward-looking narrative. It signals modernization. It suggests discipline. It aligns with the dominant technological theme of the moment.

Which story do you think markets prefer?

This doesn’t require conspiracy thinking. It’s basic incentive alignment.

Public companies are rewarded for telling coherent future stories. Investors want to believe that cost reductions are strategic, not corrective. Executives are incentivized to frame change as transformation, not retrenchment. AI provides a very convenient language for that transformation.

Now, to be clear: AI absolutely increases productivity. Small teams can accomplish more than they could five years ago. I do believe certain roles will shrink and some workflows will disappear.

But that is different from saying AI is broadly replacing people today.

Most current systems are still human-in-the-loop. The reality is that AI is probabilistic by design and needs human guardrails and supervision. They need deterministic tooling to keep them operating reliably. They are powerful tools, just not autonomous departments.

If layoffs were primarily driven by AI capability, we would expect to see large-scale removal of execution-heavy, deterministic roles. That is not what we’re seeing. What we’re seeing looks much more like normalization after a decade of expansion. After all, only 8% of new roles added during the pandemic have been downsized at the largest tech firms.

Incentives matter. The AI narrative is compelling because it is forward-facing. It suggests inevitability. It frames reductions as technological progress rather than capital misallocation. If you are leading one of these companies, how would you position these layoffs? The same way.

This doesn’t mean leaders are being dishonest. It means leaders are rational actors responding to markets, boards, and macroeconomic conditions.

AI is real. Productivity gains are real. But we should be careful not to confuse narrative alignment with technological causation.

Not every layoff in the AI era is caused by AI.

Sometimes it’s just math.

When I started developing software, the operating system handed off control to an application, the application did its thing, and when done, handed back control to the operating system. These early systems were largely single-application and linear. Control flow was simple and direct. The operating system had very little involvement with the running application.

The rise of graphical user interfaces brought the next major paradigm mainstream. Instead of the operating system handing off control, it actually owned control, sending it temporarily to the application. The application and operating system worked in cooperation. For instance, if you wanted to print, the application would call the operating system and tell it what to print and the operating system would handle it from there. This is called event-driven programming.

This was the standard for desktop and mobile operating systems. When web development became popular, client-server also became popular and hit massive scale. In this model, the application would do some work, need some information, and request it from the server. The server would do its thing and send back a response with whatever was requested. Meanwhile, generally nothing was stopping the application from doing other things while it was waiting.

In each of these models, a human did something and the software reacted to it. The user would click a button and the application and operating system or application and server would do something on their behalf. This is human-in-the-middle. A human is involved in the process.

This is mostly how things worked until the early 2000s. When I started my first company, I remember investors saying selling to software developers was one of the worst markets you could ever choose. This was a group of people who could write stuff on their own and all acted as individual purchasers. Very hard! And many companies died trying.

In the late 2000s and early 2010s, this started to shift. Part of this was the rise of microservices where we could break control of the application into many different servers with each doing one specific task. And another was the rise of mobile and modern, very complex operating systems. As a developer, there was too much to know and it became feasible and desirable to outsource some capabilities to other software applications and services. We had mashups, where we’d use, say, Google Maps in our own applications.

In the 2010s a few new companies were founded to build services explicitly for other software. Stripe, payment processing, and Twilio, messaging and communication, were two such companies. Both are still staples in software development circles. Why build your own payment processing software with all the compliance and reporting requirements when we can pay 2.9% and $0.30 per transaction, and work with a company that focused on making it brain-dead simple to integrate?

This is the start of the inflection point. For the first time we have software built primarily for other software to call, with no humans involved. That’s software-in-the-middle. That shift is about to accelerate dramatically with AI, LLMs, and agents.

For decades, software was built primarily for humans. We clicked buttons. We filled out forms. We triggered workflows.

Stripe and Twilio changed that. They weren’t built for humans to use directly. They were built for software to call. Clean APIs, clear contracts, and simple integrations.

That pattern is about to dominate.

AI, LLMs, and agents don’t just assist humans; they consume APIs, call services, and orchestrate workflows. The next generation of software development won’t just build applications for users; it will build systems designed to be used by other systems.

Software enabling software. Software-in-the-middle.

I didn’t get bad code because an LLM can’t write software. I got bad code because I gave it too much freedom.

I was working on a new feature for TrueMath this past week. I’d already written it before, but it lived behind an admin wall, and I wanted to elevate it for customers. The change came with some structural overhead, but at its core this was mostly a lift-and-shift exercise.

So I started a session with my trusty LLM, fed it a bunch of code, and said, “Here’s the basic structure, here’s what I did before—write this in the new style.”

The original code was about 2,000 lines. The LLM wrote 4,000 lines and still wasn’t done. And the code was spaghetti. There is no way I could have supported that long-term.

After a few days, I stopped writing code, started a new chat with the same LLM, and changed my instructions. This time I explicitly told it to lift and shift within the new structure and to write as little new code as possible.

It nailed the core in a single response. The rest took me a couple of days to finish up. The result? Clean, easy to update—and about 2,200 lines of code. Perfect.

One of the beautiful things about using an LLM to write software is that there’s a clear way to check whether what it did was correct. We run code through a compiler. We inspect outputs. We write automated tests and run them again and again.

Most things we ask LLMs to do don’t work like that.

We ask it to do research, and unless we double-check everything, we have no idea whether it made parts of it up. We ask it to draft legal documents without knowing whether it missed important laws in our jurisdiction.

We ask it to do math.

Did it use the right formulas?
Did it use the right data?
Did it make assumptions it never told us about?

Software gives us compilers, tests, and repeatability. Other domains—research, law, and especially math—don’t. Until they do, we’re still guessing. Just faster.