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

161–170 of 239 posts

Re: Why agents are bad pair programmers

#161

Post by [deleted] »

mock-possum wrote: post #50
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.”

[deleted]

Re: Why agents are bad pair programmers

#162

Post by afavour »

jstummbillig wrote: post #145
Traster wrote: post #120

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

People are thinking too much of humans and LOCs as something valuable or worth their consideration when working with AI (because usually that LOCs would have required human effort). This is simply not the case when doing AI coding, and you need to adjust how you work because of that and play to the strengths of this setup, if you want to get something out of it and not frustrate yourself. Here is how to do this: Have…

> LOCs as something valuable or worth their consideration when working with AI (because usually that LOCs would have required human effort)

At this point AI generated code absolutely requires review by a human so LOC is still an important metric.

Re: Why agents are bad pair programmers

#163

Post by tristor »

Traster wrote: post #120

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

> It's like working with someone on their first day.

This matches my experience exactly, but worse than working with a human on their first day, day 100 for an AI is still like working with them on their first day. Humans have effectively infinite context windows over a long enough period of time, AIs context windows are so constrained that it's not worthwhile to invest the effort to 'teach' it like you would a junior engineer.

Re: Why agents are bad pair programmers

#164

Post by rlewkov »

iamkoch wrote: post #139
Traster wrote: post #120

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

This absolutely captures my experience. My successful AI written projects are those where I care solely on the output and have little to no knowledge about the subject matter. When I try to walk an agent through creating anything about which I have a deeply held opinion of what good looks like, I end up frustrated and abandoning the project. I've enjoyed using roo code's architect function to document an agreed upon…

> "This leads me to conclude that using AI to write code that a(nother) human is one day to interact with is a no-go, for all the reasons listed." So, if one's goal is to develop code that is easily maintainable by others, do you think that AI writing code gets in the way of that goal?

Re: Why agents are bad pair programmers

#165

Post by jeffrallen »

searls wrote: post #115
Macha wrote: post #97

Earlier quoted context omitted.

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.

Aider solves this by turn-taking. Each modification is a commit. If you hate it, you can undo it (type /undo, it does the git reset --hard for you). If you can live with the code but want to start tweaking it, do so, then /commit (it makes the commit message for you by reading the diffs you made). Working I turns, by commits, Aider can see what you changed and keep up with you. I usually squash the commits at the end, because the wandering way of correcting the AI is not really useful history.

Re: Why agents are bad pair programmers

#166

Post by bakkoting »

Traster wrote: post #120

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

Anthropic's guide to using Claude Code [1] is worth reading.

Specifically, their recommended workflow is "first ask it to read the code, then ask it to make a plan to implement your change, then tell it to execute". That sounds like the workflow you're asking for - you can read its plan and make adjustments before it writes a single line of code.

One of the weird things about using agents is that if they're doing things in a way you don't like, including things like writing code without first running the design by you, you can simply ask them to do things a different way.

[1] https://www.anthropic.com/engineering/claude-code-best-pract...

Re: Why agents are bad pair programmers

#167

Post by cmrdporcupine »

Article has some good points. They move fast, and they can easily run off the rails if you don't watch carefully.

And I've found that it's just as mentally exhausting programming alongside one as it is doing it yourself.

The chief advantage I've found of working alongside Claude is its automation of tedious (to me) tasks.

Re: Why agents are bad pair programmers

#168

Post by cmrdporcupine »

thallada wrote: post #48
8note wrote: post #25

Earlier quoted context omitted.

[flagged]

Everyone knows real programmers only need to use a butterfly.

If you've opened your eyes, it's not deep work.

Deep work happens in a sensor deprivation tank. And you have to memorize everything you thought through, and write it down (with quill pen) after you emerge.

Anything else isn't really deep. Sorry, you posers.

Re: Why agents are bad pair programmers

#169

Post by danans »

tobyhinloopen wrote: post #151
energy123 wrote: post #93

Earlier quoted context omitted.

You can, but I would expect code correctness to be reduced, you're removing one mechanism the model uses to dump local reasoning immediately prior to where it's needed.

With that logic, I should ask the AI to _increase_ the amount of comments. I highly doubt the comments it generates are useful, they're usually very superficial.

Perhaps not useful to you, but they are the only way the LLM has to know what it is doing.

It has to reason about the problem in its output, since its output comprises almost the entirety of its "awareness". Unlike you, the LLM doesn't "know" anything, even superficial things.

In some sense it's like us when we are working on a problem with lots of novel parts. We usually have to write down notes to refer to in the process of solving the problem, except for the LLM the problem is always a novel problem.

Re: Why agents are bad pair programmers

#170

Post by jstummbillig »

Sharlin wrote: post #148
jstummbillig wrote: post #145

Earlier quoted context omitted.

People are thinking too much of humans and LOCs as something valuable or worth their consideration when working with AI (because usually that LOCs would have required human effort). This is simply not the case when doing AI coding, and you need to adjust how you work because of that and play to the strengths of this setup, if you want to get something out of it and not frustrate yourself. Here is how to do this: Have…

This approach is essentially the PR workflow preferred by the author. Why let an LLM make huge changes to your working copy just for you to revert them next, instead of just writing patches to be asynchronously reviewed? What you propose is no way of doing pair programming in particular, and seems to support the author’s argument.

1. There is not a mention of "pair programming" in the comment I was addressing. As often happens, the discussion evolves.

2. The point is, that you are training the AI through this process. You can do pair programming afterwards (or not). Aim to instruct it to give you ballpark answers first, and take it from there.

Post reply on HN