> not 99% tweaking reports, trying to implement arcane and contradictory business logic, or fighting with shitty and frustrating externalities.

Those are the parts the LLM is bad at. The 1% of stuff that was interesting was worth looking forward to.

I’m unconvinced about architecture mattering much. I used to think that, but these days I’m leaning towards it being the product of a problem we don’t have anymore. Architecture used to be dangerous and time-consuming to redo. If an AI can do that safely for $100 or $1000 in tokens (one day), that ROI is maybe negative

In a big production codebase with lots of active customers and data, architecture changes still feel pretty difficult even with LLMs accelerating them by an order of magnitude — migrating and backfilling data and all of that. That’s more complex than pointing Claude at a repo and saying “rewrite this in Rust.”

I guess you’re right, though - what is the ROI of keeping the architecture clean? It certainly saves time and money later, but it’s unclear if it’s a net win.

(It’s of course also significant to note that the upfront work of figuring out the right architecture and keeping the code clean has also been correspondingly reduced as well. Both sides of the equation are affected…)

The industry never really figured out a way to reliably answer this question in the pre-LLM days either, so… I suspect it will continue to be hard to determine.

in my experience it takes more than a day to sufficiently migrate bad architecture to a good one. like, many more days than it took to vibe the original implementation. having the prototype is good to understand what you want, but then going back and rebuilding it properly is a longer task. which is fine.