I've been considering a... protocol? for improving this. Consider this repo:
foo.py
bar.py
bar.py.vibes.md
bar.py.vibes.md would contain whatever human-written guidance describes how bar should look. It could be an empty file, or a few paragraphs, or it it could contain function signatures and partially defined data types.
If an LLM wants to add a new file, it gets a vibes.md with whatever prompt motivated the addition.
Maybe some files keep their assiciated *.vibes.md forever, ready to be totally rewritten as the LLM sees fit. Maybe others stick around only until the next release, after which the associated code is reviewed and the vibes files are removed (or somehow deactivated, I could imagine it being useful for them to still be present).
What do people think, do we need handcuffs of this kind for our pair programming friends the LLMs?
I think coding will eventually go away in favor of models with metadata built around them.
How many times did you have a mutation operation where you had to hand code the insert of 3 or 4 entities and make sure they all come back successful, or you back out properly (and perhaps this is without a transaction, perhaps over multiple databases).
Make sure the required fields are present Grab the created inserted ID Rinse, repeat
Or if you're mutating a list, writing code that inserts a new element, but you don't know which one is new. And you end up, again, hand coding loops and checking what you remember to check.
What about when you need to do an auth check.
And the hand coder may fail to remember one little thing somewhere.
With LLM code, you can just describe that function and it will remember to do all the things.
An LLM with a model + metadata - we won't really need to think of it as editing User.java or User.py anymore. Instead User.yaml - and the LLM will just consume that, and build out ALL of your required biz-logic, and be done with it. It could create a fully authenticating/authorizing REST API + GraphQL API with sane defaults - and consistent notions throughout.
And moving into UIs- we can have the same thing. The UI can be described in an organized way. What fields are required for user registration. What fields are optional according to the backend. It's hard to visualize this future, but I think it's a no-code future. It's models of requirements instead.
I don't understand all of what you wrote but a lot of it is very old news and usually done with deterministic tooling you don't have to wait for, some of which you should have built or configured yourself to get it tailored to the type of work you do.
And some of it we've had under the RAD umbrella, basically using configuration files and tools to generate those that are used to generate large portions of systems.
> I think coding will eventually go away in favor of models with metadata built around them.
You can pry my understanding of, and desire to use, traditional programming languages from my cold dead neurons. The entire point of computer systems is that they automatically and unerringly follow precise, explicit instructions.
In writing the code that is supposed to implement my idea, I find that my idea has many flaws.
Sending that idea to an LLM (in absence of AGI) seems like a great way to find out about the flaws too late.
Otherwise, specifying an application in such detail as to obtain the same effect is essentially coding, just in natural language, which is less precise.
What do you suppose that metadata is going to look like if not partially complete code where the LLM fills in the gaps?