The fact that you have to “prompt-engineer” means that the tool has a terrible interface.
In your flaslight analogy, there’s an on/off button that doesn’t work. You have to flip the flashlight, tap it twice, check the batteries and flip it twice again. Then it turns on.
The fact that LLM coding tools are basically micro-managing with a special twist “knowing how to prompt”, makes it a shit tool for a lot of people. And they are justified in thinking so.
You can’t hone a skill you have little control over. It’s like a hammer that strikes a random area within a certain radius of a nail.
As for having little control, I feel like that happens in other disciplines too. The best archers need to account for the stochastic nature of wind patterns, and thus they do not always hit their intended target. But still, their accuracy is far greater than a novice. There is both skill and “luck” - if you will - involved in the process. You definitely can hone a skill you have little control over in the beginning, I believe. Maybe this is the analogy that should’ve been made.
I will say, “knowing how to prompt” feels like a weird skill, and I think the way we interface with these tools is kinda wacky. Regular text feels to fuzzy.
But it does help immensely, I find, to take every wrong agentic coding output as a learning experience. When I know the answer, and the agent failed, I ask myself why it didn’t fint it. Taking these opportunities has led me to be more proficient in the use of skill files, agent files, subagents, context window management, etc., all which have improved the agents output massively. I feel like a year ago, it was just prompting and copy-pasting (at least for me), but now, with tools like OpenCode, I can get a better looping effect with fewer errors.
A good tool is easily documentable, and then usable with said documentation.
A good tool has perfect repeatability
It is easy to predict the outcome of using a good tool.
Current LLMs have neither. For all the user knows, it’s a black box that takes input and poops out output. You can only steer the output after some output has already been given.
Context engineering is a skill analogous to communicating a problem to fellow maintainers. This typically involves articulating the issue within an issue tracker, pull request, or comment using written text. Therefore, proficiency in “prompt engineering” is essentially a measure of one’s articulacy.
So it’s not a “useful tool for coding” then, if the quality of the output depends of one’s ability to articulate in a way that tickles the LLM “the right way”.
Also, no matter how well you articulate, the output is still somewhat random. You can produce two different sections of code with (essentially) the same prompt, which also just means that theres an amount of luck and percieved randomness in a tool.
Imagine you want a piece of software written but you’re hiring it out, like a lot of corporations do. You write up a loose specification and hand it to two different dev shops and you’ll get two wildly different results. The tighter the spec, the closer the results will be.
Following my analogy with the archer, promting the right way is like accounting for wind. And again, no matter how much the best archers in the world account for wind, they do sometimes miss. Still very impressive how high their skill is, even with randomness involved. And with agentic coding, one can always shoot twice.
The fact that you have to “prompt-engineer” means that the tool has a terrible interface.
In your flaslight analogy, there’s an on/off button that doesn’t work. You have to flip the flashlight, tap it twice, check the batteries and flip it twice again. Then it turns on.
The fact that LLM coding tools are basically micro-managing with a special twist “knowing how to prompt”, makes it a shit tool for a lot of people. And they are justified in thinking so.
You can’t hone a skill you have little control over. It’s like a hammer that strikes a random area within a certain radius of a nail.
I both agree and disagree.
As for having little control, I feel like that happens in other disciplines too. The best archers need to account for the stochastic nature of wind patterns, and thus they do not always hit their intended target. But still, their accuracy is far greater than a novice. There is both skill and “luck” - if you will - involved in the process. You definitely can hone a skill you have little control over in the beginning, I believe. Maybe this is the analogy that should’ve been made.
I will say, “knowing how to prompt” feels like a weird skill, and I think the way we interface with these tools is kinda wacky. Regular text feels to fuzzy.
But it does help immensely, I find, to take every wrong agentic coding output as a learning experience. When I know the answer, and the agent failed, I ask myself why it didn’t fint it. Taking these opportunities has led me to be more proficient in the use of skill files, agent files, subagents, context window management, etc., all which have improved the agents output massively. I feel like a year ago, it was just prompting and copy-pasting (at least for me), but now, with tools like OpenCode, I can get a better looping effect with fewer errors.
I am curious about your findings
Don’t forget we are talking about a tool.
A good tool is easily documentable, and then usable with said documentation. A good tool has perfect repeatability It is easy to predict the outcome of using a good tool.
Current LLMs have neither. For all the user knows, it’s a black box that takes input and poops out output. You can only steer the output after some output has already been given.
Context engineering is a skill analogous to communicating a problem to fellow maintainers. This typically involves articulating the issue within an issue tracker, pull request, or comment using written text. Therefore, proficiency in “prompt engineering” is essentially a measure of one’s articulacy.
So it’s not a “useful tool for coding” then, if the quality of the output depends of one’s ability to articulate in a way that tickles the LLM “the right way”.
Also, no matter how well you articulate, the output is still somewhat random. You can produce two different sections of code with (essentially) the same prompt, which also just means that theres an amount of luck and percieved randomness in a tool.
Imagine you want a piece of software written but you’re hiring it out, like a lot of corporations do. You write up a loose specification and hand it to two different dev shops and you’ll get two wildly different results. The tighter the spec, the closer the results will be.
It’s not much different from that.
Indeed. I agree that it’s not a tool, but a type of outsourcing.
Following my analogy with the archer, promting the right way is like accounting for wind. And again, no matter how much the best archers in the world account for wind, they do sometimes miss. Still very impressive how high their skill is, even with randomness involved. And with agentic coding, one can always shoot twice.