The car analogy doesn’t work because you’re not the one making the code/driving the car. It drives itself, and you sometimes can propose some directions for it to steer.
The problems with llm aren’t just that sometimes your shit doesn’t work or obviously bad, that’s what you’re talking about, and that’s what minimally responsible sloperators can catch. The main problem is it writes something that looks OK to a human (that’s a criteria for it) but sometimes it’s unexpectedly idiotic in random places (because not being idiotic wasn’t a criteria). You need to check way more thoroughly for it, and you can’t use normal shortcuts that help you with it. So you obviously don’t do that.
See, that’s the issue. People letting it “drive itself” get worse results. You should be the one holding the standards and guiding the model, otherwise you will be frustrated.
Yeah, but it’s designed, purposefully, to trick people into believing you can just let it do whatever. And people do. Hense the whole problem we’re talking about.
I saw this advice too, the problem with being very detailed is a question why not use a less ambiguous languages to do it?
Why not write the explanation in language like Python. Why should I write it in English when I can say the same thing in Python and it is actually easier to do for me.
This kind of specification applies to the agent behavior or the agent behavior in a project. You don’t write it on every conversation, you write/review it once for the project or agent and let the harness include it on every conversation. You can even ask the agent to scan the codebase and pull desirable patterns out of it for future sessions.
The entire point of using an agent is to not have to write everything yourself, so that when you write “implement feature X”, the feature gets implemented in a way that makes sense in that project, is reviewed, refactored, and tested by agents, and it’s good enough to bring in a human reviewer.
The car analogy doesn’t work because you’re not the one making the code/driving the car. It drives itself, and you sometimes can propose some directions for it to steer.
The problems with llm aren’t just that sometimes your shit doesn’t work or obviously bad, that’s what you’re talking about, and that’s what minimally responsible sloperators can catch. The main problem is it writes something that looks OK to a human (that’s a criteria for it) but sometimes it’s unexpectedly idiotic in random places (because not being idiotic wasn’t a criteria). You need to check way more thoroughly for it, and you can’t use normal shortcuts that help you with it. So you obviously don’t do that.
See, that’s the issue. People letting it “drive itself” get worse results. You should be the one holding the standards and guiding the model, otherwise you will be frustrated.
Yeah, but it’s designed, purposefully, to trick people into believing you can just let it do whatever. And people do. Hense the whole problem we’re talking about.
I saw this advice too, the problem with being very detailed is a question why not use a less ambiguous languages to do it?
Why not write the explanation in language like Python. Why should I write it in English when I can say the same thing in Python and it is actually easier to do for me.
This kind of specification applies to the agent behavior or the agent behavior in a project. You don’t write it on every conversation, you write/review it once for the project or agent and let the harness include it on every conversation. You can even ask the agent to scan the codebase and pull desirable patterns out of it for future sessions.
The entire point of using an agent is to not have to write everything yourself, so that when you write “implement feature X”, the feature gets implemented in a way that makes sense in that project, is reviewed, refactored, and tested by agents, and it’s good enough to bring in a human reviewer.