* Don't do ad-hoc fixes. Don't mutate the production data just to fix an issue. Fix the bug, ingest the bad data in code if necessary, or write a migration/repair script that an ops agent can run. * Write infrastructure as code, don't rely on remembering complex manual workflows. * Make sure there's a single model in the app with a single source of truth. Don't let truth get spread out across representations, it will get out of sync and bugs will result. Derived truths can be projected from the single truth, but they must update when the truth updates. * Write all logic in the application server, and send only a minimal visible payload to the web client. No calculations, except those needed for rendering the view, should happen in the client.

It goes on. These are all driven from the model making mistakes and having to have it go back and refactor to correct them.

This is exactly the problem that TDD solves. One of the most compelling reasons for test-first is because "Running the code in your head" does not actually work well in practice, leading to the above-cited issues. This is just another variant of "Running the code in your head" except an LLM is doing it. Strong TDD practices (don't write any code without a test to support it) will close those gaps. It may feel tedious at first but the safety it creates will leave you never wanting to go back.

Where this could be safe and useful: Find gaps in the test-set. Places where the code was never written because there wasn't a test to drive it out. This is one of the hardest parts of TDD, and where LLMs could really help.

They want to be heavily regulated so that new upstart competitors will not come in and spoil their cozy space. And it’s easy to justify because terrorism, money laundering, insider trading, etc etc. And many of these regulations are largely ineffective and easily worked around, whilst costing billions to the banks to comply with. Hence the moat.

We won’t get banking disruption until there’s banking deregulation.