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, where some of it was wasted on code that never went anywhere.

But the world is in quite an amazing place right now, where a current cheap Flash-tier model can generate a functional 500-line Python script that parses and re-encodes a pile of files to make your entire day more efficient, if you know how to ask for it. That now takes a few seconds to request and run (thank you, Gemini 3.7 Flash). 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 software development. Software logic implementation has become a commodity. The expensive part of software is not really the programming logic; it is the accumulated organizational knowledge of why the thing works the way it does and the operational ownership for that context. 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 now is to ask what software companies and SaaS providers are actually selling. The modern experience with coding harnesses and LLM models 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.

My progress was roughly as follows.

Phase 1 - Testing the waters

This was enough to bring a few products to prototype and launch at least one in production, with rapidly accelerated timelines.

Phase 2 - Development of architecture

I got real refinement and product work out of this level. 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 where Phase 2 optimized it for me and then buried the savings under large amounts of administrative overhead.

At this time, the tools also had no memory between sessions, which meant every 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.

I was mainly using a large-context Pro-tier model throughout phases 1 and 2 (Gemini 2.5 Pro), aside from experimentation with other vendors. I feel like this model still 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 (at best) in the order of magnitude of correct.

However: 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. But 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. Is it the governance and the harness around the model?

Perhaps everyone is going through the same cycle of learning how the new tools work, as new techniques and technology are being developed. I am not sure. But the buzzwords around when I experienced phase 3 were certainly all around one's 'harness' and 'agentic coding'.

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 just built a longer queue with the same bottleneck at the end of it.

But 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 human 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 an old system commissioned by people who have left the organization.

There is a middle ground option. Consider an internal approvals tool: a form, a routing rule, a handful of roles, an audit log, email notifications, one integration with the personnel directory. Real business logic for this tool can be described in a couple dozen rules, all of which somebody in the building can still articulate out loud. That is the case I argue is most interesting in the current era, and I think it now takes days or weeks rather than quarters to implement this 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 determining the business logic that 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 sufficiently precise specification is the software (as the Brooks argument goes).

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 extremely complicated in the modern era. Framework churn, dependency management, build systems and CI/CD pipelines, the seven ways to configure the same deployment, glue code between services that should never have been separate services, and so on. None of that is essential complexity, and 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 Brooks objection is correct but the conclusion does not exactly follow. Writing a complete spec is as "hard" as writing software. But you are not writing a specification from nothing. You are writing down what the organization already decided, most of which exists in someone's head, a documentation page, and any number of requests or tickets. Or perhaps you can extract what is desired from the head of a particular executive. That work is transcription and reconciliation, which has different challenges involved.

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. The actual reproduction is a question of time and effort as the tooling and API costs allow.

Can you exactly 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 for a bugfix 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 available to everyone.

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. Perhaps this is a strong argument someone could 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 or software company 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 if the software creation is cheap, and the business logic is your own, the largest line item could be one that never appears on the invoice, where you are paying somebody else to be responsible for operations; to carry the insurance; to be the name in the incident report when it goes wrong; and to hold the certification that satisfies auditing.

If the logic is commoditized but the liability is not, you may still be buying correctly. Software development and SaaS are 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 might not actually need, and a support contract of uncertain value. Software logic implementation can be a commodity; operational ownership and ownership of liability are different. So you can sort your vendors by which of these two concepts you are actually buying - are they doing the work, or just holding the burden? And if you are buying the transfer of liability, what is the liability cap? You can directly use a risk calculation to determine cost/benefit here.

But maybe we don't have to talk about vendor-value at all. What about indirect costs to yourself? Moving off a large SaaS 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 this expensive part once, in a direction that suited someone else's code, and probably cost a lot of time and money. That is difficult to undo.

So the status quo creates a hazard. 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 a migration or rebuild.

But all of that happened because of an investment of time and effort into vendor complexity rather than the real essential problem. My argument is that you can focus on the essential work and so much of the accidental complexity can just be performed by the machines at this point.

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.