Earlier quoted context omitted.
I'm open to hearing how being honest with them about their negative approach is patronizing them.
Calling someone "on the first peak of the Dunning-Kruger curve" is patronizing them.
How would you have handled it?
Why agents are bad pair programmers
61–70 of 239 posts
Re: Why agents are bad pair programmers
#62Earlier quoted context omitted.
For what it’s worth, the deepest-thinking and most profound programmers I have met—hell, thinkers in general—have a peculiar tendency to favour pen and paper. Perhaps because once their work is recognised, they are generally working with a team that can amplify them without needing to interrupt their thought flow.
Ha, I would count myself among those if my handwriting wasn't so terrible and I didn't have bad arthritis since my youth. I still reach for pen and paper on the go or when I need to draw something out, but I've gotten more productive using an outliner on my laptop, specifically Logseq. I think there's still room for thought augmentation via LLMs here. Years back when I used Obsidian, I created probably the first or s…
[deleted]
Re: Why agents are bad pair programmers
#63When I first tried an LLM agent, I was hoping for an interactive, 2-way, pair collaboration. Instead, what I got was a pairing partner who wanted to do everything themselves. I couldn't even tweak the code they had written, because it would mess up their context. I want a pairing partner where I can write a little, they write a little, I write a little, they write a little. You know, an actual collaboration.
You can totally do that. Just tell it to.
If you want an LLM to do something, you have to explain it. Keep a few prompt docs around to load every conversation.
Re: Why agents are bad pair programmers
#64This guy needs a custom prompt. I keep a prompt doc around that is constantly updated based on my preferences and corrections.
Not a few sentences but many many lines of examples and documentation
Re: Why agents are bad pair programmers
#65LLM agents don't know how to shut up and always think they're right about everything. They also lack the ability to be brief. Sometimes things can be solved with a single character or line, but no they write a full page. And, they write paragraphs of comments for even the most minuscule of changes. They talk at you, are overbearing and arrogant.
I expect a lot of the things people don't like ("output too long, too many comments in code") are side effects of making the LLM good in other areas. Long output correlates with less laziness when writing code, and higher performance on benchmarks due to the monotone relationship between number of output tokens and scores. Comment spam correlates with better performance because it's locally-specific reasoning it can…
Just add to the prompt not to include comments and to talk less.
I have a prompt document that includes a complete summary of the Clean Code book, which includes the rules about comments.
You do have to remind it occasionally.
Re: Why agents are bad pair programmers
#66Pair programming is also not suitable for all cases Maybe not for many cases I mentioned this elsewhere but I find it absolutely impossible to get into a good programming flow anymore while the LLM constantly interrupts me with suggested autocompletes that I have to stop, read, review, and accept/reject It's been miserable trying to incorporate this into my workflow
I recently got a new laptop and had to setup my IDE again. After a couple hours of coding something felt "weird" - turns out I forgot to login to GitHub Copilot and I was working without it the entire time. I felt a lot more proactive and confident as I wasn't waiting on the autocomplete. Also, Cursor was exceptional at interrupting any kind of "flow" - who even wants their next cursor position predicted? I'll probab…
Same, I like agents or nothing in between.
Re: Why agents are bad pair programmers
#67Earlier quoted context omitted.
I don't believe you experience deep work the same way I do then In my mind you cannot do deep work while being interrupted constantly, and LLM agents are constant interruptions
You can do better than a No true Scotsman fallacy. The fact is that not everyone works the same way you do, or interacts the same way with agents. They are not constant interruptions if you use them correctly. Essentially, this is a skill issue and you're at the first peak of the Dunning–Kruger curve, sooner ready to dismiss those with more experience in this area as being less experienced, instead of keeping an open…
> You could have asked for tips since I said I've found a way to work deeply with them
How do you work deeply with them? Looking for some tips.
Re: Why agents are bad pair programmers
#68Re: Why agents are bad pair programmers
#69Earlier quoted context omitted.
You can do better than a No true Scotsman fallacy. The fact is that not everyone works the same way you do, or interacts the same way with agents. They are not constant interruptions if you use them correctly. Essentially, this is a skill issue and you're at the first peak of the Dunning–Kruger curve, sooner ready to dismiss those with more experience in this area as being less experienced, instead of keeping an open…
It’s quite amusing to see you complain about patronisation, and then see you turn about and do it yourself one comment later.
As an observer to this conversation, I can't help but notice that both have a good point here.
Soulofmischief’s main point is that meesles made an inappropriate generalization. Meesles said that something was impossible to do, and soulofmischief pointed out that you can't really infer that it's impossible for everyone just because you couldn't find a way. This is a perfectly valid point, but it wasn't helped by soulofmischief calling the generalization “patronizing”.
Bluefirebrand pushed back on that by merely stating that their experience and intuition match those of meesles, but soulofmischief then interpreted that as implying they're not a real programmer and called it a No True Scotsman fallacy.
It went downhill from there with soulofmischief trying to reiterate their point but only doing so in terms of insults such as the Dunning-Kruger line.
Re: Why agents are bad pair programmers
#70Finally someone said it, they're overconfident in their approach, don't consult us with the details of the implementation, they're trained to create mock APIs that don't follow structure, leading to lot of rework. The LLM actions should be measured, collaborative, ask for details when it's not present. It is impossible to give every single detail in the initial prompt, and a follow up prompt derails the train thought…
Most stacks now support some form of "plan" workflows. You'd want to first do this, and see if it improves your experience.
One workflow that works well for me, even with small local models, is to start a plan session with something like: "based on @file, and @docs and @examples, I'd like to _ in @path with the following requirements @module_requirements.md. Let's talk through this and make sure we have all the info before starting to code it."
Then go back and forth, make sure everything is mentioned, and when satisfied either put it into a .md file (so you can retry the coding flow later) or just say "ok do it", and go grab a cup of coffee or something.
You can also make this into a workflow with .rules files or .md files, have a snippets thing from your IDE drop this whenever you start a new task, and so on. The idea with all the advancements in LLMs is that they need lots of context if you want them to be anything other than what they were trained on. And you need to try different flows and see what works on your specific codebase. Something that works for projectA might not work for projectB ootb.