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

41–50 of 239 posts

Re: Why agents are bad pair programmers

#41

Post by soulofmischief »

hnthrowaway121 wrote: post #35
soulofmischief wrote: post #22

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

Analysis in the last 5-10 years has shown the Dunning-Kruger effect may not really exist. So it’s a poor basis on which to be judgmental and condescending.

> judgmental and condescending

pushing back against judgement and condescension is not judgemental and condescending.

> may not really exist

I'm open to reading over any resources you would like to provide, maybe it's "real", maybe it isn't, but I have personally both experienced and witnessed the effect in myself, other individuals and groups. It's a good heuristic for certain scenarios, even if it isn't necesarily generalizable.

Re: Why agents are bad pair programmers

#44

Post by soulofmischief »

JumpCrisscross wrote: post #32
soulofmischief wrote: post #22

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

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 second copilot-for-Obsidian plugin and I found it very helpful, even though GPT-3 was generally pretty awful. I still find myself in deep flow, thinking in abstract, working alongside my agent to solve deep problems in less time than I otherwise would.

Re: Why agents are bad pair programmers

#45

Post by almosthere »

__MatrixMan__ wrote: post #38

I've been considering a... protocol? for improving this. Consider this repo: foo.py bar.py bar.py.vibes.md This would indicate that foo.py is human-written (or at least thoroughly reviewed by a human), while bar.py is LLM written with a lower bar of human scrutiny. bar.py.vibes.md would contain whatever human-written guidance describes how bar should look. It could be an empty file, or a few paragraphs, or it it coul…

I think coding will eventually go away in favor of models with metadata built around them.

How many times did you have a mutation operation where you had to hand code the insert of 3 or 4 entities and make sure they all come back successful, or you back out properly (and perhaps this is without a transaction, perhaps over multiple databases).

Make sure the required fields are present Grab the created inserted ID Rinse, repeat

Or if you're mutating a list, writing code that inserts a new element, but you don't know which one is new. And you end up, again, hand coding loops and checking what you remember to check.

What about when you need to do an auth check.

And the hand coder may fail to remember one little thing somewhere.

With LLM code, you can just describe that function and it will remember to do all the things.

An LLM with a model + metadata - we won't really need to think of it as editing User.java or User.py anymore. Instead User.yaml - and the LLM will just consume that, and build out ALL of your required biz-logic, and be done with it. It could create a fully authenticating/authorizing REST API + GraphQL API with sane defaults - and consistent notions throughout.

And moving into UIs- we can have the same thing. The UI can be described in an organized way. What fields are required for user registration. What fields are optional according to the backend. It's hard to visualize this future, but I think it's a no-code future. It's models of requirements instead.

Re: Why agents are bad pair programmers

#46

Post by jcranmer »

soulofmischief wrote: post #39
girvo wrote: post #30

Earlier quoted context omitted.

It’s quite amusing to see you complain about patronisation, and then see you turn about and do it yourself one comment later.

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.

Re: Why agents are bad pair programmers

#47

Post by icedchai »

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.

Have you tried recently? This hasn't been my experience. I modify the code it's written, then ask it to reread the file. It generally responds "I see you changed file and [something.]" Or when it makes a change, I tell it I need to run some tests. I provide feedback, explain the problem, and it iterates. This is with Zed and Claude Sonnet.

Re: Why agents are bad pair programmers

#48

Post by thallada »

8note wrote: post #25
bluefirebrand wrote: post #20

Earlier 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

[flagged]

Everyone knows real programmers only need to use a butterfly.

Re: Why agents are bad pair programmers

#49

Post by carpo »

psadri wrote: post #36
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.

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

Same. I use /ask in Aider so I can read what it's planning, ask follow-up questions, get it to change things, then after a few iterations I can type "Make it so" while sitting back to sip on my Earl Grey.

Re: Why agents are bad pair programmers

#50

Post by mock-possum »

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.

In all honesty - have you tried doing what you would do with a paired programmer - that is, talk to them about it? Communicate? I’ve never had trouble getting cursor or copilot to chat with me about solutions first before making changes, and usually they’ll notice if I make my own changes and say “oh, I see you already added XYZ, I’ll go ahead and move on to the next part.”
Post reply on HN