I feel like I have gone from 100% hand written code -> 0% hand written -> 50% and climbing.
I think there are things LLMs are really good at coding up and experimenting with but I think there's still a need to understand the btoader context of your software so you need to dive in at some point.
It's very important to understand what's happening, sure. Blindly shipping AI-produced code without understanding is just irresponsible. But how does writing code helps with that? Reading helps a lot, but writing just slows things down in my experience so far.
I'll push back against this slightly: learning what good code is requires debugging bad code, whether by way of a symbolic debugger or judicious use of printf() or breaking an algorithm down into its steps so that you can figure out its asymptotic behaviors.
I harped on checking someone's ability to debug code back when I interviewed candidates, in part because I found that people who could debug effectively could also sniff out bad code. It was something of a bonus that I also happened to select for candidates who could explain their debugging strategies and what that meant for the software they were working on.
It's kind of the same distinction between backups and restores, wherein the restores are what's important, but they're impossible without the backups to restore from.
One of the first things I do in any new-to-me project is set breakpoints in the integration tests and start stepping through the code so that I can establish some mental context. However, if there aren't integration tests, I begin writing them so that I can walk around with my debugger.
Hard agree on this. I feel like it's pretty normal, but I struggle with retaining information by just reading. I really need the manual typing step to cement the knowledge.
LLMs will make tradeoffs without consulting you. This is sometimes a feature and often a bug. Many times a decision made up front can have non obvious implications down the line. This is one of the biggest values I bring to be table as a more experienced swe.
I think if I fully understand everything the agent is going to do and trivially verify the output quality, LLMs are a win. For one off prototypes, the same is true. For software which is unique, complex, and performing a task which has not been fully specified I find myself needing to drop into my editor more and more.
Recently I've been moved to a research focused team and I really need to have proof that something is happening. I've had Claude Opus 5 gaslight me by telling me it did something and when I read the code it obviously did not. This happens more and more with my tasks that are kind of complex.
I've found a lot of the claims by AI people have been 6mo - 2 years "ahead" of my experience. I think we are now in an era where harness engineering is highly valuable (making a test, looping an agent, manually annealing with new ideas) but the claims that no one writes code manually seems like it may not be fully there for all code.
I had a similar experience but I'm closer to 95-99% hand written again now. I still use AI for reviewing and prototyping, but it feels like writing the code myself is the best way to actually know what's going on.
gravypod · · focus · HN ↗
I think there are things LLMs are really good at coding up and experimenting with but I think there's still a need to understand the btoader context of your software so you need to dive in at some point.
dimonomid · · focus · HN ↗
bluefirebrand · · focus · HN ↗
dimonomid · · focus · HN ↗
But yes I agree that as part of learning effort it's important to write, too.
nrr · · focus · HN ↗
I harped on checking someone's ability to debug code back when I interviewed candidates, in part because I found that people who could debug effectively could also sniff out bad code. It was something of a bonus that I also happened to select for candidates who could explain their debugging strategies and what that meant for the software they were working on.
bluefirebrand · · focus · HN ↗
But you're right. The better indication of capability is debugging skill than writing skill.
nrr · · focus · HN ↗
One of the first things I do in any new-to-me project is set breakpoints in the integration tests and start stepping through the code so that I can establish some mental context. However, if there aren't integration tests, I begin writing them so that I can walk around with my debugger.
tripledry · · focus · HN ↗
dimonomid · · focus · HN ↗
tripledry · · focus · HN ↗
[dead]
Gisbitus · · focus · HN ↗
gravypod · · focus · HN ↗
I think if I fully understand everything the agent is going to do and trivially verify the output quality, LLMs are a win. For one off prototypes, the same is true. For software which is unique, complex, and performing a task which has not been fully specified I find myself needing to drop into my editor more and more.
Recently I've been moved to a research focused team and I really need to have proof that something is happening. I've had Claude Opus 5 gaslight me by telling me it did something and when I read the code it obviously did not. This happens more and more with my tasks that are kind of complex.
I've found a lot of the claims by AI people have been 6mo - 2 years "ahead" of my experience. I think we are now in an era where harness engineering is highly valuable (making a test, looping an agent, manually annealing with new ideas) but the claims that no one writes code manually seems like it may not be fully there for all code.
arcrae · · focus · HN ↗
ghthor · · focus · HN ↗