Live data from Hacker News

Why agents are bad pair programmers

justin.searls.co

51–60 of 239 posts

Re: Why agents are bad pair programmers

#51

Earlier quoted context omitted.

> I use an LLM as a reference (on-demand), and don't use agents (yet) This was me until about three weeks ago. Then, during a week of holiday, I decided I didn't want to get left behind and tried a few side-projects using agents -- specifically I've been using Roo. Now I use agents when appropriate, which I'd guess is about 50% of the work I'm doing.

Roo looks interesting. How does it compare with Cursor and Windsurf?

It burns tokens if you BYOK but you can hook into GH Copilot LLMs directly

I really like the orchestrator and architect personas as is out of the box. I prefer it over Cursor / Windsurf for a few reasons - no indexing (double edged sword) - orchestrator I find much more useful than windsurf cascades - tool usage is fantastic

The no indexing is a double edged sword, it does need to read files constantly, contributing to token burn. However, you don't have to worry about indexed data being on a 3rd party server (cursor), and also since it has to crawl to understand the codebase for it to implement, to me it seems like it is more capable of trickier code implementations, as long as you utilize context properly.

For more complex tasks, I usually either spend 20-30 minutes writing a prompt to give it what I'm looking to implement, or write up a document detailing the approach I'd like to take and iterate with the architect agent.

Afterwards, hand it off to the orchestrator and it manages and creates subtasks, which is to provide targeted implementation steps / tasks with a fresh context window.

If you have a GH Copilot license already, give it a shot. I personally think it's a good balance between control as an architect and not having to tie my time down for implementations, since really a lot of the work in coding is figuring out the implementation plan anyways, and the coding can be busy work, to me personally anyways. I prefer it over the others as I feel Windsurf/Cursor encourages YOLO too much.

Re: Why agents are bad pair programmers

#53

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

AI "auto-complete" or "code suggestions" is the worst, especially if you are in a strongly-type language because it's 80% correct and competing with an IDE that can be 100% correct.

AI agents are much better for me because 1) they don't constantly interrupt your train of thought and 2) they can run compile, run tests, etc. to discover they are incorrect and fix it before handing the code back to you.

Re: Why agents are bad pair programmers

#54

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 love the autocomplete, honestly use it more than any other AI feature.

But I'm forced to write in Go which has a lot of boilerplate (and no, some kind of code library or whatever would not help... it's just easier to type at that point).

It's great because it helps with stuff that's too much of a hassle to talk to the AI for (just quicker to type).

I also read very fast so one line suggestions are just instant anyway (like non AI autocomplete), and longer ones I can see if it's close enough to what I was going to type anyway. And eventually it gets to the point where you just kinda know what it's going to do.

Not an amazing boost, but it does let me be lazy writing log messages and for loops and such. I think you do need to read it much faster than you can write it to be helpful though.

Re: Why agents are bad pair programmers

#55
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.

They should add a “cmd-enter” for ask, and “enter” to go.

Separately, if I were at cursor (or any other company for that matter), I’d have the AI scouring HN comments for “I wish x did y” suggestions.

Re: Why agents are bad pair programmers

#56

LLM 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 attend on when writing the next line of code, leading to reduced errors.

Re: Why agents are bad pair programmers

#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 and design of the application.

I don't know if I'm using it right, I'd love to know more if that's the case. In a way the LLM should improve on being iterative, take feedback, maybe it's a hard problem to add/update the context. I don't know about that either, but love to learn more.

Re: Why agents are bad pair programmers

#58
post #4

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

Second this. My solution is to have a 'non-AI' IDE and then a Cursor/VS Code to switch between. Deep work cannot be achieved by chatting with the coding bots, sorry.

I do this as well and it works quite well for me like that!

Additionally, when working on microservices and on issues that don’t seem too straightforward, I use o3 and copy the whole code of the repo into the prompt and refine a plan there and then paste it as a prompt into cursor. Handy if you don’t have MAX mode, but a company-sponsored ChatGPT.

Re: Why agents are bad pair programmers

#59

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…

[dead]

Re: Why agents are bad pair programmers

#60
post #8

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

> Also, Cursor was exceptional at interrupting any kind of "flow" - who even wants their next cursor position predicted?

Me, I use this all the time. It’s actually predictable and saves lots of time when doing similar edits in a large file. It’s about as powerful as multi-line regex search and replace, except you don’t have to write the regex.

Post reply on HN