These sorts of refactorings take time, even more so if done by "committee". The good thing is that explicit interfaces have to be created thereby (hopefully) increasing adaptability and resilience over time.

() Spec and (variably coarse) implementation plan are already grounded in code reality and are commited.

I wonder which trend will be winning though. I personally won't bet on quality.

I did subagent based removal tasks a few times. These were the ones that required the least amount of input or thinking from me, because the requirements are abundantly clear. "Remove this part of the code without breaking any other part or by porting the tests done with it onto another system."

In these situations the code acts as the bookkeeping ledger itself, and coordination complexity is almost a no-brainer.

I had the problem of crashing terminals due to OOM kills and wanted to switch to a more lightweight terminal. Also I had too many of them and couldn't find the right one any more.

I thought, why not build one yourself. The result:

https://github.com/ThePixelPilgrim/kabelsalat

It has GTK tabbed, (almost) transparently tmux-backed terminals (so quitting or crashing the app and starting it up again restores the state) in colored, named groups.

I recently added Wayland app embedding to run Chrome side by side with the terminal, local to each group, but this is still a bit shaky.

Would be nice if someone would test drive it and give me some feedback. :)

Not sure about "bugs" in that area, but there is a lot of work going on by mathematicians in formalizing and checking ever more complex proofs using proof assistants.

These systems have been tested on very complex proofs already, but well... I'm not a mathematician, just a software engineer who accepted his new role in this "new thinking order".