alt Hacker NewsI have to admit, I asked ChatGPT to do a TLDR summary because I found the writing meandered quite a bit. I think the overall point is sound:
> "Developers become attached to tools like Vim, Emacs, or an IDE because years of experience make those tools predictable extensions of their thinking. The attachment is less about features and more about accumulated trust, muscle memory, and a workflow built around known boundaries.
> AI coding agents disrupt that trust because they are fast but probabilistic, opaque, constantly changing, and capable of producing more code than humans can realistically review. This shifts the bottleneck from writing code to specifying, reviewing, validating, and operating it safely."
(Note the > is paraphrasing)
Trust is a big problem I'm having with these tools so far. What I've been running into a lot is, I'll get the equivalent 40 hours of work done in 8 hours, and I'm like, wow, that really was quick. Then I'll start using the application I'm making more directly (a tool for writing), and I'll start to see that it's broken all over the place in very surprising ways (ie, updating this menu item broke something on the other side of the app, etc.). So then I spend another 40 hours of real wall clock time kind of fixing everything that was broken, and at the end of those two weeks I'm like, did I actually go much faster or was that all kind of a wash? Because if I'm not going faster in overall terms, then the loss of deep understanding of the code base might not be worth it if my pace is the same.
I'm sure someone is going to be like "BRUH AUTOMATED TESTS" or "BRUH MODEL CHOICE". I have a LOT of automated tests, and I don't like fussing with models so I pretty much use Opus on high reasoning for most things (or the equivalent from other providers). Code review also doesn't help that much, for much of the same reason it doesn't tend to help find bugs in human written code either.. you're reading the happy path usually.
Anyway I wouldn't say these tools aren't useful, but, I'm deeply skeptical of all the productivity claims because I think people just look at one dimension of it while ignoring all the other important dimensions. Yeah you can generate a lot of crap fast, but most of it is not shippable and making it shippable does take time.
Replies
I was surprised to see you say you have automated tests. To me this makes most of the difference, but you have you actually have a good test suite, like one that actually proves the code does what you want it to do. Unit tests, property tests, e2e tests. The other part that makes all difference, is you have to be all up in the model's business about architecture. Pick something that wants to testable and isolation friendly, data models that are correct by construction (ie invalid states are not expressible), etc. It absolutely will try to cut corners give you bullshit slop at every turn, you have to keep the structure sane and build the right tests and harness around it.
And I can hear your objection now: correct, it's probably not worth all that for a throwaway, but the effort per output goes down as the infra builds up and you end up with a program that can reliably expand.
> Anyway I wouldn't say these tools aren't useful, but, I'm deeply skeptical of all the productivity claims because I think people just look at one dimension of it while ignoring all the other important dimensions. Yeah you can generate a lot of crap fast, but most of it is not shippable and making it shippable does take time.
My own stance is that there's never any reason to go fast on anything. Communication has always been the bottleneck. Whether it's about gathering requirements or understanding the purpose of a badly written code, any speed improvements I get has always been a small percentage of the overall progress.
What has helped more is my understanding of the platform and some theoretical knowledge. Because one I get the information, I can quickly derive a solution in my mind. And that solution has always been easy and fast to implement, at least the happy path. 90% of the time taken in coding is always about handling all the edge cases, aka fixing bugs. And writing tests so that you're not easily introducing more bugs.
[flagged]
[dead]
If you are spending 40 hours fixing everything that was broken, the question I have is does your AI tools have the necessary context to be successful and not result in a lot of broken items?
Also, is there ways for AI to help prevent the loss of deep understanding of your code base without you having to know every line of code deeply?