As a developer who doesn't use AI for coding, except for the occasional non-project specific question to a chat bot, I am wondering if you use it for client projects or only for your own projects. If you do use it for client projects, do you have some kind of agreement that you're going to share their code with a third-party? I'm asking because most clients will make you sign a contract saying that you shouldn't disclose any information about the project to a third-party. I even once had a client who explicitly stated that AI should not be used. Do you find clients willing to make an exception for AI coding agents?
Why agents are bad pair programmers
91–100 of 239 posts
Re: Why agents are bad pair programmers
#92As a developer who doesn't use AI for coding, except for the occasional non-project specific question to a chat bot, I am wondering if you use it for client projects or only for your own projects. If you do use it for client projects, do you have some kind of agreement that you're going to share their code with a third-party? I'm asking because most clients will make you sign a contract saying that you shouldn't disc…
I don't share anything with openai/anthropic that I wouldn't feel comfortable pasting into a web search prompt.
Re: Why agents are bad pair programmers
#93Earlier 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.
You can, but I would expect code correctness to be reduced, you're removing one mechanism the model uses to dump local reasoning immediately prior to where it's needed.
Re: Why agents are bad pair programmers
#94Pair 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’ve always seen it as primarily an _education_ tool; the purpose of pair programming isn’t that two people pair programming are more productive than two people working individually, they’re generally not. So pair programming with a magic robot seems rather futile; it’s not going to learn anything.
Re: Why agents are bad pair programmers
#95As a developer who doesn't use AI for coding, except for the occasional non-project specific question to a chat bot, I am wondering if you use it for client projects or only for your own projects. If you do use it for client projects, do you have some kind of agreement that you're going to share their code with a third-party? I'm asking because most clients will make you sign a contract saying that you shouldn't disc…
No, I don't. This goes for internal projects as well, we're not going to share code unless payed to do so.
We commonly work with personal information so it would also introduce rather harsh legal risks if usian corporations could reach it.
Re: Why agents are bad pair programmers
#96Earlier quoted context omitted.
How would you have handled it?
Here is how I might have handled it differently: Instead of > Meanwhile, plenty of us have found a way to enhance our productivity during deep work. No need for the patronization. you could have written > Personally, I found doing X does enhance my productivity during deep work. Why it's better: 1) cuts out the confrontation (“you're being patronizing!”), 2) offers the information directly instead of merely implying…
That's real patronizing. His answers were fine, unless you think he is totally wrong.
Re: Why agents are bad pair programmers
#97When 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.
My approach has generally been to accept, refactor and reprompt if I need to tweak things.
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.
Re: Why agents are bad pair programmers
#98I've been considering a... protocol? for improving this. Consider this repo: foo.py bar.py bar.py.vibes.md This would indicate that foo.py is human-written (or at least thoroughly reviewed by a human), while bar.py is LLM written with a lower bar of human scrutiny. bar.py.vibes.md would contain whatever human-written guidance describes how bar should look. It could be an empty file, or a few paragraphs, or it it coul…
I think coding will eventually go away in favor of models with metadata built around them. 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 Rins…
I don't understand all of what you wrote but a lot of it is very old news and usually done with deterministic tooling you don't have to wait for, some of which you should have built or configured yourself to get it tailored to the type of work you do.
And some of it we've had under the RAD umbrella, basically using configuration files and tools to generate those that are used to generate large portions of systems.
Re: Why agents are bad pair programmers
#99As a developer who doesn't use AI for coding, except for the occasional non-project specific question to a chat bot, I am wondering if you use it for client projects or only for your own projects. If you do use it for client projects, do you have some kind of agreement that you're going to share their code with a third-party? I'm asking because most clients will make you sign a contract saying that you shouldn't disc…
I basically only use it in the workplace, and largely because of one of those AI mandates.
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.
Re: Why agents are bad pair programmers
#100LLM agents are very hard to talk about because they're not any one thing. Your action-space in what you say and what approach you take varies enormously and we have very little body of common knowledge about what other people are doing and how they're doing it. Then the agent changes underneath you or you tweak your prompt and it's different again.
In my last few sessions I saw the efficacy of Claude Code plummet on the problem I was working on. I have no idea whether it was just the particular task, a modelling change, or changes I made to the prompt. But suddenly it was glazing every message ("you're absolutely right"), confidently telling me up is down (saying things like "tests now pass" when they completely didn't), it even cheerfully suggested "rm db.sqlite", which would have set me back a fair bit if I said yes.
The fact that the LLM agent can churn out a lot of stuff quickly greatly increases 'skill expression' though. The sharper your insight about the task, the more you can direct it to do something specific.
For instance, most debugging is basically a binary search across the set of processes being conducted. However, the tricky thing is that the optimal search procedure is going to be weighted by the probability of the problem occurring at the different steps, and the expense of conducting different probes.
A common trap when debugging is to take an overly greedy approach. Due to the availability heuristic, our hypotheses about the problem are often too specific. And the more specific the hypothesis, the easier it is to think of a probe that would eliminate it. If you keep doing this you're basically playing Guess Who by asking "Is it Paul? Is it Anne?" etc, instead of "Is the person a man? Does the person have facial hair? etc"
I find LLM agents extremely helpful at forming efficient probes of parts of the stack I'm less fluent in. If I need to know whether the service is able to contact the database, asking the LLM agent to write out the necessary cloud commands is much faster than getting that from the docs. It's also much faster at writing specific tests than I would be. This means I can much more neutrally think about how to bisect the space, which makes debugging time more uniform, which in itself is a significant net win.
I also find LLM agents to be good at the 'eat your vegetables' stuff -- the things I know I should do but would economise on to save time. Populate the tests with more cases, write more tests in general, write more docs as I go, add more output to the scripts, etc.