upvote
I don’t want every verb implemented, I also dont want an IETF standard. I want as little as possible, so I have to worry about as little as possible in the future.

Use-cases differ, you described a complete REST API, which can be as much of a problem as a too little.

reply
I see you haven't encountered an API where a GET command can modify the database.
reply
Similarly, I once worked somewhere that had an HTTP API that returned status code 200 {“error”: “ok”} to indicate an error occurred.
reply
Now why would you make such a monstrosity? Audit logs? I was having good day till now.
reply
Say what now
reply
Then just tell it to do that

It'll even suggest it

You want a single RPC websocket go for it

reply
Till it has explored the codebase, asked me follow up questions, suggested the code change, incorporating my fixes after losing time on context switch + the extra time I need when somebody requests a change in 3 months to learn the mental model. I’m way faster to just write it myself (mental model included)
reply
If it's genuinely the case that you can write code faster than you can prompt it into existence then you're not being ambitious enough with your coding agent. Ask it to do more. Tackle bigger problems.
reply
1. It's unclear why creating more code faster is a good thing. Software engineering wisdom for decades has been that code is a cost, not a product. There are great reasons for that, which haven't changed with the appearance of LLMs.

2. There absolutely are cases where modifying code "manually" is unquestionably faster than prompting an LLM. There are trivial examples for this - eg only an insane person would ask an LLM to rename a variable rather than using an LSP for that. It would provably and consistently take more keystrokes. There are less trivial examples as well, like, you know, having an understanding of your codebase and using good abstractions/libraries within it that let you make large changes to the program's behavior with little boilerplate code.

One can argue that producing a lot of complex changes through an LLM is faster, which I would agree with, but then see point #1. Sustainable software development has up to this point relied on iterative discovery of the right small components that together form a complete, functional, stable system (see "Programming as Theory Building").

There's zero indication so far that LLMs are capable of speeding up the process of creating complete, functional, stable systems. What every org within my career and friend circle is seeing (and research into productivity impacts of LLMs on software development is showing) is the same story - fast prototypes that either turn into abandonware, personal tools, or maintenance nightmares.

reply
bro is probably using a local LLM at 2 tokens/sec
reply
Ad hominem
reply
the obscure IETF? Which standard is that exactly? Who cares guess - Claude do that stuff.
reply