Why agents are bad pair programmers

100% of my positive experiences with agent coding are when I don't have reason to care about the intrinsic qualities of the code (one-off scripts or genuine leaf node functions that can't impact anything else.

Think of the AI like an outsourced consultant who will never say no. It'll always do everything it can to solve the problem you've given it. If it doesn't know how, it'll write a thousand lines when a single additional dependency and 2 lines of code would've done it.

I’m no longer a developer by trade and it’s more a hobby or specific problem solving scenario now. But I find using it to identify gaps in my thinking and edit English is ultimately better than getting random code — I love editing English text, but find editing code without consistent style a drag for my purposes.

No emojis, no comments, no console log statements, no read me file, no error handling. Act as a senior developer working with other experienced developers.

Otherwise it happily generates bunch of trash that is unreadable. Error handling generated will most of the times just hide errors instead of actually dealing with them.

My successful AI written projects are those where I care solely on the output and have little to no knowledge about the subject matter.

When I try to walk an agent through creating anything about which I have a deeply held opinion of what good looks like, I end up frustrated and abandoning the project.

I've enjoyed using roo code's architect function to document an agreed upon approach, then been delighted and frustrated in equal measure by the implementation of code mode.

On revelation is to always start new tasks and avoid continuing large conversations, because I would typically tackle any problem myself in smaller steps with verifiable outputs, whereas I tend to pose the entire problem space to the agent which it invariably fails at.

I've settled on spending time finding what works for me. Earlier today I took 30 minutes to add functionality to an app that would've taken me days to write. And what's more I only put 30 minutes into the diary for it, because I knew what I wanted and didn't care how it got there.

This leads me to conclude that using AI to write code that a(nother) human is one day to interact with is a no-go, for all the reasons listed.

Now, I have the best luck in my personal project codebase, which I know extremely intimately so can be very surgical with.

Work, which has far less comments and is full of very high level abstractions that I don't know as well.. it struggles with. We both do.

It's a fine pair programmer when one of the pairs knows the codebase extremely well. It's a bad companion elsewhere.

Here is how to do this: Have it generate something. That first 2000 lines of not so great first attempt code, don't even think about understanding all of that, or, worse, about correcting it.

Review it loosely. You are not dealing with a human! There is absolutely no need to be thorough or nice. You are not hurting any feelings. Go for 80/20 (or the best ratio you think you can get).

Then, think:

- Anything you missed to inform the AI about? Update your initial prompt

- Anything the AI simply does not do well or to your liking? Write general instructions (all of the IDEs have some way of doing that) that are very explicit about what you don't want to see again, and what you want to see instead.

Then revert everything the ai did, and have it go again from the start. You should approach something that's better.

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.

This is the gist of what I've always wanted from a programming mentor, instructor, or tutor.

It can be surprisingly hard to find. Knowing that current LLMs still struggle with it perhaps helps explain why.

This matches my experience exactly, but worse than working with a human on their first day, day 100 for an AI is still like working with them on their first day. Humans have effectively infinite context windows over a long enough period of time, AIs context windows are so constrained that it's not worthwhile to invest the effort to 'teach' it like you would a junior engineer.

Specifically, their recommended workflow is "first ask it to read the code, then ask it to make a plan to implement your change, then tell it to execute". That sounds like the workflow you're asking for - you can read its plan and make adjustments before it writes a single line of code.

One of the weird things about using agents is that if they're doing things in a way you don't like, including things like writing code without first running the design by you, you can simply ask them to do things a different way.

[1] https://www.anthropic.com/engineering/claude-code-best-pract...

Most of what you're describing does apply to humans on the first day, and ais on their first day. If you aren't capturing these preferences somewhere and giving it to either a human or the ai, then why would they somehow know your preferences? For ai, the standard thats forming is you create some markdown file(s) with these so they only need to be explained once, and auto provided as context.

That said, I also value not becoming too dependent on any service which isn't free and efficient. Relying on a CNC machine when you never learned how to whittle strips me of a sense of security and power I'm not comfortable with.

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.

If you want an LLM to do something, you have to explain it. Keep a few prompt docs around to load every conversation.

I infrequently tab complete. I type out 80-90% of what is suggested, with some modifications. It does help I can maintain 170 wpm indefinitely on the low-medium end.

Keeping up with the output isn’t much an issue at the moment given the limited typing speed of opus and o3 max. Having gained more familiarity with the workflow, the reading feels easier. Felt too fast at first for sure.

My hot take is that if GitHub copilot is your window into llms, you’re getting the motel experience.

