pah.moi ·

Software Logic Implementation Is a Commodity

taggedLLMAIdevelopmentcodingagentharness

I have spent a lot of time over the last two years testing different techniques for LLM-driven development. Certainly thousands of hours; some of it was wasted on code that never went anywhere.

But the world is in quite an amazing place right now, where a functional 500-line Python script that parses and re-encodes a pile of files to make your entire day more efficient can be generated by a current cheap Flash-tier model in about two seconds, if you know how to ask for it. It is shocking to compare this to a few years ago.

This has significant implications when its potential is scaled up to the level of professional software development. Software logic implementation has become a commodity. The expensive part of software was never the logic; it was the specification, the operational ownership, and the accumulated organizational knowledge of why the thing works the way it does. Those are now the only parts you are actually paying for. If you can define what you want, you can have it built. The question that follows is which of your vendors are selling you the commodity part. Experience suggests that the implementation of software logic is now a commodity that can be purchased in dozens of different places.

Two years in

I was very dismissive of LLM potential prior to two years ago, having done development work since I was a child; surely the robot is not any good at this... but it is inescapable. Most people have gone through some version of this acceptance, at various speeds.

Phase 1 - Testing the waters

This was enough to bring a few products to prototype and launch at least one in production.

Phase 2 - Development of architecture

I got real refinement and product work out of this level. The tension was that automating context management reduced what I had to think about per prompt while inflating the total volume of context moving through the system. Phase 1 taught me to optimize context by hand; Phase 2 optimized it for me and then buried the savings under overhead.

The tools also had no memory between sessions, which meant every hard-won piece of project knowledge had to be re-derived or re-fed. That did not get solved until Phase 3, and it got solved by writing things down rather than by any tooling improvement - which turned out to matter more than I understood at the time.

I was mainly using a large-context Pro-tier model throughout phases 1 and 2, aside from experimentation with other vendors. I feel like this model holds up better than I expected in raw contexts against the tools I use today. This suggests to me that improvements are really more from harness design than from raw model capability, which is a somewhat inconvenient thing to believe if you are waiting for the next release to solve your problems.

Phase 3 - Autonomy

This phase brings rapid development of competent products. I have sent a lot of things to production since then, after making so many prototypes that halted before becoming truly worthwhile.

Attributing acceleration

I am going to make up some numbers here to use as an estimation going forward.

Phase 3 feels roughly three times as productive as Phase 2, which felt roughly twice as productive as Phase 1. That compounds to something like 6x. But multiplying two 'feelings' together is just a claim that is probably in the order of magnitude of correct. The interesting part is that the difference between Phase 3 and Phase 1 is larger than the difference between no tooling and Phase 1.

One objection to this: a METR randomized trial found experienced developers measurably slower using chat-assistance coding tools on mature codebases they already maintained, while estimating afterward that they had been faster. That is Phase 1 tooling applied to the hardest case. The speedup I am claiming comes from the move from Phase 1 to Phase 3, on greenfield creation and brownfield reproduction. But also consider that if handing an expert raw model access makes them slower, then the model might not be the variable. Perhaps it is the governance and the harness around the model.

A second objection: generation got 6x cheaper, but what do we lose? The results are not 6x better. Whether or not the results are as good, but faster is an unanswered question for which I do not have any real data. I would say that it feels like it is the case with current tooling. But I do know that assessment of quality and output did not scale in a linear manner alongside generation. One still has to read the AppSec findings, decide whether the test coverage means anything, and make a decision. If you triple the volume of code entering review and review capacity stays flat, you have not built a faster pipeline: you have built a longer queue with the same bottleneck at the end of it.

My answer to this objection is only partial. You were always supposed to be doing this testing and seeing the same bottleneck, which means you can make things worse by sending more down the pipeline. But parts of the review do get automated, where an LLM-coding agent can just as easily automate scanning, linting, test generation, property-based testing, security tool integration, and so on. What did not get cheaper is the senior person deciding whether a design is right, or what the risk parameters are for security decisions. So the throughput gain is real but it is not always uniform. It is large for greenfield work with well-understood requirements, but has to shrink where humans become more involved.

Abstraction, and where it stops

From Phase 1 to Phase 3, the use of the tools became more and more abstract. Phase 1 was writing code with help. Phase 3 is writing constraints and receiving code.

Abstract things last longest. Consider how the Unix philosophy shows up in how its toolset operates: one task per simple program, output portably piped elsewhere. At maximum abstraction, grep does a very specific thing as a program for searching text that matches a regular expression, and that description has outlived nearly every program ever written to consume its output.

Hand that abstraction to a coding harness and it might recreate grep. Get more concrete with project requirements and security parameters and it certainly will, without you learning any C.

But grep is the easiest case anyone could pick. It is a pure function. It is completely specified, publicly, across forty years of documentation. It has no users with opinions, no compliance surface, and no integration with a payroll system nobody remembers commissioning.

So take a middle case instead. An internal approvals tool: a form, a routing rule, a handful of roles, an audit log, email notifications, one integration with the HR directory. Real business logic in a couple dozen rules, all of which somebody in the building can (hopefully) still articulate out loud. That is the case I actually care about, and I think it now takes days or weeks rather than quarters based on my experiences when working on greenfield creation or brownfield reproduction. This is not because of superintelligent LLM models, whatever people might be marketing, but because the entire difficulty of that application is business logic a human already knows and can write down. The opportunity is the easy conversion of business logic into software.

