The Hardest Part of Software May No Longer Be Writing Code

Software development is entering a moment where writing code may no longer carry the same cost it once did. Laurie Voss described that change in a quote collected by Simon Willison on 14th September 2026, pointing to a shift in where the real work of making software now sits.
“The cost of writing code collapsed, and the cost of reviewing, fixing and operating it is following, and I’m assuming it gets there,” Voss said. The statement links several parts of software development: creating code, checking it, repairing it, and keeping it running. If the cost of writing code falls first, the other parts become the next focus.
Writing Code Is Only One Part of the Job
Voss’s point is not that software becomes complete when code exists. Code still needs review, fixes, and operation, and each of those tasks remains part of the cost of making software. The quote presents these activities as connected stages rather than separate concerns.
The order matters. Writing code may become less expensive, but that does not remove the need to decide what the code should do, check whether it works as intended, correct problems, and operate the finished software. The cost may move from one stage to another.
That creates a simple question for anyone thinking about software development: if producing code is no longer the hardest part, what work deserves the most attention? Voss offers a direct answer in the second half of the quote.
The Remaining Work Starts With People
“What’s left of making software is finding out what people actually want, defining it precisely, and making it pleasant to use,” Voss said. This shifts the focus away from code as the whole product and toward the people who need to use the result.
Finding out what people want comes first. That means understanding the need before turning it into a software task. The quote does not describe this as a minor step. It places that work at the center of what remains when writing code costs less.
Defining the need precisely comes next. A broad request may not tell someone what the software must do, but a precise definition gives the work a clearer target. Without that clarity, less expensive code does not automatically produce a useful result.
The final part is making the software pleasant to use. Voss includes this alongside understanding people and defining their needs, which gives the user experience a central place in the process. Software must not only exist or meet a definition; it must also feel good to use.
A Different Measure of Software Work
Voss’s quote describes a future in which the amount of code may say less about the value of software development. The important work may lie in understanding people, setting a precise direction, and shaping the experience that follows.
Reviewing, fixing, and operating software still matter in this view. Voss says their cost is following the falling cost of writing code, while also assuming it gets there. That means the quote describes a process still moving toward a new balance rather than presenting every stage as already equal.
The idea also draws a line between producing software and making software well. Writing code addresses production, but understanding what people want addresses purpose. Precise definitions address direction, and a pleasant experience addresses use.
That distinction gives the quote its main lesson. Lower coding costs do not settle the most important questions. They make those questions harder to ignore.
On 14th September 2026, Laurie Voss’s summary offered a compact way to look at the changing shape of software development: the work may become less about writing code and more about knowing what should be built, describing it clearly, and making it useful to people.




