There's a more general problem. We need to figure out how to use LLMs and still have decent code quality.
One possibility is to have firmer APIs for known components. APIs that come with the entry and exit conditions for proof of correctness. That gives an LLM a hard definition it can work to meet.
This isn't as bad as it used to be. We may be able to use LLMs to create entry and exit conditions from specs written for humans and from unit tests. Code is cheaper than it used to be, but so is formalism.
This may be a way to put firewalls around AI slop.
What I'm getting at was covered in an article yesterday about the end of abstraction. There's an argument being made for layer-free software, where everything is one big blob of code, created and understood only by an LLM. The software is modified only by re-prompting.
There are a lot of people edging around this concept, but it's not solid yet.
Can you point to any place/post making this argument? I'm an active lurker here, and have not seen anyone arguing for layer-free/blob-of-code type of workflow.
The fact that some teams find themselves there is simply a realization of what I stated - inactive maintainership by not taking code reviews seriously.
I saw that go by on YC two days ago, and it scrolled off fast enough I can't find it. They were talking specifically about AI tools, as in avoiding harnesses and letting the LLM do more of the job.
One possibility is to have firmer APIs for known components. APIs that come with the entry and exit conditions for proof of correctness. That gives an LLM a hard definition it can work to meet.
This isn't as bad as it used to be. We may be able to use LLMs to create entry and exit conditions from specs written for humans and from unit tests. Code is cheaper than it used to be, but so is formalism.
This may be a way to put firewalls around AI slop.