The senior should also start using AI to increase the amount of work done to stabilise the system, in a careful manner. More benchmarks, better testing, better safety net when delivering software, automated security reviews, better instrumentation, and so on.

> And this is how AI affects the two loops

There should be another image illustrating that the amount of mitigations done from senior side, red-/blue-team style.

> Yes, yes, of course this is simplistic.

It's an example, put to the extreme, to clearly communicate the ideas. As all things, the golden mean applies, as I understand the article argues for:

> the design of the 'Scale' version is influenced by what worked and what doesn’t work in the 'Speed' version of the system.

My rewrite is running stable in production for two weeks with 50x speedup, which have made the doomed old solution viable again.

Wonder what this will mean for future legacy projects and how how we should structure the programs to be inside “rewrite with llm”-size? Maybe a renessanse for microservices?

How can one help with implementing Linux and Windows support?

Is it open source?

Would not search + first party description solve that? It’s easy to create a page “you have problem A? Try our product B”.

You do not need to solve that at the language level. A common pattern is using multiple replicas, service discovery and automatic restart upon a dead replica. For example kubernetes does this out of the box.

For dark corners of the code, that is often a good middle ground between interrupting the service and never die.

For example: build code and image, update git reference and version number in Application when build done.

You then get atomic updates of both code and configuration.