The cost to build is not zero. Try building something and then get back to me. Did it just work? Did it survive exposure to your first customer? How about your second? How about your 100th? Does it scale beyond that? When you go to extend it, is it extensible or do you have to refactor everything? How good is the automated testing coverage? If you let a coding agent define and write all the tests, they probably aren't very good. The cost to build *a* thing is getting cheaper. If the result is we build *many* more things, then the cost to build and maintain *things* is going to skyrocket. Proceed with caution.
It's a fine line for sure. One I build something and get it into "production" ie I use it every day for work. I wonder if im missing something obvious that would make it work better or help me be more efficient. But dang it's empowering to be able to dream something and then make it real
The total cost is almost the same or higher. What became cheaper is the cost of discovery because the feedback loop for a POC (proof of concept) is now cheaper in most cases (ignoring the initial learning curve to use AI tools effectively but factoring in the increasing cost of tokens). Overall, I understand why token-sellers want us to believe that the cost of BUILDING things is approaching zero (and conveniently assume BUILDING=RUNNING=MONETIZING), but anyone with critical thinking should be able to see the obvious conflict of interest there. And if I read this correctly, you're also warning about the point of diminishing return when the POC fails to scale beyond a certain point. However, there's a silver lining: when the PMF is proven, the developers have a much easier time implementing the product from scratch because they have a working prototype at hand instead of the traditional vague and changing requirements. Our workflows are empowered but it hasn't fundamentally changed, despite what the token-sellers advertise.
Building things is getting cheaper. Building things with intention is become more rare and expensive
This is the modern iteration of 'we built the prototype in a 3-day hackathon' or 'my nephew can code this in a weekend.' Shipping an initial artifact has never been easier, but ensuring that artifact survives the 100th customer, scaling infrastructure, and continuous refactoring is where true engineering lives. As the cost of generating lines of code falls, the volume of code explodes—and with it, the architectural complexity and maintenance debt skyrocket. If you let an agent write both the feature and the tests, you aren't automating quality; you are just automating confirmation bias. The future belongs to teams focusing on code governance, not just code generation.
The maintenance bill is the one everyone notices, but it comes second. The first cost is easy to miss. Building used to be expensive, so you had to stop and ask if the thing was worth doing at all. The price sorted the ideas for you. Take the price away and nothing sorts them. Teams build whatever they can, and all of it still has to be run and kept up for years. So the real work now is deciding what not to build. That used to take care of itself when the work was slow. Now someone has to say no and stand behind it.
Great point about the price. I would add one more. Because develop and ship digital product was costly (with everything arround) it got priority and focus of whole enterprise around it. Ergo aligning, prioritising, bridging worked. Now it’s “cheep” to write a code and launch SW… great but SW by itself don’t generate value. To make example, it’s like building a taxi company back in the day and just buy a cars… well ok and what’s next? Drivers, backoffice, pricing, marketing, GTM, competition… The car itself doesn’t have positive value… contrary it has negative value as it cost money and once is just standing in the parking lot, you loose.
This is an important distinction. AI is reducing the cost of producing an initial version of software, but it doesn't eliminate the cost of building a reliable product. Real engineering begins after the first prototype validating with users, handling edge cases, maintaining quality, ensuring scalability, writing meaningful tests, and evolving the architecture over time. Faster code generation is valuable, but sustainable software still depends on sound engineering practices and thoughtful design.
All your point is valid, but I think the context matters, if you're someone who always had alot of ideas, but never managed ro execute on them bc you could not code (aka create something). Trying out your ideas are now cheap, if someone of them stick find a technical co-founder (or technical help to sort your pain points out) but someone who has been coded for 15 years i am genuinely excited that we have democratized solving problems! But building a sustainably company I'll argue is harder than ever
Teresa, this hits the part teams are most tempted to wave away. The first prototype can look cheap, but every extra surface area creates ownership: tests, observability, migrations, support paths, and someone who knows why it exists. The product trap I keep seeing is treating AI output as the artifact instead of treating the operating model around it as the artifact. When you evaluate AI-built features with teams, what early signal tells you they are accumulating maintenance debt?
Founder, Inside the Function | Operational analysis of how elite companies actually run Finance, Ops, Sales, Product, Engineering — for C-level executives | Product Owner @ YSoft | Subscribe at insidethefunction.com
1wActually it really depends on how you use AI to code it. If it “vibe coded” which is for me you used just AI without any external tools for automation than it will not ended up so good and more customers and features -> more repetitive problems. BUT from my experience I build a system good programmer would do as if it is done manually (complete explicit state machine of development stages, tests and test coverage done by standard tools, explicit “hard” coded deployment, documentation and change requests management as separated steps in advance to implementation) then it works really well for me. Reliable, no unexpected issues, consistent. It required to build a development system in advance (I used python), but then it brings really good results where I do just description of what I want in form of Md documentation or CR.