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.
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
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.
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.
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
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.
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