Of course this does artificially inflate the "accept rate" which the AI companies use to claim that it's writing good code, rather than being a "sigh, I'll fix this myself" moment.

Pair programming requires communicating both ways. A human would also lose context if you silently changed their stuff.

Or have the ai write the entire first draft for some piece and then you give it a once over, correcting it either manually or with prompts.

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 probably keep Copilot disabled for now and stick to the agent-style tools like aider for boilerplate or redundant tasks.

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.

AI agents are much better for me because 1) they don't constantly interrupt your train of thought and 2) they can run compile, run tests, etc. to discover they are incorrect and fix it before handing the code back to you.

But I'm forced to write in Go which has a lot of boilerplate (and no, some kind of code library or whatever would not help... it's just easier to type at that point).

It's great because it helps with stuff that's too much of a hassle to talk to the AI for (just quicker to type).

I also read very fast so one line suggestions are just instant anyway (like non AI autocomplete), and longer ones I can see if it's close enough to what I was going to type anyway. And eventually it gets to the point where you just kinda know what it's going to do.

Not an amazing boost, but it does let me be lazy writing log messages and for loops and such. I think you do need to read it much faster than you can write it to be helpful though.

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.

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 attend on when writing the next line of code, leading to reduced errors.

They’re far from perfect that’s for sure.

You need a 30L fishtank for your desk. Great for tuning out.

We commonly work with personal information so it would also introduce rather harsh legal risks if usian corporations could reach it.

I don't think it actually saves me enough time (or for many tasks, any time) so I wouldn't pay for it for my own projects, and also for my own projects, the enjoyability is a big factor, and I enjoy doing more than prompting.

One workflow that works well for me, even with small local models, is to start a plan session with something like: "based on @file, and @docs and @examples, I'd like to _ in @path with the following requirements @module_requirements.md. Let's talk through this and make sure we have all the info before starting to code it."

Then go back and forth, make sure everything is mentioned, and when satisfied either put it into a .md file (so you can retry the coding flow later) or just say "ok do it", and go grab a cup of coffee or something.

You can also make this into a workflow with .rules files or .md files, have a snippets thing from your IDE drop this whenever you start a new task, and so on. The idea with all the advancements in LLMs is that they need lots of context if you want them to be anything other than what they were trained on. And you need to try different flows and see what works on your specific codebase. Something that works for projectA might not work for projectB ootb.

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.

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 Rinse, repeat

Or if you're mutating a list, writing code that inserts a new element, but you don't know which one is new. And you end up, again, hand coding loops and checking what you remember to check.

What about when you need to do an auth check.

And the hand coder may fail to remember one little thing somewhere.

With LLM code, you can just describe that function and it will remember to do all the things.

An LLM with a model + metadata - we won't really need to think of it as editing User.java or User.py anymore. Instead User.yaml - and the LLM will just consume that, and build out ALL of your required biz-logic, and be done with it. It could create a fully authenticating/authorizing REST API + GraphQL API with sane defaults - and consistent notions throughout.

And moving into UIs- we can have the same thing. The UI can be described in an organized way. What fields are required for user registration. What fields are optional according to the backend. It's hard to visualize this future, but I think it's a no-code future. It's models of requirements instead.

What makes it invalid is "= 5", and lack of "struct" before "MyStruct" (could have used typedef).

It's not that AIs are bad. It's that pair programming is (often) not effective. In the majority of cases, one side dominates the other.

In my experience, a modified pair programming system works better where the two of us discuss the problem to be solved, then each of us goes off for a few hours independently coming up with ideas, and doing experiments. We then get together, discuss our findings, and finalize a plan of attack. And then pair programming helps as we're both at the same level and on the same page. But even then, having to watch someone else's screen (or have people interrupt you while you're typing) is a pain.

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

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 seems like 3 out of 4 decisions that it makes are fine. But that 4th decision is usually asinine.

That said, I now consider LLMs a mandatory addition to my toolkit because they have improved my developer efficiency so much. I really am a fan. But without a seasoned dev to write detailed instructions, break down the project into manageable chunks, make all of the key design decisions, and review every line of code that it writes, today's AI will only add a mountain of technical debt to your project.

I guess I'm trying to say: don't worry because the robots cannot replace use yet. We're still in the middle of the hype cycle.

But what do I know? I'm just an average meat coder.

"The easiest path is to sign in to Copilot from any JetBrains IDE"

Somebody must've made a standalone login script by now right? I wonder if `gh auth login` can be used to get a token?

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.