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

151–160 of 239 posts

Re: Why agents are bad pair programmers

#151

Post by tobyhinloopen »

energy123 wrote: post #93
tobyhinloopen wrote: post #65

Earlier quoted context omitted.

Just add to the prompt not to include comments and to talk less. I have a prompt document that includes a complete summary of the Clean Code book, which includes the rules about comments. You do have to remind it occasionally.

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.

Re: Why agents are bad pair programmers

#152

Post by tobyhinloopen »

searls wrote: post #119
tobyhinloopen wrote: post #64

This guy needs a custom prompt. I keep a prompt doc around that is constantly updated based on my preferences and corrections. Not a few sentences but many many lines of examples and documentation

Gist an example of what you mean? My experience with very large prompts and exacting custom instructions has been drastically eroded "intelligence"

Many of my prompts include _somewhat_ sensitive details because they're tailor-made for each project. This is a more generic prompt I've been using for my code generation tool:

https://gist.github.com/tobyhinloopen/e567d551c9f30390b23a0a...

More about this prompt:

https://bonaroo.nl/2025/05/20/enforced-ai-test-driven-develo...

Lately, I've been letting the agent write the prompt by ordering it to "update the prompt document with my expressed preferences and code conventions", manually reviewing the doc. Literally while writing this comment, I'm waiting for the agent to do:

> note any findings about this project and my expressed preferences and write them to a new prompt document in doc, named 20250610-.md

I keep a folder of prompt documents because there's so many of them (over 30 as of writing this comment, for a single project). I have more generic ones and more specific ones, and I usually either tell the agent to find relevant prompt documents or tell the agent to read the relevant ones.

Usually over 100K tokens is spent on reading the prompts & documentation before performing any task.

Here's a snippet of the prompt doc it just generated:

https://gist.github.com/tobyhinloopen/c059067037a6edb19065cd...

I'm experimenting a lot with prompts, I have yet to learn what works and what doesn't, but one thing is sure: A good prompt makes a huge difference. It's the difference between constantly babysitting and instructing the agent and telling it to do something and waiting for it to complete.

I had many MRs merged with little to no post-prompt guidance. Just fire and forget, commit, read the results, manually test it, and submit as MR. While the code is usually somewhere between "acceptable" and "obviously AI written", it usually works just fine.

Re: Why agents are bad pair programmers

#153

Post by johnisgood »

shultays wrote: post #130
johnisgood wrote: post #124

Earlier quoted context omitted.

That is not even valid C code, so you would have to seriously convince me, too. What makes it invalid is "= 5", and lack of "struct" before "MyStruct" (could have used typedef).

It is a c++ code.

I think the point flew by a few.

Re: Why agents are bad pair programmers

#154

Post by jamil7 »

I think one huge issue with pairing for non programmers or junior programmers is that the LLM never pushes back on whatever you throw at it. Like it can't deconstruct and examine what that acutal problem and suggest a more robust or simplar alternative.

Re: Why agents are bad pair programmers

#155

Post by pbhjpbhj »

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.

I've asked for hints/snippets to give ideas and then implemented what I wanted myself (not commercially). Worked OK for me.

Re: Why agents are bad pair programmers

#156

Post by hk1337 »

bluefirebrand wrote: post #2

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

> Pair programming is also not suitable for all cases

I think this is true but pair programming can work for most circumstances.

The times where it doesn't work is usually because one or both parties are not all-in with the process. Either someone is skeptical about pair programming and thinks it never works or they're trying to enforce a strict interpretation of pair programming.

Re: Why agents are bad pair programmers

#157

Post by sltr »

> to ask a clarifying question

I think one shortfall of LLMs is their reluctance to ask clarifying questions. From my own post [1]:

> LLMs are poor communicators, so you have to make up the difference. Unlike a talented direct report, LLMs don't yet seem generally able to ask the question-behind-the-question or to infer a larger context behind a prompt, or even ask for clarification.

[1] https://www.slater.dev/dev-skills-for-the-llm-era/

Re: Why agents are bad pair programmers

#158

Post by bluefirebrand »

hk1337 wrote: post #156
bluefirebrand wrote: post #2

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

> Pair programming is also not suitable for all cases I think this is true but pair programming can work for most circumstances. The times where it doesn't work is usually because one or both parties are not all-in with the process. Either someone is skeptical about pair programming and thinks it never works or they're trying to enforce a strict interpretation of pair programming.

It doesn't work when someone already has a solution in mind and all they need to do is type it into the editor

I've been doing this a while. This is most of my work

Re: Why agents are bad pair programmers

#159

Post by __MatrixMan__ »

almosthere wrote: post #45
__MatrixMan__ wrote: post #38

I've been considering a... protocol? for improving this. Consider this repo: foo.py bar.py bar.py.vibes.md This would indicate that foo.py is human-written (or at least thoroughly reviewed by a human), while bar.py is LLM written with a lower bar of human scrutiny. bar.py.vibes.md would contain whatever human-written guidance describes how bar should look. It could be an empty file, or a few paragraphs, or it it coul…

I think coding will eventually go away in favor of models with metadata built around them. How many times did you have a mutation operation where you had to hand code the insert of 3 or 4 entities and make sure they all come back successful, or you back out properly (and perhaps this is without a transaction, perhaps over multiple databases). Make sure the required fields are present Grab the created inserted ID Rins…

What do you suppose that metadata is going to look like if not partially complete code where the LLM fills in the gaps?

Re: Why agents are bad pair programmers

#160

Post by globnomulous »

34679 wrote: post #146
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…

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.

Post reply on HN