Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Why agents are bad pair programmers

justin.searls.co

Post reply on HN
Print view View original

111–120 of 239 posts

Re: Why agents are bad pair programmers

#111

Post by pegasus »

shultays wrote: post #107

A week or so ago I needed to convince chatgpt that following code will indeed initialize x values in struct struct MyStruct { int x = 5; }; ... MyStruct myStructs[100]; It was insisting very passionately that you need MyStruct myStructs[100] = {}; instead. I even showed msvc assembly output and pointed to the place where it is looping & assigning all x values and then it started hallucinating about msvc not conformin…

LLM's don't have beliefs, so "convincing" them of this or that is a a waste of your time. The way to handle such cases is to start anew with a clean context and just add your insight to the prompt so that it lands on the right track from the beginning. Remember these models are ultimately just next-token predictors and anthropomorphizing them will invariably lead to suboptimal interactions.

Re: Why agents are bad pair programmers

#112

Post by mdemare »

dragonfax wrote: post #37
psadri wrote: post #36

Earlier quoted context omitted.

I usually add “discuss first. Don’t modify code yet”. Then we do some back and forth. And finally, “apply”.

Claude Code has "plan mode" for this now. It enforces this behavior. But its still poorly documented.

Claude Code denies that it has a plan mode...

Re: Why agents are bad pair programmers

#113

Post by searls »

Whenever I land on the front page, I check the comments and brace for HN coming and telling me how stupid I am and lighting me aflame in front of my peers.

But sometimes if I manage to nail the right headline, nobody reads my post and just has their own discussion, and I am spared.

Re: Why agents are bad pair programmers

#114

Post by Macha »

rhizome31 wrote: post #109
Macha wrote: post #106

Earlier quoted context omitted.

Sadly, I mean my current employer is doing the whole "tracking to see AI usage rates" and basically checking in performance reviews if people are using as much AI as the AI sales people told the CEO people need to use. We're a SaaS company so we own all our code.

Wow, really?! I had no idea that such policies existed. Quite astonishing I have to say.

Klarna, Shopify and either Google or Meta made a lot of press promoting policies like that and also the AI companies themselves are selling this kind of approach in the "how to make the best use of our tools" advice they give to execs.

Re: Why agents are bad pair programmers

#115

Post by searls »

Macha wrote: post #97
khendron wrote: post #29

When 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.

My approach has generally been to accept, refactor and reprompt if I need to tweak things. Of course this does artificially inflate the "accept rate" which the AI companies use to claim that it's writing good code, rather than being a "sigh, I'll fix this myself" moment.

I do this too and it drives me nuts. It's very obvious to me (and perhaps anyone without an incentive to maximize the accept rate) that the diff view really struggles. If you leave a large diff, copilot and cursor will both get confused and start duplicating chunks, or they'll fail to see the new (or the old) but if you accept it, it always works.

Re: Why agents are bad pair programmers

#116

Post by searls »

rsynnott wrote: post #94
bluefirebrand wrote: post #2

Pair 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’ve always seen it as primarily an _education_ tool; the purpose of pair programming isn’t that two people pair programming are more productive than two people working individually, they’re generally not. So pair programming with a magic robot seems rather futile; it’s not going to learn anything.

LLMs in their current incarnation will not, but there's nothing inherently preventing them from learning. Contexts are getting large enough that having a sidecar database living with each project or individual as a sort of corpus of "shit I learned pairing with Justin" is already completely achievable, if only a product company wanted to do that.

Re: Why agents are bad pair programmers

#117

Post by searls »

throwawayffffas wrote: post #102

In my experience the problem is not they are too fast, they are too slow. Honestly, their speed is just the right amount to make them bad. If they were faster, I could focus on following the code they are writing. But they take so much time for every edit that I tune out. On the other hand if they were slower, I could do other work while they are working, but they are done every 50 seconds to a few minutes which mean…

Yeah, I could completely see this. Reminds me of the "Slow Internet vs No Internet" oatmeal comic

Re: Why agents are bad pair programmers

#118

Post by searls »

csomar wrote: post #72
Onewildgamer wrote: post #57

Finally 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…

Also giving them more details seems to confuse them. There is probably a way around this, though. They are pretty good in finding a tiny silver of information out of the ocean. What I hate is that the industry is all geared toward the same model (chat bot). Imagine if we never invented the keyboard, mouse, GUI, touch screen, etc...

Yes, this is exactly why the "planning" approach never seems to work for me. Like every ounce of planning I do with the LLM it becomes a pound stupider at implementation time

Re: Why agents are bad pair programmers

#119

Post by searls »

tobyhinloopen wrote: post #64

This 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

Gist an example of what you mean? My experience with very large prompts and exacting custom instructions has been drastically eroded "intelligence"

Re: Why agents are bad pair programmers

#120

Post by Traster »

I think this has put into words a reason why I bounced off using AI this way, when I need something done I often have a rough idea of how I want it done, and how AI does it often doesn't match what I want, but because it's gone off and written a 2,000 lines of code it's suddenly more work for me to go through and say "Ok, so first off, strip all these comments out, you're doubling the file with trivial explanations of simple code. I don't want X to be abstracted this way, I want that...." etc. And then when I give it feedback 2,000 lines of code suddenly switch to 700 lines of completely different code and I can't keep up. And I don't want my codebase full of disjoint scripts that I don't really understand and all have weirdly different approaches to the problem. I want an AI that I have similar opinions to, which is obviously tough. It's like working with someone on their first day.

I don't know if it's giving the tools less self-confidence per se, but I think it's exposing more the design process. Like ideally you want your designer to go "Ok, I'm thinking of this approach, i'll probably have these sorts of functions or classes, this state will be owned here" and we can approve that first, rather than going straight from prompt -> implementation.

Post reply on HN