News for hackers. Stuff that matters.
Re:Why agents are bad pair programmers by 34679 on Tuesday June 10, 2025 @09:38AM (#44236678)
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 the project along with instructions to read the to do file and mark each step as complete after finishing it.

This ensures the LLM has a complete understanding of the overall goals, along with a step by step list of tasks to get there. It also allows me to quickly get the LLM back up to speed when I need to start a new conversation due to context limits.

Re:Why agents are bad pair programmers by globnomulous on Tuesday June 10, 2025 @10:50AM (#44237513)
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.

Re:Why agents are bad pair programmers by woah on Tuesday June 10, 2025 @01:09PM (#44239099)
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 by hnthrow90348765 on Tuesday June 10, 2025 @01:45PM (#44239396)
That's dumb, of course, but sometimes people really just do the bare minimum to describe what they want and they can only think clearly once there's something in front of them. The 2000 lines there should be considered a POC, even at 2000 lines.
Re:Why agents are bad pair programmers by devmor on Tuesday June 10, 2025 @01:38PM (#44239335)
and the jobs of developers that want to schedule another breakout session to discuss the pros and cons of a 2-line change.
Re:Why agents are bad pair programmers by ge96 on Tuesday June 10, 2025 @01:58PM (#44239509)
Yeah... I'm gonna need to circle back on that
Re:Why agents are bad pair programmers by dowager_dan99 on Tuesday June 10, 2025 @05:18PM (#44241562)
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 by ben_w on Tuesday June 10, 2025 @05:23PM (#44241600)
Meetings are how managers keep everyone else aligned with their goals.
Re:Why agents are bad pair programmers by apwell23 on Tuesday June 10, 2025 @02:34PM (#44239875)
> 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.

Re:Why agents are bad pair programmers by avandekleut on Tuesday June 10, 2025 @02:49PM (#44240041)
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 by kenfox on Tuesday June 10, 2025 @03:54PM (#44240761)
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.
Re:Why agents are bad pair programmers by apwell23 on Tuesday June 10, 2025 @05:52PM (#44241876)
that doesn't work ( atleast not anymore)
Re:Why agents are bad pair programmers by jyounker on Tuesday June 10, 2025 @06:41PM (#44242299)
So it behaves just like a person.
Re:Why agents are bad pair programmers by apwell23 on Tuesday June 10, 2025 @07:34PM (#44242677)
thats why we replaced people with machines . so we can have some predictability.
Re:Why agents are bad pair programmers by tharkun__ on Tuesday June 10, 2025 @11:14PM (#44243867)
Keyword: Some
Re:Why agents are bad pair programmers by apwell23 on Wednesday June 11, 2025 @02:48PM (#44250576)
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 by tharkun__ on Wednesday June 11, 2025 @07:37PM (#44252975)
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 by apwell23 on Thursday June 12, 2025 @07:47AM (#44256553)
> 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 by dotancohen on Tuesday June 10, 2025 @08:09PM (#44242908)

  > I have it create 2 documents, initialprompt.txt and TODO.md.
That is an amazing approach. Which (AI) tools are you using?
Re:Why agents are bad pair programmers by jappgar on Tuesday June 10, 2025 @11:00PM (#44243784)
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.
Re:Why agents are bad pair programmers by SparkyMcUnicorn on Wednesday June 11, 2025 @07:13PM (#44252814)
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.