"But the specification is the program"

If reproducing software requires a complete specification via architecture, ADRs, UI/UX, business rules, then writing that specification is roughly as hard as writing the software, because a sufficiently precise specification is the software. That has been the standard response since Brooks, and I do not think it has ever been refuted.

Brooks split software difficulty into the essential complexity (inherent to the problem) and the accidental complexity (of expressing a solution in a given language, on given hardware, with given tools). His claim was that no tooling improvement would help much, because the accidental part was already small.

The accidental part is tremendously complicated again. Framework churn, dependency management, build systems, the seven ways to configure the same deployment, glue code between services that should never have been separate services. None of that is essential complexity. All of it eats engineering time. LLM tooling is very good at exactly that layer and mediocre at the essential one, which explains both why the speedup is real and why it is bounded.

So the objection is correct and the conclusion still does not follow. Writing a complete spec is as hard as writing software. But you are not writing it from nothing. You are writing down what the organization already decided, most of which exists in somebody's head, a documentation page, and a decade of tickets. Or perhaps you can extract what is desired from the head of a particular executive. That work is transcription and reconciliation, not invention. It is difficult, and can be political, but ultimately, transcription is a different task than construction, with different challenges.

Reproducibility

The most important part of AI-driven software development is no longer knowing about malloc vulnerabilities during state transitions. It is having well-defined business logic and rules of working for how an application is intended to run and operate.

Given those, an agent can make that operation happen on any platform or piece of hardware, and it can be reproduced rapidly in the event of total loss. You may have already found the value in NixOS, Ansible, or Terraform for reproducing your infrastructure or your workstation. The same thing is now available for the software layer. It is a question of time and effort as the tooling allows.

Can you reproduce what it took to build a piece of complicated software? Almost certainly not. That is bound to the business, the people who worked on it, the bugfixes, the outages, and every decision made under pressure that nobody wrote down. It was never reproducible, and it is not reproducible now.

But the artifact is a different thing from its history. If the architecture, the ADRs, the interface specification, and the business rules are well defined, the artifact can be rebuilt without anything near the old investment of time and money. Terraform does not reproduce the reasoning that led to your VPC layout. It reproduces the VPC. That is still enormously valuable, and it is the deal on offer here.

For software that has existed for decades, rebuilding at 6x the pace is still going to take years. But that is a very small slice of the software opportunities that actually exist.

Costs over time

Build cost is not lifetime cost, and lifetime cost is mostly maintenance. This is the strongest thing anyone can say against everything above.

If you generate a system 6x faster and nobody on staff understands it well enough to change it safely, you have not saved money. You have moved the bill. Generated code with no resident expertise is a liability the moment it needs to change under time pressure, which is the only circumstance under which anything ever needs to change.

I do not think this is fatal, but the mitigation is already part of the prescription. It is that the specification has to be the durable artifact, not the code. If the business rules and the architecture live in the repo, stay current, and are the thing you actually edit, then maintenance becomes regeneration against an updated spec rather than archaeology in an unfamiliar codebase. If the spec rots and the code becomes the only source of truth, you have built exactly the legacy system you were trying to avoid, just faster than usual, and with less shared understanding of it than usual.

What you are actually paying for

So: if you are paying a SaaS vendor a large amount of money for a product, do you know what you are buying? And if so, how difficult would it be to reproduce?

Your enterprise may be paying for integrations, compliance, specific security conditions. All of that is a fine thing to value and spend budget on. But the largest line item is usually the one that never appears on the invoice, where you are paying somebody else to be responsible; to carry the insurance; to be the name in the incident report when it goes wrong; and to hold the certification that satisfies your auditor without you standing up the evidence yourself.

If the logic is commoditized but the liability is not, you may still be buying correctly. SaaS is not instantly dead. But not all enterprise tools require the same level of compliance, support, insurance, and so on. You are not paying for support on grep and probably not for any number of third-party 'supply-chain toolsets' in your environment.

But lots of software comes at a great cost where the platform is totally disconnected from your business requirements, and therefore you are paying for integrations you do not use, a compliance story you never invoke, and a support contract you have never opened a ticket against. Software logic implementation is a commodity; operational ownership and ownership of liability are not. Sort your vendors by which of the two concepts you are actually buying and the answers could get uncomfortable. And if you are buying the transfer of liability, what is the liability cap? Twelve months of fees is not what a breach costs you; the transfer is not the entirety of the liability.

There is a version of this that is not about vendors at all. Moving off a platform onto something dynamic and business-rule specific looks like an extreme change. But you almost certainly made a pile of business rule definitions and compromises to land on that platform in the first place. You have already done the expensive part once, just in a direction that suited somebody else, and probably cost a lot of money. That is difficult to undo.

There is a hazard in this. After enough years on a platform you cannot easily tell your business rules from the vendor's defaults. The system of record became the definition of the business, and a rule that exists because the vendor's object model required it looks identical, from the inside, to a rule somebody actually chose. Reproduce faithfully and you carry vendor accidents across as requirements. Does the vendor's odd naming for roles and stages represent your business, or just their object model? You find out what is yours during the process of defining the rebuild.

The future

And beyond the enterprise question: if you want to build something for yourself, for your business, or for your friends, can you define what it is you want? Specifically enough, completely enough, including the parts you would rather leave vague?

If so, you can have the robot create it for you. That is the constraint now, and perhaps it is a much better constraint than the one we had before. A revolutionary tool in a revolutionary era.