Code is run more than read (2023)

And cars are driven more than worked on, but putting the oil filter inaccessibly in the middle of the engine block is still an unforgiveable sin.

I've worked at some of the "top tier" finance firms over the years.

It is absolutely astounding how much of them run on code that is:

- very reliable aka it almost never breaks/fails

- written in ways that makes you wonder what series of events led to such awful code

For example:

- A deployment system that used python to read and respond to raw HTTP requests. If you triggered a deployment, you had to leave the webpage open as the deployment code was in the HTTP serving code

- A workflow manager that had <1000 lines of code but commits from 38 different people as the ownership always got passed to whoever the newest, most junior person on the team was

- Python code written in Java OOP style where every function call had to be traced up and down through four levels of abstraction

I mention this only b/c the "LLMs write shitty code" isn't quite the insult/blocker that people think it is. Humans write TONS of awful but working code too.

I like the final conclusion. And sadly I don't feel like anything changed for the better on this topic since 2023.

I am afraid that without a major crash or revolution of some sort, user won't matter next to a sufficiently big biz. But time will tell.

> But when you run your code in production, the KISS mantra takes on a new dimension. It’s not just about code anymore; it’s about reducing the moving parts and understanding their failure modes.

This sentence, itself, takes on new meaning in the age of agentic coding. "I'm fine with treating this new feature as greenfield even if it reimplements existing code, because the LLM will handle ensuring the new code meets biz and user expectations" is fine in isolation... but it may mean that the code does not benefit from shared patterns for observability, traffic shaping, debugging, and more.

And if the agent inlines code that itself had a bug, that later proves to be a root cause, the amount of code that needs to be found and fixed in an outage situation is not only larger but more inscrutable.

Using the OOP's terminology, where biz > user > ops > dev is ideal, this is a dev > ops style failure that goes far beyond "runs on my machine" towards a notion of "is only maintainable in isolation."

Luckily, we have 1M context windows now! We can choose to say: "Meticulously explore the full codebase for ways we might be able to refactor this prototype to reuse existing functionality, patterns, and services, with an eye towards maintainability by other teams." But that requires discipline, foresight, and clock-time.

Once I wrote the perfect piece of software. It was so perfect that there was literally no bugs for months.

How could this have happened? Well, the code was shipped but no customer was running it in production.

Clearly, there is a thing missing here: Regulations. If you have strong regulations on how you can make money, you cannot sustainably have biz antagonize user. So in that case biz just becomes a filter for users that actually are willing (and able) to fund your software. That's a good thing.

Obviously, our regulations aren't perfect or even good enough yet. See DRM. See spyware TVs. See "who actually gets to control your device?". But still...

Oh noe, noe no.. you want to crowdsource debugging.. describe the error and your expectations, then build software by machine learning while screwing up.

Does the ">" mean "greater than" or is it meant to symbolize an arrow in a ordered sequence?

It went on the good track, but failed to generalize that ≹ is what apply among all these terms.

yes, run by machines, read by humans. so ?

[dead]

[dead]

[dead]

    biz > user