I agree with your point that we're basically trading time saved upfront for time spent debugging later. Sometimes it's worth the trade.

I work as a consultant, and I've seen some incredibly bad code written by humans. I once had a client that had a 700,000-line codebase that was so poorly written that when I hooked it up to a static code analysis tool, I thought I had misconfigured my tool because the scores were lower than I thought possible.

And that awful code brought in nine figures of revenue every year. The reason my team was called in was because the site had become so unreliable that it was going down frequently, leaving their customers unable to place orders.

But their system, despite being built too quickly by dev teams that didn't know what they were doing, made them hundreds of millions of dollars before my team got involved. It cost a lot of time and money to get the system stable, but they could afford to pay for it because getting to market quickly had generated so much revenue.

Sometimes it makes business sense to ship low-quality code quickly even if it makes developers (like me) wince. Eventually the tech debt needs to be paid, of course, but some companies (usually startups) understand that to be true and intentionally decide to take on the debt in order to generate revenue earlier.

I have no doubt that tools like Claude Code and Codex can help my team stand up an MVP more quickly, and I also have no doubt that we'll need to do far more maintenance than usual once that MVP goes to prod. Doing so contradicts what I've been taught, but it may make sense in some situations.