Ask HN: I hate coding agents. Is this skill issue?
1. Farewell deep focus. Before, I could work in flow state for hours on end. Now, waiting for the prompt to finish introduces constant interruptions, which translates into constant distractions, constant context switch, infinite ideas for endless new projects. My brain is melting. I can literally feel when my neurons start clogging up, forcing me to take frequent pauses just staring outside the window for 10 minutes straight.
2. I don't own my own projects anymore. Before, I used to understand every single little implementation detail of a project. When a client reported a bug, I immediately knew what and where to fix in the code base. Now, all I can do is to clasp my hands and recite a prayer to the LLM deity, hoping that my voice will be heard.
3. The overlords decide my fate. This is a corollary of #2. There's an outage every other day, and since I don't understand 80% of the code the AI has written, no AI available means it's literally impossible for me to work. I depend completely on its availability.
4. It's mostly right, but never quite there. I really make an effort to write descriptive prompts, extensive documentation, and various design docs. All of this to make it easier for the AI to understand the context and philosophy of the project. I write AGENTS.md, skills and rules. Yet, it can easily do 80% of the work correctly, but it always makes some wrong assumptions that make the other 20% very hard to fix. You have to held it's hand over every single little bug that it can't automatically fix. Old, already fixed bugs keep resurfacing out of nowhere. It's like Penelope's shroud: it looks like it fixed the current problem, but an old fix just wen't undone. No real progress was made.
This is my experience with coding agents, please tell me your own. I'd love this to be a discussion.
P.S. This post was handwritten by a human being.
Coding agents are brilliant for the 9-5 it’s just a job type of coder as if it done quick and works (for now) the business leaders are happy.
And brilliant for the expert in a particular language who can read the code very quickly
But for everyone else, adds some anxiety as multiple files get changed, hundreds of code lines appear and so on.
The decision is whether to go slower and be thorough or vibe code and trust it won’t back fire through a critical bug
Majority of devs are like all other employees, they get paid to work, are put under pressure to deliver faster and so coding agents allow them to clock out at 5pm and go home to follow their actual interests and hobbies
Yep, I think right now one of the best use cases is one-off disposable code for things that I don't really care about and don't want to do. At least, that's what I'm mostly using them for
My experience is also that they're very different from writing code myself.
There are ways to use the tool better and worse, the worst is to blindly fire off the agent and commit the changes without reading them: This *only* works for very small projects, though it often *does* work for those projects.
For bigger projects, you need to use (and enforce use of) the right architecture, and read pull requests rather than saying "LGTM" and clicking accept. Pick the right way to split the project up into discrete components with clear boundaries between them, make sure that the LLM's commits never introduce surprise coupling outside those boundaries, and make sure the unit tests aren't ridiculously brittle, they can be OK.
https://www.youtube.com/watch?v=grPtnrOTP_4
"Make sure to read the commits" seems to be enough for your points 2/3, at least for me. But everyone thinks a bit differently, YMMV. It also means I almost immediately catch most of the (20%? 10%?) of the time the LLM does something wrong, though not all of them.
I find I still have deep focus. If anything, the problem for me is they're so addictive I am tempted to keep working and working rather than rest, a problem I last faced over 20 years ago when I was working on a personal project that ended up not going anywhere.
I do read the commits and really try to understand what the model is trying to do. However, I think this conflicts against what we are really trying to do here: - We want to code faster so we use LLMs - We want to still be in charge, so we spend a lot of time reading and understanding every single commit and review PRs.
Before, we used to build a mental model of the code with every new line of code we wrote. That took time, but the result was a very solid understanding. Now we try to build the mental model by just looking at what the LLM produces. Similar to how students who spend most of their time practicing what they are studying with actual exercises achieve higher grades than those who just read the book, we are now at a disadvantage against our old selves who made the effort of writing the code.
Moreover, an LLM produces code a lot faster than we can read and understand. If we want to achieve an actual speedup in code output, there's no way we can read and understand everything and be faster than before. We have to sacrifice the understanding of some parts. This compounds over time and we quickly get into a place of total reliance on LLMs.
Regarding addiction: I also think these devices are addictive. They do open a lot of new doors for us builders. But I think hour grey matter hardware is not built of this speed. Give it time, the more project ideas you start spinning up, the sooner you'll reach burnout.
> Similar to how students who spend most of their time practicing what they are studying with actual exercises achieve higher grades
This is spot on.
> build a mental model of the code with every new line of code
This idea has been explored in depth in the Peter Naur's excellent paper, "Programming as theory building" [1] (also extensively discussed on HN [2]). If you haven't read it yet, I bet you will enjoy it a lot. :)
[1] https://gwern.net/doc/cs/algorithm/1985-naur.pdf
[2] https://hn.algolia.com/?q=Programming+as+theory+building
Thank you so much for suggesting this, I will definitely enjoy reading it!
AI coding forces people to frontload a lot of the detailed thinking that used to take place over an epic or sprint. It's not a very natural way of working, and in fact is quite contrary to the iterative development style that most devs are already used to.
I find it painful as well. I actually find agentic coding counterproductive. I typically use LLMs the “old way”: web chat interface, asking questions and searching. I write the code by hand. This makes me 2-3x more productive than before (I guess with agents I could be 5-10x more productive but the price to pay is not worth it)
My process is becoming as follows:
1) I always start with a clean code base (ie. no uncommitted changes)
2) I have a text file called prompts in which I write my first prompt for my desired change, in the initial prompt I always explicitly ask to NOT generate unit tests.
3) Copy paste the prompt to the cli
4) While the LLM is working on my prompt I go back to my prompts file and start preparing the next prompts that will build on top of the previous one
5) Once the agent is done I review every single line of code and either manually fix what I don’t like or prompt minor changes until I reach my desired result.
6) commit locally the change
7) copy paste the next major prompt from my prompts file
8) Repeat steps 4-8 until I fully implement my major change
9) Once I have my major change I prompt for adding unit tests and related documentation
10) Once my unit tests are all green I execute additional manual tests if required, squash all local commits and push for pear review
Following these steps I can work fully focused and let me emphasise again on the fact that even if the majority of code is written by the LLM I still review and read every single line of code so that when LLM companies decide to fuck us or when shit happens in production I know where to look as if I wrote the code myself like the old days
All of this works for me because I know very well the programming language and the specific domain I am working in thanks to the past experience collected in past years before LLMs.
I had the same issues a year an a half ago. You just have to get over it. It sucks and not much can be done about it.
So do you still use agentic programming? What percentage of code do you write yourself and what percentage do you hand off to AI?
I don't really think so. When writing code with AI, I feel like we're doing two different jobs at once: writing documentation and writing code. Even though they're technically two sides of the same coin, it gets really frustrating.
Besides, no matter how good our design docs are, AI just can't grasp the business context outside of what's written. Plus, AI loves to modify things using band-aid patches, making it incredibly hard to keep the code clean. The design logic often gets messy, and you ultimately lose true logical consistency.
My current workaround is to provide detailed architecture and design principles upfront, and also add comments at the top of each file to clearly define its scope. That seems to help a bit.
But my biggest headache right now is that AI struggles to adapt to the latest APIs—it actually likes to revert the new APIs I've just updated back to the older, deprecated ones.
Yes! Yes! Yes! The band-aid patches! I really hate that.
Regarding old API regression, I think that's because the LLM sees a lot more examples of deprecated APIs throughout the code, than new replacements you just introduced. You could try forcing it to immediately replace old calls to deprecated endpoints, then actually removing the definition completely, so that you reduce the number of bad examples and increase that of good examples
Try investing more into design so you could feel ownership of what you built and control all your decisions. Agenda should not be solving all problems -
So don't use coding agents? No one is forcing you, are they?
Well, there's mass hysteria at the moment. I'm lucky enough to be self employed right now, but there definitely are people being forced to use them by their bosses
No, it's not a skill issue. It's a taste issue. You have some.
More seriously, you triggered a thought with your point 4. In prose, "editor" is a different skill from "author". It's a different career track.
AI is, essentially, taking coders from "author" to "editor". We don't feel nearly as comfortable there. It isn't what we do, or at least what we've been doing for our whole careers.
Very good point!