Ok, so here’s a question. A lot of this to me seems to assume that like stuff works the way it’s supposed to. And half of my job (SRE, not SWE) is figuring out why it’s not working the way it’s supposed to, which often involves diving into the code, because if it worked the way it was supposed to then I could just read the docs.

Is the assumption here that code goes away because LLM’s write perfect code?

What do you do if two people write competing specs? Which spec takes precedence? What is the hierarchy of a bunch of spec.md files? And if you can write all that in not code, How do you predict how the compiler will interpret it?

I could maybe see a higher level language come out of this, but software engineering often isn’t the art of writing code, but figuring out why the code that’s there isn’t doing what it’s supposed to.

The agile manifest has this principle:

Working software over comprehensive documentation

This basically flips that in its head. Does this like work? Documentation is immensely tricky to get right. How do you maintain “code” when there’s no shared objective understanding of what symbols mean.

If I read python code, what it does is objective and predictable. If I read documentation, I have to trust the words you use make sense to me? I often read code instead of documentation, because only the code can tell you what it _really_ does.

Maybe “writing essentially all the code” is like the 80/20 rule or 99/1 rule. Engineers only write 1% of code, but that code represents a wide swath of time bug troubleshooting, distributed systems management, optimization, etc.