Ask HN: I hate coding agents. Is this skill issue?

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!

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!

I used to watch a window code - each line - but that was too much. I ended up just making sure adversarial reviews are performed for every task, a completion report generated to my personal preferences and then I feed multiple tasks through an an orchestrator that keeps the high-level context in play, which aligns work with my objectives before merging it. It knows my preferences, and runs audits itself, along with automated tests. It took a long time to tweak it to a point where I can stay involved in the choices and code while maximizing throughput - but the work put into the ecosystem has (so far) paid off.

Wow this feels next level! So you only talk to the orchestrator, then it calls sub agents to do the actual work, review and realign. Got a few questions for you:

- Which tools did you use to create this ecosystem?

- Do you write the tests yourself? Do you tell it which tests to write? Or does it guess them on its own based on his understanding of your preferences? How do you make sure the generated code is secure?

- As you give orders to the orchestrator and as the orchestrator gives orders to sub agents your original message might get distorted (similar to when you print a copy of a copy of a copy with your printer). Do you ever find subagents going off topic in an endless code/review/code/review loop?

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)

I was like this too. I found pride for myself on only using the web chat. But being constantly bombarded by titles like "Look what crazy software project this accountant built with X agent!!!!" makes me worry that I'll stay behind if I don't adapt to this new model. I think after all, AI is here to stay, and it's evolving a lot faster than we can keep up

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.

Yep, some time I think we are going back to a waterfall methodology

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

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.

Thank you for your suggestion. Going straight to the next prompt while the agent is still working will probably help me stay in flow state longer. However I'll still have to context switch when checking the code. Nonetheless, I'll experiment with this, thanks!

Yes, its like when you are chatting with somebody and due to the async process somehow you start chatting about two things in parallel (maybe it’s only me),

Anyhow, I think that you can keep in the flow as long as the successive prompts are still related to the major change if not then I guess you deserve a stop and pause before moving on with the next task.

Quite similar, but I ask for "/grilling" skill in every prompt so the agent aligns to my decissions before it drifts into own. And I actually ask to make tests before any implementation and let them all fail.

TDD advocates would be proud of you ;) differently from your approach I still prefer to make sure the model code is inline with my expectations and only then ask for unit tests, only exception is when I am dealing with a bug then the failing unit test is a MUST.

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?

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