alt Hacker NewsCrazy how many engineers in here just say they are using another prompt on top. From my experience that makes things worse. It does abstractions, but the wrong ones. It overcomments, confusing future calls of the LLM.
To me building on multiple scalable systems this has been the most dangerous part of LLMs. On a good codebase it will work good, but it will maek it worse, so you keep using it, till it doesnt work and then you have to pay the bill and fix for what you didn’t build before.
If you put an agent on a fresh codebase 2 things are often given:
-> You have a mental model of the code -> The code is somewhet concise
After multiple iterations both is lost and LLM performance degrades. To solve this you can regular refactor, but it’s not a nice experienc. So my best solution is:
I use LLMs for exploration and for review, but I write the code myself. I find it hard to believe why so many engineers try to avoid it. It’s not consuming much of my time. And it’s actually the most enjoyable part.
Sometimes I race AI i give it a prompt /bug to fix and at the sametime im greping/symboling through the codebase and tryto fix it myself. AI isn’t always faster.
Replies
> I use LLMs for exploration and for review, but I write the code myself. I find it hard to believe why so many engineers try to avoid it. It’s not consuming much of my time. And it’s actually the most enjoyable part.
At my workplace, there is more work to be done than there is engineers, and approximately 2 engineers per service. I can spin off multiple Claude Code instances on unrelated work, steering them occasionally, and then finally reviewing the output. After I have reviewed it, I post it for team review.
You're absolutely right that my depth of familiarity is lesser with this code, but we are absolutely shipping more as a result of increased parallelization.
The bottleneck now is typically reviews - both pre-push and team reviews.
Exactly. I follow a similar workflow. I am still writing code by hand. Not all code. Parts are generated by Opus.
> To solve this you can regular refactor, but it’s not a nice experienc.
Really? I always thought that was the best part of programming. And now that I can direct an LLM to identify a specific pattern and rework it in a certain way, or to extract a function for a specific purpose and then use it where possible (with my review, of course), so much the better.
I agree with you about the joy of writing things directly, overall. But being able to get a few hundred lines of new approximately-what-I-wanted-to-type code (which I generally can read and fix much faster than I would have written it from scratch) definitely improves the experience, when my brain is racing ahead of my fingers. Certainly it gets me more motivated to actually start on a new feature. Similarly for all the not-exactly-exact find-and-replace tasks.
(I'm not a slow typist, but I slow myself down when I write the code, by thinking too much about details that won't be important until after the tests run.)
>Sometimes I race AI i give it a prompt /bug to fix and at the sametime im greping/symboling through the codebase and tryto fix it myself. AI isn’t always faster.
+1 - this is also my experience. I also "race" the AI on some tasks, especially when it's simple and the AI is taking forever to return a result - so it even has a head start, and I often complete it faster or around the same time.
For some things maybe it is faster, but it isn't really returning a better result. It often turns into spaghetti, doing things I didn't ask it to do.
> I write the code myself. I find it hard to believe why so many engineers try to avoid it.
Gradually over its recent booming years, software work went from one of several practical engineering refuges for curious tinkers and puzzle-addicts to a career path for financially ambitious bright people akin to finance, law, or medicine.
Many people carrying a "software engineer" title now never really enjoyed that part of the work at all but were suitably clever and responsible to accomplish what modest ends they were tasked to by their very generous employers. Mostly (but not entirely), those people are the ones most eager to have AI agents shield them from rigorous design and puzzle work and enable them to leverage their innate cleverness more lazily. They never really internalized the coding and engineering principles of the industry and so can't foresee what might be down the road for them with this technique, especially when they're surrounded by peers with the same mindset.
> AI isn’t always faster.
It is when coding was an extremely frustrating and high friction experience for you in the first place, as is the case for many who work among us now.