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

191–200 of 239 posts

Re: Why agents are bad pair programmers

#191

Post by aerhardt »

Macha wrote: post #106
rhizome31 wrote: post #104

Earlier quoted context omitted.

Thank you for the reply. What do you mean by "AI mandates"? Does it mean your company has an explicit policy allowing sharing code with AI services?

Sadly, I mean my current employer is doing the whole "tracking to see AI usage rates" and basically checking in performance reviews if people are using as much AI as the AI sales people told the CEO people need to use. We're a SaaS company so we own all our code.

I just puked in my mouth a little. Sorry to hear you're being subjected to that.

Re: Why agents are bad pair programmers

#192

Post by Horde »

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…

There is an old issue, that's related, why one should avoid using equality relations in AI used for creating a proof. It will go back and forth and fill the log with trivial statements before it comes to the right proof path. This might end up being the majority of the proof and could be an unbounded part. Then somebody has to read that and spend a good deal of time deciding what's trivial and what isn't. Whereas if you remove equality, you have something that isn't very natural.

Re: Why agents are bad pair programmers

#193

Post by aerhardt »

tobyhinloopen wrote: post #65
energy123 wrote: post #56

Earlier quoted context omitted.

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…

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.

I have added it in the guidelines doc for Junie and that won't stop it. It can't help itself - it needs to write a comment every three lines, no matter the language it's writing in.

Re: Why agents are bad pair programmers

#195

Post by avandekleut »

apwell23 wrote: post #190
34679 wrote: 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.

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

Re: Why agents are bad pair programmers

#196

Post by chermi »

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…

I prompt it to come up with 3 potential implementation plans, choose which one it thinks is best, and explain its plan to me before it does anything. I also ask it to enumerate which files/functions it will modify in its chosen plan. Then you can give feedback on what it thinks and have it come up with a new plan if you don't like it. Every bit of context and constraints you give it helps. Having a design doc + a little description of your design/code "philosophy" helps. This is easy to do in cursor with rules, I'm guessing other tools have a similar feature. Also, if there's a somewhat similar feature implemented already or if you have a particular style, tell it to reference example files/code snippets.

Re: Why agents are bad pair programmers

#197

Post by tobyhinloopen »

aerhardt wrote: post #193
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.

I have added it in the guidelines doc for Junie and that won't stop it. It can't help itself - it needs to write a comment every three lines, no matter the language it's writing in.

Hah the need to add comments is pretty resilient, that’s true.

Re: Why agents are bad pair programmers

#198

Post by tobyhinloopen »

cadr wrote: post #189
tobyhinloopen wrote: post #152

Earlier quoted context omitted.

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

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 commonly used.

If I’m working on APIs, I have API specific prompts. If I’m working on syncs with specific external services, I have prompts containing the details about these services.

Basically I consider every session a conversation with a new employee. I give them a single task and include all the relevant documentation and guidelines and wish them good luck.

Sometimes it takes a while, but I generally have a second issue to work on, in parallel. So while one agent is fixing one issue, I prepare the other agent to work on the second. Very occasionally I have 3 sessions running at the same time.

I barely write code anymore. I think I’ve not written a single line of code in the last few work days. Almost everything I submit is written by AI, and every time I have to guide the LLM and I expect the mistake to be repeated, I expand the relevant prompt document.

Last few days I also had the LLM update the prompt documents for me since they’re getting pretty big.

I do thoroughly review the code. The generated code is different from how I would write it, sometimes worse but sometimes better.

I also let it write tests, obviously, and I have a few paragraphs to write happy flow tests and “bad flow” tests.

I feel like I’m just scratching the surface of the possibilities. Im writing my own tools to further automate the process, including being able to generate code directly on production and have different versions of modules running based on the current user, so I can test new versions and deploy them instantly to a select group of users. This is just a wild fantasy I have and I’m sure I will find out why it’s a terrible idea, but it doesn’t stop me from trying.

Re: Why agents are bad pair programmers

#199

Post by thoughtpalette »

searls wrote: post #113

Whenever I land on the front page, I check the comments and brace for HN coming and telling me how stupid I am and lighting me aflame in front of my peers. But sometimes if I manage to nail the right headline, nobody reads my post and just has their own discussion, and I am spared.

Hilarious but realistic take. I've noticed a similar trend with other posts. I'm a fan of the discourse either way tbh.

Re: Why agents are bad pair programmers

#200

Post by Bob_LaBLahh »

UltraSane wrote: post #108
Bob_LaBLahh wrote: post #85

Earlier quoted context omitted.

In my experience, LLMs are idiot savant coders--but currently more idiot than savant. Claude 3.7 (via cursor and roo) can comment code well, create a starter project 10x faster than I could, and they spit out common crud apps pretty well. However I've come to the conclusion that LLMs are terrible at decision making. I would much rather have an intern architect my code than let AI do it. It's just too unreliable. It s…

LLMs currently can generate a few thousand lines of coherent code but they cannot write a cohesive large scale code base. But LLMs are very good at writing SQL and Cypher queries that I would spend hours or days figuring out how to write.

Agreed.

I find it interesting that LLMs seem pretty good at spitting out SQL that works well enough. But on the other hand LLMs seem pretty awful at working with CSS. I wonder if this is due to a difference in the amount of training data available for SQL vs CSS, or is this because CSS is a finicky pain in the ass when compared to SQL.

Post reply on HN