First let me tip my hat and thank you for engaging on this. I think though that we're talking past each other which isn't my goal. So I'll try to explain a litt

First let me tip my hat and thank you for engaging on this. I think though that we're talking past each other which isn't my goal. So I'll try to explain a little clearer. The concerns you raise are valid. The process in my example is more rushed than I'd go through in a team context. This is a relatively immature project I'm exploring solo, so the appropriate level of "process overhead" is different than in a team context. I didn't take the time to separate that from what I'd do in a team. In a team, there'd be upfront discussion to align on what's in the "roadmap" (ie. we'd write a spec), there'd be discussion as the work proceeds if tech-debt emerges and refactors are needed, there'd be CI, tests, coverage, and code review. A good team would own the code forever, so they'd be happy with any refactoring. When I said massive refactors I meant within the context of one PR. It's insanely freeing to be able to draw with crayons all over your codebase, see what works, and then either `git reset --hard` or refactor it into shape. If a refactor of existing code is needed, that's its own PR. In summary, almost nothing changes at the level of team process. Keep all those guardrails - but use these tools to 1000x the amount of typing & exploration you can do!