BUILDING
IS FREE.

Building software is free now. A person says what they want in their own language and the thing exists, and most of the people doing it never learned to code.

I spent twenty years on the half that just became free. The JVM and Spring, Cloud Foundry, a Bitcoin developer platform, and now agent systems.

The vocabulary for this is the inner loop and the outer loop. The inner loop is what happens on your machine before anything is committed, and it is what a platform builds for whoever already arrived. The outer loop is everything after: whether anybody shows up, whether they reach a first working call, whether the number moves. The outer loop is the half I lost, more than once, while the inner one ran clean.

[THE DOOR]

I did not study computer science. I trained as an electrical and electronics engineer and met programming on the job, after undergrad, when someone taught me object oriented programming in Java. My core memory from that year is Hello World printing to a console.

I want to be precise about what happened, because it is the whole foundation. It was not professional satisfaction. As a person, I had made something and something happened because of it, and what arrived was happiness, an unplanned smile, a hit of dopamine, a private fulfilment at having caused an effect in the world. What followed took about four minutes. Print my name instead. Add an exclamation mark. Break it. Read the error, which was telling me something specific. Search for it, find the documentation, fix it, break it again on purpose. See it work, extend it, break it, repair it, extend it further, until the thing I wanted existed.

The industry calls that flow state, and the term is older than my career. What the term does not carry is the price. That loop survives only as well as the tools around it, and every tool you have to leave in order to see a result takes the state with it. Four windows between writing a line and watching it run, and the state is gone before the fourth one loads.

[WHAT IT COSTS TO BUY FOUR MINUTES]

At Pivotal, on Cloud Foundry, we shipped a command called cf push. You ran it in your project directory and a few seconds later your application was running in the cloud on an HTTPS URL.

Everything hard sits behind the word push. The platform packaged the runtime, the dependencies, the environment, and the environment variables. It provisioned a load balancer and a gateway, placed the result in a multi-tenant container system, and bound your application to the services it needed, so that a Postgres database or a RabbitMQ broker or a Kafka cluster arrived already wired, with the right client and the right credentials injected, provided you had written the application to accept them. The marketing was the command itself. It fit inside a tweet at the old character limit, so we tweeted it, and running the line printed Hello World on a URL in the cloud.

The part that mattered is easy to mistake for convenience. cf push never asked what language you had written. A build pack existed for Ruby, for Java, for Python, and the platform did the detection itself. Nobody converted to anything.

Build packs were a market decision before they were a technical one. Carrying every language set our addressable population at every developer alive, and it meant growth never depended on winning a language war against anybody. The tweet was distribution strategy: the shortest demonstration that could exist, carried by the people who ran it. Both of those are product calls, and they decided more than any amount of engineering underneath them.

[THREE THAT ASKED PEOPLE TO SWITCH]

In 2014 the same question came up in the Spring ecosystem, on event streaming and batch data: open source at the core, with a commercial edition sold on top of it. That shape sets the discipline, because the open project decides who arrives and the commercial product can only ever sell to people the open project already reached.

Hadoop was at its peak, with Cloudera and Hortonworks fighting over distributions and Spark and Flink arriving behind them. Our runtime was Java on the JVM and that market wrote Python and Scala. We bridged it with message brokers: write your consumer in any language, connect through the client library we publish, and the JVM sits on the other side. We lost, because the bridge still asked a Python team to accept a JVM in the middle of their system, and the open project never reached the population the commercial one was priced against.

I took the Hiro Platform, developer infrastructure for Stacks, a Bitcoin layer, from nothing to launch. Discovery interviews, research with the developers writing contracts on that chain, a funnel I defined and instrumented, and an activation number I owned. I held two convictions at once, that everything was moving to the browser and that you have to meet developers where they already are, so I built both: VS Code in the browser, VS Code on your own machine, and an SSH tunnel joining them, with Kubernetes, certificates, and a gateway underneath. The KPI was mine to set: collapse the twelve steps required to deploy a contract into under five minutes, with a clean promotion path from testnet to mainnet. I hit it. A head of engineering told me to my face that I had confirmation bias about the bridge. The people who used it liked it and said it freed them from their desks, that they could work from a laptop or an iPad. Roughly a thousand developers existed in that ecosystem. About a hundred came. Activation never moved. Everyone that bridge served was already on Stacks; it made their week better and opened no doors.

The third one never shipped. Our API already had an OpenAPI specification and the documentation lived in an open repository anyone could contribute to. From a specification like that you generate a typed client library for whatever language a developer is already writing: a package installed with pip for Python, a gem for Ruby, a Maven artifact for Java. The developer calls a method with real types, reads no URL, hand-rolls no HTTP request, and learns nothing about our ecosystem to make a first call succeed. That is the difference between someone trying your platform on a Tuesday afternoon and someone never trying it. I lost that one on priority. It was filed as documentation tooling and it was actually distribution, and work that is mislabeled loses roadmap arguments it should win. The pool never widened.

[WHAT SEPARATES THEM]

Those are three of several, from different companies in different decades, and they resolve the same way. The inner loop was good in all of them, and what set cf push apart was never craft. It carried the developer's existing world across on their behalf, and the other three asked people to come to us first.

A platform's reach is set by how much of someone's language, runtime, and habit it can carry without asking them to switch. Build packs did it by carrying whatever language a developer showed up with. Client libraries generated from the spec would have done the same for the API, putting a Python or Ruby or Java developer one install away from a working call. The editor bridge served only people already inside the ecosystem, so it moved nothing.

Of those three arguments I won one and lost two, and the record came out the wrong way round. The one I won was the bridge, and it did not move the number. The two I lost were both about who could reach the platform at all, and both would have. The bridge was not the wrong thing to build either. It was right and irrelevant, in an ecosystem that held a thousand developers on its best day.

