Live data from Hacker News

Why agents are bad pair programmers

justin.searls.co

21–30 of 239 posts

Re: Why agents are bad pair programmers

#21
post #8

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

I recently got a new laptop and had to setup my IDE again. After a couple hours of coding something felt "weird" - turns out I forgot to login to GitHub Copilot and I was working without it the entire time. I felt a lot more proactive and confident as I wasn't waiting on the autocomplete. Also, Cursor was exceptional at interrupting any kind of "flow" - who even wants their next cursor position predicted? I'll probab…

It's strange the pure llm workflow and boring. I still write most of my own code and will llms when I'm too lazy to write the next piece.

If I give it to an llm most of my time is spent debugging and reprompting. I hate fixing someone elses bug.

Plus I like the feeling of the coding flow..wind at my back. Each keystroke putting us one step closer.

The apps I made with llms I never want to go back to but the apps I made by hand piece by piece getting a chemical reaction when problems were solved are the ones I think positively about and want to go back to.

I always did math on paper or my head and never used a calculator. Its a skill I never have forgotten and I worry how many programmers won't be able to code without llms in the future.

Re: Why agents are bad pair programmers

#22

Earlier quoted context omitted.

> Deep work cannot be achieved by chatting with the coding bots, sorry. ...by you. Meanwhile, plenty of us have found a way to enhance our productivity during deep work. No need for the patronization.

I don't believe you experience deep work the same way I do then In my mind you cannot do deep work while being interrupted constantly, and LLM agents are constant interruptions

You can do better than a No true Scotsman fallacy. The fact is that not everyone works the same way you do, or interacts the same way with agents. They are not constant interruptions if you use them correctly.

Essentially, this is a skill issue and you're at the first peak of the Dunning–Kruger curve, sooner ready to dismiss those with more experience in this area as being less experienced, instead of keeping an open mind and attempting to learn from those who contradict your beliefs.

You could have asked for tips since I said I've found a way to work deeply with them, but instead chose to assume that you knew better. This kind of attitude will stunt your ability to adopt these programs in the same way that many people were dismissive about personal computers or the internet and got left behind.

Re: Why agents are bad pair programmers

#23

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

I’m a Vim user and couldn’t agree more.

Didn’t like any of the AI-IDEs, but loved using LLMs for spinning up one off solutions (copy/paste).

Not to be a fan boy, but Claude Code is my new LLM workflow. It’s tough trying to get it to do everything, but works really well with a targeted task on an existing code base.

Perfect harmony of a traditional code editor (Vim) with an LLM-enhanced workflow in my experience.

Re: Why agents are bad pair programmers

#24

Earlier quoted context omitted.

If I have a 20 line function in my mind and the LLM injects 20 lines for me to accept or reject, I have two problems First I have to review the 20 lines the LLM has produced Second, if I reject those lines, it has probably shoved the function I had in mind out of my head It's enormously disruptive to my progress

The hard truth here is in accepting that the 20 lines in your head were probably wrong, or suboptimal, and letting go of that urge. Think in interfaces, not implementations. Successive rendering, not one-shot.

Maybe it's the domain I work in, or the languages I use, but the 20 lines the LLM comes up with is almost certainly wrong.

Re: Why agents are bad pair programmers

#25

Earlier quoted context omitted.

> Deep work cannot be achieved by chatting with the coding bots, sorry. ...by you. Meanwhile, plenty of us have found a way to enhance our productivity during deep work. No need for the patronization.

I don't believe you experience deep work the same way I do then In my mind you cannot do deep work while being interrupted constantly, and LLM agents are constant interruptions

[flagged]

Re: Why agents are bad pair programmers

#26

I use an LLM as a reference (on-demand), and don't use agents (yet). I was never into pair programming, anyway, so it isn't a familiar workflow for me. I will admit that it encourages "laziness," on my part, but I'm OK with that (remember when they said that calculators would do that? They were right). For example, I am working on a SwiftUI project (an Apple Watch app), and forgot how to do a fairly basic thing. I co…

> I use an LLM as a reference (on-demand), and don't use agents (yet)

This was me until about three weeks ago. Then, during a week of holiday, I decided I didn't want to get left behind and tried a few side-projects using agents -- specifically I've been using Roo. Now I use agents when appropriate, which I'd guess is about 50% of the work I'm doing.

Re: Why agents are bad pair programmers

#28

Earlier quoted context omitted.

If I have a 20 line function in my mind and the LLM injects 20 lines for me to accept or reject, I have two problems First I have to review the 20 lines the LLM has produced Second, if I reject those lines, it has probably shoved the function I had in mind out of my head It's enormously disruptive to my progress

The hard truth here is in accepting that the 20 lines in your head were probably wrong, or suboptimal, and letting go of that urge. Think in interfaces, not implementations. Successive rendering, not one-shot.

> ...and letting go of that urge.

What urge? The urge to understand what the software you're about to build upon is doing? If so, uh... no. No thanks.

I've seen some proponents of these code-generation machines say things like "You don't check the output of your optimizing compiler, so why check the output of Claude/Devon/whatever?". The problem with this analogy is that the output from mainstream optimizing compilers is very nearly always correct. It may be notably worse than hand-generated output, but it's nearly never wrong. Not even the most rabid proponent will claim the same of today's output from these code-generation machines.

So, when these machines emit code, I will inevitably have to switch from "designing and implementing my software system" mode into "reading and understanding someone else's code" mode. Some folks may be actually be able to do this context-shuffling quickly and easily. I am not one of those people. The results from those studies from a while back that found that folks take something like a quarter-hour to really get back into the groove when interrupted while doing a technical task suggest that not that many folks are able to do this.

> Think in interfaces...

Like has been said already, you don't tend to get the right interface until you've attempted to use it with a bunch of client code. "Take a good, educated stab at it and refine it as the client implementations reveal problems in your design." is the way you're going to go for all but the most well-known problems. (And if your problem is that well-known, why are you writing more than a handful of lines solving that problem again? Why haven't you bundled up the solution to that problem in a library already?)

> Successive rendering, not one-shot.

Yes, like nearly all problem-solving, most programming is and always has been an iterative process. One rarely gets things right on the first try.

Re: Why agents are bad pair programmers

#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.

Re: Why agents are bad pair programmers

#30

Earlier quoted context omitted.

I don't believe you experience deep work the same way I do then In my mind you cannot do deep work while being interrupted constantly, and LLM agents are constant interruptions

You can do better than a No true Scotsman fallacy. The fact is that not everyone works the same way you do, or interacts the same way with agents. They are not constant interruptions if you use them correctly. Essentially, this is a skill issue and you're at the first peak of the Dunning–Kruger curve, sooner ready to dismiss those with more experience in this area as being less experienced, instead of keeping an open…

It’s quite amusing to see you complain about patronisation, and then see you turn about and do it yourself one comment later.
Post reply on HN