Live data from Hacker News

Why agents are bad pair programmers

justin.searls.co

171–180 of 239 posts

Re: Why agents are bad pair programmers

#171
post #69
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.

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

I only took issue with ", sorry." The rest of it I was fine with. I definitely didn't need to match their energy so much though, I should have toned it down. Also, the No true Scotsman was about deep work, not being a programmer, but otherwise yeah. I didn't mean to be insulting but I could have done better :)

Re: Why agents are bad pair programmers

#172
post #169

Earlier quoted context omitted.

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

I usually use huge context/prompt documents (10-100K tokens) before doing anything, I suppose that helps.

I’ll experiment with comments, I can always delete them later. My strategy is to have self-documenting code (and my prompts include a how-to on self-documenting code)

Re: Why agents are bad pair programmers

#173

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…

> I want an AI that I have similar opinions to, which is obviously tough. It's like working with someone on their first day.

Most of what you're describing does apply to humans on the first day, and ais on their first day. If you aren't capturing these preferences somewhere and giving it to either a human or the ai, then why would they somehow know your preferences? For ai, the standard thats forming is you create some markdown file(s) with these so they only need to be explained once, and auto provided as context.

Re: Why agents are bad pair programmers

#174
> give up on editor-based agentic pairing in favor of asynchronous workflows like GitHub's new Coding Agent, whose work you can also review via pull request

Why not just review the agent's work before making a git commit?

Re: Why agents are bad pair programmers

#175
post #146

Earlier quoted context omitted.

Just like with human engineers, you need to start with a planning session. This involves a back and forth discussion to hammer out the details before writing any code. I start off as vague as possible to see if the LLM recommends anything I hadn't thought of, then get more detailed as I go. When I'm satisfied, I have it create 2 documents, initialprompt.txt and TODO.md. The initial prompt file includes a summary of t…

In essence, I need to schedule a meeting with the LLM and 'hammer out a game plan.' Gotta make sure we're 'in sync' and everybody's 'on the same page.' Meeting-based programming. No wonder management loves it and thinks it should be the future.

LLMs are stealing the jobs of developers who go off half-cocked and spend three days writing 2000 lines of code implementing the wrong feature instead of attending a 30 minute meeting

Re: Why agents are bad pair programmers

#176

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

> you can simply ask them to do things a different way

Instead of a writing a blog post about how they didn't guess how you wanted things done?

Re: Why agents are bad pair programmers

#177

Earlier quoted context omitted.

I do notice though that if I edit what it wrote before accepting it, and then it sees it (either because I didn’t wait for it to finish or because I send it another message), it will overwrite my changes with what it had before my changes every single time, without fail. (Zed with Claude 4)

Interesting. I always wait for it to finish with my workflow.

It does it even if I wait for it to finish, but don't accept. Eg:

Starting code: a quick brown fox

prompt 1: "Capitalize the words"

AI: A Quick Brown Fox

I don't accept or reject, but change it to "A Quick Red Fox"

prompt 2: "Change it to dog"

AI: A Quick Brown Dog

Re: Why agents are bad pair programmers

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

This is kind of intentionally the flow with Claude code as I’ve experienced it.

I’m in VSCode doing my thing, and it’s in a terminal window that occasionally needs or wants my attention. I can go off and be AI-Free for as long as I like.

Re: Why agents are bad pair programmers

#179
post #89

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 was trying out sonnet 4 yesterday and it spent 15 minutes changing testing changing etc just to get one config item changed. It ended up changing 40 files for no reason. Also kept trying to open a debugger that didn’t exist and load a webpage that requires auth. They’re far from perfect that’s for sure.

I don’t think anyone seriously is claiming perfect. The thing is all of AI is moving 5 times faster than any disrupting tech before it.

We went from proof reading single emails to researching agentic coding in a year.

It should have been five.

Re: Why agents are bad pair programmers

#180
post #175

Earlier quoted context omitted.

In essence, I need to schedule a meeting with the LLM and 'hammer out a game plan.' Gotta make sure we're 'in sync' and everybody's 'on the same page.' Meeting-based programming. No wonder management loves it and thinks it should be the future.

LLMs are stealing the jobs of developers who go off half-cocked and spend three days writing 2000 lines of code implementing the wrong feature instead of attending a 30 minute meeting

and the jobs of developers that want to schedule another breakout session to discuss the pros and cons of a 2-line change.
Post reply on HN