Live data from Hacker News

Why agents are bad pair programmers

justin.searls.co

231–239 of 239 posts

Re: Why agents are bad pair programmers

#231

Earlier quoted context omitted.

I don't share anything with openai/anthropic that I wouldn't feel comfortable pasting into a web search prompt.

So no AI autocomplete I suppose? I assume AI autocomplete may send any part of your code base or even all of it to a third-party.

Precisely. For work projects, I only send contexts I've specified myself (so I might copy-paste a chunk, clean it, then send), I don't let AI tools pick and choose what they need.

If I were using it for some hobby project or open source thing I would probably be more open to experimenting with sending random parts of the codebase.

Re: Why agents are bad pair programmers

#232

Earlier quoted context omitted.

thats why we replaced people with machines . so we can have some predictability.

Keyword: Some

humans don't ignore an instruction 4 times out of 10 unless they have a reason to do it on purpose.

Re: Why agents are bad pair programmers

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

Sadly this just doesn't pan out in larger more complex projects. It will write an implementation plan, not follow it, then lie and say it did.

What tool and/or model are you calling "it"?

I'm using Claude Code on a large legacy monstrosity, and don't have this problem. There are problems and my flow automatically has it reviewing its own work in phased implementations, but even in the worst situations it's easy to get back on track.

Re: Why agents are bad pair programmers

#234

Earlier quoted context omitted.

Keyword: Some

humans don't ignore an instruction 4 times out of 10 unless they have a reason to do it on purpose.

I congratulate you in that you only work with humans that never misunderstand, never forget a step in a long process they think they know by heart etc.

I guess you also think that we should get rid of checklists for pilots because they would never ignore an instruction they were clearly given during training except on purpose?

Re: Why agents are bad pair programmers

#235
post #71

Earlier quoted context omitted.

How would you have handled it?

Here is how I might have handled it differently: Instead of > Meanwhile, plenty of us have found a way to enhance our productivity during deep work. No need for the patronization. you could have written > Personally, I found doing X does enhance my productivity during deep work. Why it's better: 1) cuts out the confrontation (“you're being patronizing!”), 2) offers the information directly instead of merely implying…

Thank you for your feedback, I will take it into account!

Re: Why agents are bad pair programmers

#236

Earlier quoted context omitted.

humans don't ignore an instruction 4 times out of 10 unless they have a reason to do it on purpose.

I congratulate you in that you only work with humans that never misunderstand, never forget a step in a long process they think they know by heart etc. I guess you also think that we should get rid of checklists for pilots because they would never ignore an instruction they were clearly given during training except on purpose?

> I guess you also think that we should get rid of checklists for pilots because they would never ignore an instruction they were clearly given during training except on purpose?

Pilots ignore items in checklist 4 times out of 10? wtf

Re: Why agents are bad pair programmers

#237
post #220

Earlier quoted context omitted.

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.

One task per session, sometimes split into multiple smaller tasks in the same session if they’re closely related.

Usually it’s like “implement a worker/class/module for x” (which will act as a model) and when it did that successfully (with tests and such) I commit everything and I continue the session building the GUI, since the GUI requires deep knowledge of the thing it just made.

If I tell it to make the GUI and worker at the same time, it will usually be poorly written with logic in the views rather than in a model, and it will be tested through views while I want dedicated tests for the model

Re: Why agents are bad pair programmers

#238
post #220

Earlier quoted context omitted.

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.

One task per session, sometimes split into multiple smaller tasks in the same session if they’re closely related. Usually it’s like “implement a worker/class/module for x” (which will act as a model) and when it did that successfully (with tests and such) I commit everything and I continue the session building the GUI, since the GUI requires deep knowledge of the thing it just made. If I tell it to make the GUI and w…

Ok, that makes sense. But when you continue the session building the GUI, do you run into it making mistakes because it doesn't have the earlier stuff (ie, your original directions) still in its context?

Re: Why agents are bad pair programmers

#239
post #238

Earlier quoted context omitted.

One task per session, sometimes split into multiple smaller tasks in the same session if they’re closely related. Usually it’s like “implement a worker/class/module for x” (which will act as a model) and when it did that successfully (with tests and such) I commit everything and I continue the session building the GUI, since the GUI requires deep knowledge of the thing it just made. If I tell it to make the GUI and w…

Ok, that makes sense. But when you continue the session building the GUI, do you run into it making mistakes because it doesn't have the earlier stuff (ie, your original directions) still in its context?

Sometimes but usually not anymore. Highly depends on the model, Claude Sonnet 3.7 has been the most reliable, but each model has its own quirks
Post reply on HN