I 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 of simple code. I don't want X to be abstracted this way, I want that...." etc. And then when I give it feedback 2,000 lines of code suddenly switch to 700 lines of completely different code and I can't keep up. And I don't want my codebase full of disjoint scripts that I don't really understand and all have weirdly different approaches to the problem. I want an AI that I have similar opinions to, which is obviously tough. It's like working with someone on their first day.
I don't know if it's giving the tools less self-confidence per se, but I think it's exposing more the design process. Like ideally you want your designer to go "Ok, I'm thinking of this approach, i'll probably have these sorts of functions or classes, this state will be owned here" and we can approve that first, rather than going straight from prompt -> implementation.
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.
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.
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.
> "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."
So, if one's goal is to develop code that is easily maintainable by others, do you think that AI writing code gets in the way of that goal?
Anthropic's guide to using Claude Code [1] is worth reading.
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.
I#m wondering how some can complain about ClaudeAI:
- its actually enlightening
- it saves a lot of time
- by intuition, i did whats written in this blog from the beginning on
YES:
- sometimes the solution is rubish because i can see that its "randomly" is connecting/integrating stuff
- ...but: In about 95% of the cases the output is exactly what i asked for
Yeah, and then you just wind up feeling exhausted AND unsatisfied with where you wind up. You are exactly who I posted this for.
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.
Your ai is generating 2000 line code chunks? Are you prompting it to create the entire Skyrim game for SNES? Then after taking long lunch, getting mad when you press run and you find out it made fallout with only melee weapons in a ps1 style?
> It's like working with someone on their first day.
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.
It’s not really that humans have infinite context windows, it’s more that the context windows are a very poor substitutes for long term memory.
Memory even in a text heavy field like programming is not only text based so it’s often hard to describe for example an appropriate amount of error checking in prompt.md. Giving a person with anterograde amnesia a book of everything they know - no matter how well indexed or how searchable will not fix the lack of long term memory.
At the start of prompt before project requirements I copy paste paragraph about the code I want.
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.
The trick is to have rules specific to the project and your programming style & preferences.
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 prompt it to come up with 3 potential implementation plans, choose which one it thinks is best, and explain its plan to me before it does anything. I also ask it to enumerate which files/functions it will modify in its chosen plan. Then you can give feedback on what it thinks and have it come up with a new plan if you don't like it. Every bit of context and constraints you give it helps. Having a design doc + a little description of your design/code "philosophy" helps. This is easy to do in cursor with rules, I'm guessing other tools have a similar feature. Also, if there's a somewhat similar feature implemented already or if you have a particular style, tell it to reference example files/code snippets.
> I want an AI that I have similar opinions to, which is obviously tough. It's like working with someone on their first day.
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.
Personally, I’ve gone from working with the AI to code to working on it to develop specifications. It’s also useful at troubleshooting issues.
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.
This is kind of why I hardly use one shot/Agentic flows that the cursors are recomending you do (after all it gets them more control and lockin). I mostly know "how" I want something done so put fences to ensure what is generated is in the X loc ballpark and in an incremental way. They are however great to reason through ideas and explore solutions before writing any code.
I don't have this experience with Claude, frankly. I do have to correct it, but I try to give very specific prompts with very specific instructions. IT does well with highly commented code.
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.
I honestly don't expect to use AI tools extensively for code generation until we figure out how to have the models learn and become accustomed to me aside from clever context prompting. I want my own models derived from the baseline.
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.
There is an old issue, that's related, why one should avoid using equality relations in AI used for creating a proof. It will go back and forth and fill the log with trivial statements before it comes to the right proof path. This might end up being the majority of the proof and could be an unbounded part. Then somebody has to read that and spend a good deal of time deciding what's trivial and what isn't. Whereas if you remove equality, you have something that isn't very natural.
People are thinking too much of humans and LOCs as something valuable or worth their consideration when working with AI (because usually that LOCs would have required human effort). This is simply not the case when doing AI coding, and you need to adjust how you work because of that and play to the strengths of this setup, if you want to get something out of it and not frustrate yourself.
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 approach is essentially the PR workflow preferred by the author. Why let an LLM make huge changes to your working copy just for you to revert them next, instead of just writing patches to be asynchronously reviewed? What you propose is no way of doing pair programming in particular, and seems to support the author’s argument.
Whenever I land on the front page, I check the comments and brace for HN coming and telling me how stupid I am and lighting me aflame in front of my peers.
But sometimes if I manage to nail the right headline, nobody reads my post and just has their own discussion, and I am spared.
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.
Have you tried recently? This hasn't been my experience. I modify the code it's written, then ask it to reread the file. It generally responds "I see you changed file and [something.]" Or when it makes a change, I tell it I need to run some tests. I provide feedback, explain the problem, and it iterates. This is with Zed and Claude Sonnet.
I do notice though that if I edit what it wrote before accepting it, and then it sees it (either because I didn’t wait for it to finish or because I send it another message), it will overwrite my changes with what it had before my changes every single time, without fail.
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.
I do this too and it drives me nuts. It's very obvious to me (and perhaps anyone without an incentive to maximize the accept rate) that the diff view really struggles. If you leave a large diff, copilot and cursor will both get confused and start duplicating chunks, or they'll fail to see the new (or the old) but if you accept it, it always works.
I try to be super careful, type the prompt I want to execute in a textfile. Ask the agent to validate and improve on it, and ask it to add an implementation plan. I even let another agent review the final plan.
But even then, occasionally it still starts implementing halfway a refining.
Same. I use /ask in Aider so I can read what it's planning, ask follow-up questions, get it to change things, then after a few iterations I can type "Make it so" while sitting back to sip on my Earl Grey.
In all honesty - have you tried doing what you would do with a paired programmer - that is, talk to them about it? Communicate? I’ve never had trouble getting cursor or copilot to chat with me about solutions first before making changes, and usually they’ll notice if I make my own changes and say “oh, I see you already added XYZ, I’ll go ahead and move on to the next part.”
I do this all the time with Claude Code. I’ll accept its changes, make adjustments, then tell it what I did and point to the files or tell it to look at the diff.
Pair programming requires communicating both ways. A human would also lose context if you silently changed their stuff.
Hmm you can tweak fine these days without messing up context. But, I run in “ask mode” only, with opus in claude code and o3 max in cursor. I specifically avoid agent mode because, like in the post, I feel like I gain less over time.
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.
> My hot take is that if GitHub copilot is your window into llms, you’re getting the motel experience.
I’ve long suspected this; I lean heavily on tab completion from copilot to speed up my coding. Unsurprisingly, it fails to read my mind a large portion of the time.
Thing is, mind reading tab completion is what I actually want in my tooling. It is easier for me to communicate via code rather than prose, and I find the experience of pausing and using natural language to be jarring and distracting.
Writing the code feels like a much more direct form of communicating my intent (in this case to the compiler/interpreter). Maybe I’m just weird; and to be honest I’m afraid to give up my “code first” communication style for programming.
Edit: I think the reason why I find the conversational approach so difficult is that I tend to think as I code. I have fairly strong ADHD and coding gives me appropriate amount of stimulation to do design work.
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
Second this. My solution is to have a 'non-AI' IDE and then a Cursor/VS Code to switch between. Deep work cannot be achieved by chatting with the coding bots, sorry.
This is kind of intentionally the flow with Claude code as I’ve experienced it.
I’m in VSCode doing my thing, and it’s in a terminal window that occasionally needs or wants my attention. I can go off and be AI-Free for as long as I like.
I do this as well and it works quite well for me like that!
Additionally, when working on microservices and on issues that don’t seem too straightforward, I use o3 and copy the whole code of the repo into the prompt and refine a plan there and then paste it as a prompt into cursor. Handy if you don’t have MAX mode, but a company-sponsored ChatGPT.
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 probably keep Copilot disabled for now and stick to the agent-style tools like aider for boilerplate or redundant tasks.
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.
> Also, Cursor was exceptional at interrupting any kind of "flow" - who even wants their next cursor position predicted?
Me, I use this all the time. It’s actually predictable and saves lots of time when doing similar edits in a large file. It’s about as powerful as multi-line regex search and replace, except you don’t have to write the regex.
AI "auto-complete" or "code suggestions" is the worst, especially if you are in a strongly-type language because it's 80% correct and competing with an IDE that can be 100% correct.
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.
I love the autocomplete, honestly use it more than any other AI feature.
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.
> Pair programming is also not suitable for all cases
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.
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.
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.
LLMs in their current incarnation will not, but there's nothing inherently preventing them from learning. Contexts are getting large enough that having a sidecar database living with each project or individual as a sort of corpus of "shit I learned pairing with Justin" is already completely achievable, if only a product company wanted to do that.
LLM agents don't know how to shut up and always think they're right about everything. They also lack the ability to be brief. Sometimes things can be solved with a single character or line, but no they write a full page. And, they write paragraphs of comments for even the most minuscule of changes.
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 attend on when writing the next line of code, leading to reduced errors.
I was trying out sonnet 4 yesterday and it spent 15 minutes changing testing changing etc just to get one config item changed. It ended up changing 40 files for no reason. Also kept trying to open a debugger that didn’t exist and load a webpage that requires auth.
I have mixed feelings about this situation. I have committed myself to learning how to use it as effectively as possible and to utilising it extensively for at least one month. Through my company, I have access to multiple products, so I am trying them all.
I can say that I am more productive in terms of the number of lines written. However, I cannot claim to be more productive overall.
For every task it completes, it often performs some inexplicable actions that undo or disrupt other elements, sometimes unrelated ones. The tests it generates initially appear impressive, but upon examining other metrics, such as coverage, it becomes evident that its performance is lacking. The amount of time required to guide it to the correct outcome makes it feel as though I am taking many steps backwards before making any significant progress forward—and not in a beneficial way. On one occasion, it added 50,000 unnecessary import lines into a module that it should not have been altering.
On another occasion, one of the agents completely dismantled the object-oriented programming hierarchy, opting instead to use if/else statements throughout, despite the rules I had set.
The issue is that you can never be certain of its performance. Sometimes, for the same task, it operates flawlessly, while at other times, it either breaks everything or behaves unpredictably.
I have tried various techniques to specify what needs to be done and how to accomplish it, yet often, for similar tasks, its behaviour varies so significantly between runs that I find myself needing to review every change it makes each time. Frustratingly, even if the code is nearly correct and you request an update to just one part, it may still behave erratically.
My experience thus far suggests that it is quite effective for small support tools, but when dealing with a medium-sized codebase, one cannot expect it to function reliably every time.
In my experience the problem is not they are too fast, they are too slow.
Honestly, their speed is just the right amount to make them bad. If they were faster, I could focus on following the code they are writing. But they take so much time for every edit that I tune out. On the other hand if they were slower, I could do other work while they are working, but they are done every 50 seconds to a few minutes which means I can't focus on other tasks.
If they did smaller faster changes it would probably be better.
Ideally though I would prefer them to be more autonomous, and the collaboration mode to be more like going over merge requests than pair programming. I ideally would like to have them take a task and go away for a few hours or even like 30 minutes.
The current loop, provide a task, wait 1 to 3 minutes, see a bunch of changes, provide guidance, repeat is the worst case scenario in my view.
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?
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.
I have a client that actively asks me to use AI more and more. They expect to get better quality code faster, ie. to reduce costs. (That's not my experience but that's beside the point).
Readit News
I don't know if it's giving the tools less self-confidence per se, but I think it's exposing more the design process. Like ideally you want your designer to go "Ok, I'm thinking of this approach, i'll probably have these sorts of functions or classes, this state will be owned here" and we can approve that first, rather than going straight from prompt -> implementation.
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.
Meeting-based programming. No wonder management loves it and thinks it should be the future.
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.
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.
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...
Instead of a writing a blog post about how they didn't guess how you wanted things done?
I#m wondering how some can complain about ClaudeAI: - its actually enlightening - it saves a lot of time - by intuition, i did whats written in this blog from the beginning on
YES: - sometimes the solution is rubish because i can see that its "randomly" is connecting/integrating stuff - ...but: In about 95% of the cases the output is exactly what i asked for
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.
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.
Memory even in a text heavy field like programming is not only text based so it’s often hard to describe for example an appropriate amount of error checking in prompt.md. Giving a person with anterograde amnesia a book of everything they know - no matter how well indexed or how searchable will not fix the lack of long term memory.
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.
also: I clean the chat and start over sometimes, because results may differ.
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.
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.
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.
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.
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.
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.
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.
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.
At this point AI generated code absolutely requires review by a human so LOC is still an important metric.
But sometimes if I manage to nail the right headline, nobody reads my post and just has their own discussion, and I am spared.
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.
(Zed with Claude 4)
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.
Deleted Comment
Never had any trouble.... and then they lived together happy forever.
If you want an LLM to do something, you have to explain it. Keep a few prompt docs around to load every conversation.
Pair programming requires communicating both ways. A human would also lose context if you silently changed their stuff.
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.
I’ve long suspected this; I lean heavily on tab completion from copilot to speed up my coding. Unsurprisingly, it fails to read my mind a large portion of the time.
Thing is, mind reading tab completion is what I actually want in my tooling. It is easier for me to communicate via code rather than prose, and I find the experience of pausing and using natural language to be jarring and distracting.
Writing the code feels like a much more direct form of communicating my intent (in this case to the compiler/interpreter). Maybe I’m just weird; and to be honest I’m afraid to give up my “code first” communication style for programming.
Edit: I think the reason why I find the conversational approach so difficult is that I tend to think as I code. I have fairly strong ADHD and coding gives me appropriate amount of stimulation to do design work.
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 in VSCode doing my thing, and it’s in a terminal window that occasionally needs or wants my attention. I can go off and be AI-Free for as long as I like.
Additionally, when working on microservices and on issues that don’t seem too straightforward, I use o3 and copy the whole code of the repo into the prompt and refine a plan there and then paste it as a prompt into cursor. Handy if you don’t have MAX mode, but a company-sponsored ChatGPT.
Sure, you could just add a shortcut too.
After a while, it turns into a habit.
...by you. Meanwhile, plenty of us have found a way to enhance our productivity during deep work. No need for the patronization.
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.
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.
I'm fascinated by how different workflows are. This single feature has saved me a staggering amount of time.
Me, I use this all the time. It’s actually predictable and saves lots of time when doing similar edits in a large file. It’s about as powerful as multi-line regex search and replace, except you don’t have to write the regex.
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.
I've been doing this a while. This is most of my work
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.
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.
The AI doesn't seem to be adding any extra value? It's not like it is more accurate that SO, or that it produces answers any faster, honestly
It just is much less trustworthy imo
Deleted Comment
They talk at you, are overbearing and arrogant.
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.
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.
They’re far from perfect that’s for sure.
We went from proof reading single emails to researching agentic coding in a year.
It should have been five.
I can say that I am more productive in terms of the number of lines written. However, I cannot claim to be more productive overall.
For every task it completes, it often performs some inexplicable actions that undo or disrupt other elements, sometimes unrelated ones. The tests it generates initially appear impressive, but upon examining other metrics, such as coverage, it becomes evident that its performance is lacking. The amount of time required to guide it to the correct outcome makes it feel as though I am taking many steps backwards before making any significant progress forward—and not in a beneficial way. On one occasion, it added 50,000 unnecessary import lines into a module that it should not have been altering.
On another occasion, one of the agents completely dismantled the object-oriented programming hierarchy, opting instead to use if/else statements throughout, despite the rules I had set.
The issue is that you can never be certain of its performance. Sometimes, for the same task, it operates flawlessly, while at other times, it either breaks everything or behaves unpredictably.
I have tried various techniques to specify what needs to be done and how to accomplish it, yet often, for similar tasks, its behaviour varies so significantly between runs that I find myself needing to review every change it makes each time. Frustratingly, even if the code is nearly correct and you request an update to just one part, it may still behave erratically.
My experience thus far suggests that it is quite effective for small support tools, but when dealing with a medium-sized codebase, one cannot expect it to function reliably every time.
Honestly, their speed is just the right amount to make them bad. If they were faster, I could focus on following the code they are writing. But they take so much time for every edit that I tune out. On the other hand if they were slower, I could do other work while they are working, but they are done every 50 seconds to a few minutes which means I can't focus on other tasks.
If they did smaller faster changes it would probably be better.
Ideally though I would prefer them to be more autonomous, and the collaboration mode to be more like going over merge requests than pair programming. I ideally would like to have them take a task and go away for a few hours or even like 30 minutes.
The current loop, provide a task, wait 1 to 3 minutes, see a bunch of changes, provide guidance, repeat is the worst case scenario in my view.
You need a 30L fishtank for your desk. Great for tuning out.
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.
We commonly work with personal information so it would also introduce rather harsh legal risks if usian corporations could reach it.
I assume AI autocomplete may send any part of your code base or even all of it to a third-party.