> This is the number one thing I optimize for now: the ability to quickly and safely change significant parts of the code and product.
This was always a good thing. Its value has nothing to do with the advent of AI coding.
> The opportunity cost of not being able to safely restructure has gone up substantially.
This bit is contradictory with everything else you said. Prior to AI coding it would take a lot longer to perform restructures. If anything, the thing you're now optimising for has gone down in value. It's still valuable, but perhaps a little less.
But in seriousness, this intuitively feels like something (as phrased) that would be easily influenced by loud noise and quantity rather than hard facts. The "piloted poorly" part is applicable to any tool use. AI is no different there other than its adoption rate.
The pattern I observe is: "write code, write test, make things green"
This is different in two ways from the classic TDD red-green-refactor suggestion:
1) they don't start with the test first, so the tests that get implemented are after writing the code, and run the risk of the model attention being now more influenced by the just-written code than the original spec
2) they finish when everything is green and don't followup with the "refactor" step unless manually prompted (either directly or indirectly by your own scaffolding/rules/whatever). this results in frequent hyper-local non-ideal-longterm fixes for things that went wrong in the first shot at writing the code pre-test-writing.
(As always, the only person who can ensure the code landing in your repo is good is you.)
But here's the rub - if you want your clanker to do those steps, it's usually a simple matter of adding them to your AGENTS.md and then it always does them.
I'm a big fan of the characterization step step being added. And it can be reasonable to add this before or even after the fact as a commit prior to your actual commit (assuming you're familiar with using tools where that's easy to do - e.g. jj or git with rebase). And the agents can do this - they just don't tend to without you saying to do so.
A lot of engineering practice comes from choosing which elements are reasonable to use given the context of what you're building. Providing that is your job. When you do that poorly, you get poor results. But garbage in garbage out has always been a thing. Any advanced automation amplifies ambient assumptions
I'm not talking about time. I'm talking about safety. The amount of times I've seen "I refactored it, but I'm not confident enough to take it to prod" is significant. Being able to go faster but still not ship it is the huge opportunity cost.
Time, safety and cost are one and the same. Not safe enough? Spend more time increasing confidence. Taking too long? Cheap out now and pay the price later due to added risk.
All of that is orthogonal to AI. All AI did was accelerate the typing code part - which was never the bottleneck or a very significant cost to begin with.
In the broader corporate world, that's not "opportunity cost". All changes are considered "risk".
All deployments must be approved by an advisory board. All work must originate from a clear business need. Analysis of those needs is not concerned with implementation, least of which whether "AI" is used.
What matters far more is that a contract requires work to be done by a deadline. Those deadlines are driven by policy. There will be no adjustment to policy unless tangible benefits are shown from more frequent deployments of code.
I gotta tell you that's extremely unlikely if you're already shipping every other week at the end of the sprint. Most of that sprint is spent in meetings, not writing code. Nobody is doing big refactors because it wasn't built so fast to require them. There's some technical debt, but nothing so severe. Those meetings are preventing risk, not wasting time. The bottleneck is a feature, not a bug.
If you think the future of dev work is to be a bureaucrat, you're right! It looks like the rest of the world outside of SV is ahead of the curve and living in the future.
I mean "We can't build X because our code structure makes that difficult" has an opportunity cost of the value of X.
I don't think the future of dev work is being a bureaucrat. I've done more rigorous engineering the last two years than I did previously. I'm more confident in the things I shop and they were built in a fraction of the time. It's a bright future for software engineering.
This was always a good thing. Its value has nothing to do with the advent of AI coding.
> The opportunity cost of not being able to safely restructure has gone up substantially.
This bit is contradictory with everything else you said. Prior to AI coding it would take a lot longer to perform restructures. If anything, the thing you're now optimising for has gone down in value. It's still valuable, but perhaps a little less.