The Software Frontier
#software #ai #making
Governing Question
What becomes worth building when implementation is cheap, but direction and understanding remain scarce?
Current Position
Cheaper implementation expands what can be attempted. It does not establish that a problem matters, that a proposed product belongs in someone’s working life, or that its builders understand what they have made.
Direction depends on contact with the problem. Engineering comprehension remains necessary when generated code meets failures, integrations, and consequences that a prototype can avoid. Timing matters too: some opportunities reward exploration, while others become clearer after earlier attempts expose the constraints.
The frontier lies in choosing worthwhile problems and learning enough to build responsibly, with speed serving that inquiry.
The Argument
The Low-Code Fallacy in Enterprise Software
Low-code can accelerate prototypes; it cannot repeal complexity. Real enterprise software still needs engineers who understand consequences.
Why Shipping Code Faster Won’t Save You
Speed is cheap now. Differentiation is not. The winning teams are the ones who know what to build, not just how fast to ship.
Code has never been cheaper
Cheaper code and faster delivery do not guarantee a useful product. Conviction grounded in customer understanding gives the work direction.
AI assistants create a false sense of progress for young engineers
AI can make young engineers faster without making them better.
First Movers Don’t Win In Technology. Last Movers Do.
In tech, first is rarely best. The winners are the ones who wait for the fog to clear, then move decisively when the category is legible.
Ideas are nothing. Execution is everything.
As AI makes execution cheaper, direction matters more: what to build, whom to serve, and whether the problem is worth solving.
What Changed
The writing on low-code and faster delivery questioned whether easier production creates useful software. Later entries sharpen the distinction between execution and direction, while the first-mover argument introduces timing and the cost of exploration. The inquiry has moved from the abundance of software toward the choices that make building worthwhile.
Unresolved
- Which problems become worth solving when implementation is no longer the main constraint?
- What replaces technical scarcity as a durable advantage in software?
- How should organizations evaluate faster creation when context and judgment remain scarce?
Last revised Sep 11, 2026