[THE SAME PROBLEM, A NEW RUNTIME]

Both halves showed up again in agent systems, in work where a wrong answer carries consequences and nothing about the runtime is deterministic. Pre-production is the inner loop: a ground truth set, evals, grading, and prompt and tool work until the system matches what the expert would have done. Matching the expert is the floor, and getting that standard out of the expert's head is the part almost nobody budgets for.

Production is the far end of the outer loop. The tradecraft owners read what the agents produced and react, and that reaction returns to the prompts, the tools, the integrations, and the ground truth set itself, with the most valuable signals carrying a comment or a pairwise preference. That returning signal is the one part a platform team cannot build for itself. It gets called reinforcement learning, which it is not; reinforcement learning changes model weights.

[WHERE PROOF REPLACES GRADING]

Grading has a ceiling. A model judging another model is still a model, and on the cases that matter most it will agree with a confident wrong answer. Where the outcome is consequential, part of the check has to be something that cannot be talked into agreeing.

Paxora is the one I own outright. I incorporated it and built it alone, across all fifty states, and the first decision was a strategy call before it was a technical one. Everyone entering legal technology is selling generation. I built the opposite: an engine that models each state's forms, fields, jurisdictions, and deadlines as data and computes the filing deterministically, with models used for reading a person's documents and never for producing the filing itself. The reason is commercial. A rejected filing costs a family a hearing date, and no consumer product survives that failure mode at volume. Trust is the product, and generation cannot underwrite it.

The hardest part is the moment of handing the packet over. Paxora produces a person's fully populated, court-ready forms and then has to decide whether to release them. Three answers are possible: release it, hold it, or refuse it. That decision is written in Lean, a programming language whose compiler checks mathematical proofs. It defines what makes a packet acceptable, and eight theorems compile against that definition, which means they hold for every packet, every court, and every override that could ever exist. A proof with a gap fails the build the way a type error does, and CI compiles it on every change. A table of 552 cases then runs the same inputs through the model and through the real production endpoint, and the two have to agree on every row.

The Java compiler I learned on told me a type was wrong in under a second, and that second was the entire inner loop. The same second can now tell you a business rule is wrong across every input that will ever exist. That is a deeper loop at the same speed, and what comes back is no longer a sample.

Every surface in that system also publishes an OpenAPI spec and runs as an MCP server, which resolves the client library argument I lost, from a direction I never predicted. I no longer generate a Python client, a Ruby client, and a Java client. I publish one description precise enough for a machine to act on, and the machine writes whatever client the person in front of it needs.

[SCALING WITHOUT HIRING]

The argument I put in front of founders now is about headcount, and only then about technology.

Delivery work in the field scales one way. Hire another engineer for every new engagement. That ratio is the operating plan, and it sets the ceiling on how many customers a company can carry. Part of the work is high touch and stays that way, particularly where the operating environment demands a person in the room. The rest is assembly, and assembly is what companies keep paying senior people to redo.

So I built the layer that does it. One command stands up an entire engagement: the agent runtime, the tools, the data integration, the eval set, the ground truth, the proofs, and the grading. A terminal control plane sits above every engagement and shows its runs, its evidence, its open decisions, and everything blocked. The engineer arrives to an environment that already exists and spends the week on the customer's problem.

What changes is the ratio, and the ratio is what the plan is allowed to assume. Engagement count rises without headcount rising alongside it. That is a decision about the shape of a company, made with tooling.

[EVERYTHING IS ONE INTENT AWAY]

The audience I spent twenty years designing for has stopped being the audience. Building software no longer requires being a developer. Nothing gets downloaded, installed, or configured, and nobody reads the documentation. A person says what they want in their own language and the thing gets built. A lawyer, an operations manager, a founder with no engineer yet: all of them ship working software now, and none of them were ever going to learn a toolchain.

Every platform I built asked people to come to us. There is nothing left to come to. Language, runtime, and habit stopped being the barrier at the moment natural language became the interface.

So the barrier moved. Software gets written now by people who never learned to write it, in volumes nobody can read, which retires the old answer of putting a senior person in front of it. A test suite only ever checks the cases somebody already thought of.

Here is the version I live with every day. Anyone can now ask a model for a divorce filing and get one back that looks right. Whether a court clerk accepts it is a different question.

In September I handed two frontier models the same family documents, the same blank forms, and the same field list Paxora fills. Temperature zero, one pass, 1,803 fields across 332 forms in all fifty states. Gemini 3.1 Pro matched 72.8 percent of the fields. Gemini 3 Flash matched 73.1.

About one field in four came back wrong or blank. Twelve percent empty, fifteen percent filled with the wrong value.

The person filing cannot see which fields those are. They find out weeks later, when the packet comes back rejected and the hearing date is gone.

That gap is the work now. Producing the thing is free. Knowing whether it is good enough to hand to someone costs exactly what it always did, and nobody sells that. Almost all of the money and the attention still go to the part that got solved.

For twenty years the hard part was making software easy to build. That is finished. What is scarce now is taste and judgment: knowing what good looks like in a domain, and being able to say so with something stronger than an opinion.

Which is where the craft goes, and almost nobody has noticed. Everything developer experience learned in twenty years, fast feedback, no context switching, seeing the result the instant you change something, now belongs to the person doing the judging. That person has the worst tooling in the building. They read output in a text box, they cannot see what changed between two runs, and there is no way to try a judgment before committing to it or to record one so it holds the next time. It is the same class of problem I spent a career on, one layer up, and worth more than the layer below it.

Everything else is a prompt.