Live data from Hacker News

Why agents are bad pair programmers

justin.searls.co

211–220 of 239 posts

Re: Why agents are bad pair programmers

#211
post #169

Earlier quoted context omitted.

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)

But that information is scattered. It's helpful for the LLM to cluster and isolate local reasoning that it can then "forget" about when it moves on to the next thing. Attending to nearby recent tokens is easy for it, looking up relevant information as needle in a haystack every single time is more error prone. I'm not saying asking it to remove comments will lead to a catastrophic drop off in performance, maybe something like a few percent or even less. Just that it's not useless for pure benchmaxxing.

Re: Why agents are bad pair programmers

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

my manager has been experimenting have AI first right the specs as architecture decision records (ADR), then explain how the would implement them, then slowly actually implementing with lots of breaks, review and approval/feedback. He says it's been far superior to typically agent coding but not perfect.

Re: Why agents are bad pair programmers

#213

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…

> but because it's gone off and written a 2,000 lines of code

That’s a you problem, not an AI problem. You have to give it small tasks broken down the same way you would break them down.

Re: Why agents are bad pair programmers

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

Meetings are how managers keep everyone else aligned with their goals.

Re: Why agents are bad pair programmers

#215

Earlier quoted context omitted.

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

Do you tell it to reread the file? Seems like the updates aren't in the context.

Hmm, perhaps not. I’ll have to experiment more.

Re: Why agents are bad pair programmers

#216
post #204

Earlier quoted context omitted.

Ive found similar behaviour with stopping at linting errors. I wonder if my instructions are conflicting with the agent system prompt.

System prompts themselves have many contradictions. I remember hearing an Anthropic engineer (possibly Lex Fridman's interview with Amanda Askell) talking about using exaggerated language like "NEVER" just to steer Claude to rarely do something.

that doesn't work ( atleast not anymore)

Re: Why agents are bad pair programmers

#217

Aider does everything right. Stop using Cursor or any other agentic environments. Try Aider, it works exactly as suggested here.

I prefer Claude Code (the `claude` cmd line version, with Sonnet 4) because it's more like an actual pair-programming session. It uses my claude acct rather than costing extra per token. It also hooks into all my MCP tools (shell (restricted), filesystem, ripgrep, test runners, etc. etc.) which makes it pretty amazing.

After turning off its annoying auto-commit-for-everything behavior, aider does work OK but it's harder to really get it to understand what I want during planning. Its new `--watch-files` thing is pretty darn cool though.

Re: Why agents are bad pair programmers

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

> This ensures the LLM has a complete understanding of the overall goals Forget about overall goal. I have this simple instruction that i send on every request "stop after every failing unit test and discuss implementation with me before writing source code " but it only does that about 7 times out of 10. Other times it just proceeds with implementation anyways.

So it behaves just like a person.

Re: Why agents are bad pair programmers

#219
I think the author's dislike for pair programming says a great deal more about the author than it does about pair programming or LLMs.

If you're pair programming and you're not driving, then it's your job to ask the driver to slow down so you can understand what they're doing. You may have to ask them to explain it to you. You may have to explain it back to them. This back-and-forth is what makes pairing work. If you don't do this, then of course you'll get lost.

The author seems to take the same passive position with an LLM, and the results are similar.

Re: Why agents are bad pair programmers

#220
post #189

Earlier quoted context omitted.

I guess it is tool-dependent, but do you pass in that enormous prompt on each request?

Yes, I inject multiple documents like that before every session. The documents I inject are relevant to the upcoming task. The one I shared is a variant of the “Base” document, I have specific documents per use case. If I know I’m adding features (controller actions), I inject a prompt containing documentation how to add routes, controllers, controller actions, views, etc and how to format views, what helpers are com…

Thanks!

Sorry to belabor the question, when you say "before every session", how many "things" do you do in a session? You say you give them a single task, but do you end up chatting back and forth with the agent in that session? I guess I'm unsure how far back the "context" goes in a conversation and if would drift from your directives if the conversation went back and forth too much.

Post reply on HN