I had some thoughts after listening to Shopify's Toronto Tech Week talk. They mentioned that their internal tool, River, can do anything. Ask it for a bug fix or UI change and it'll whip up a demo in minutes. They've rearchitected it and other applications multiple times because the cost of architectural changes are so much lower now.

So, my thoughts were as follows. If they can code anything in River, perfectionism will occur where it never seems like the code or architecture is good enough. How do they manage this? (this question is valid even without River, just for general coding with AI)

I think they need to define metrics for success. This requires initial investigation into what the codebase is actually meant to do. Does it need to live long? How important is it? If it will exist for a while, what features might be added on top? Even if you think it's for the short-term, why? If we build on top of it, what might we build?

After investigation, it will become more clear what the codebase must do. My main focus here is determining if it's realistic to architect for specific scenarios, like making it easier to extend. The goal is to avoid premature optimization while utilizing AI to set up you for the future. Pre-AI, you'd avoid it like the plague. Right now, I think it makes development easier enough that you can set building blocks for yourself so you aren't pigeon-holed into one decision in the code and can more easily refactor if the need occurs.

I'd also ask why the refactor is needed. Did we realize something terrible about the current version? Do we simply think the new architecture might be better? What defines "better"? If it's something subjective like ease-of-use, we better have near 100% agreement that the new architecture is better, or it probably isn't worth our time. That said, if AI is good enough to re-architect in seconds, and the process of confirming that the new architecture is quick and verifiable with no chance of missing a bug, it becomes easier to justify small gains where even 60% of people think it's better. However, real metrics are better, like if the architecture change improves latency.

That said, it's an interesting question about backlog as well. Do we simply have so little on our backlog that a new architecture is more important or easier to work on than new improvements?

Additionally, you likely want to ensure that architecture changes don't bloat the codebase. If you're cleaning it up, trimming stuff, reducing redundancy, that's great. If you're adding complexity, it needs to be justified with an above reason.