Writing
AI Coding Part 2: Development Costs
What got cheaper, what got riskier, and why cost discipline now matters more
AI-assisted coding has changed software economics, but not by making cost irrelevant. It has moved cost around: lowering some barriers, raising others, and changing what feels possible before we've done the hard thinking.
In Part 1, I wrote about guilt and legitimacy. Part 2 is less emotional and more structural: cost.
When starting is cheap, starting too much becomes easy — you can generate plausible momentum without building durable shape.
Not just money. Cost as time, complexity, attention, maintenance burden, and the cognitive load of keeping a product coherent over time.
AI has changed that cost profile. Certain things are faster and genuinely cheaper in the short term: boilerplate, rough prototypes, and first-pass implementation.
But first-pass speed is only one part of total cost. The harder costs often arrive later: integration friction, review and verification time, architecture drift, and maintenance overhead.
The key shift is that prototyping got cheaper while finishing got more strategic. When starting is cheap, starting too much becomes easy. You can generate plausible momentum without building durable shape.
I increasingly treat false abundance as a delivery risk. Lower build friction should tighten scope discipline, not dissolve it.
A practical model is four cost buckets: generation, validation, integration, maintenance. AI usually improves generation. It can improve validation. It can quietly worsen integration and maintenance if standards are loose.
This is why founder-builder realism matters more now, not less. The question is no longer can I build this at all - it is should this exist, can I sustain it, and what complexity am I importing.
Part 3 is about loss: what we may thin out culturally and cognitively if speed becomes fluent substitution for understanding.