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)
Why agents are bad pair programmers
211–220 of 239 posts
Re: Why agents are bad pair programmers
#212Earlier 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.
Re: Why agents are bad pair programmers
#213I 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…
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
#214Earlier 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.
Re: Why agents are bad pair programmers
#215Earlier 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.
Re: Why agents are bad pair programmers
#216Earlier 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.
Re: Why agents are bad pair programmers
#217Aider does everything right. Stop using Cursor or any other agentic environments. Try Aider, it works exactly as suggested here.
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
#218Earlier 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.
Re: Why agents are bad pair programmers
#219If 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
#220Earlier 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…
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.