Hacker News Reader

Comment by dimonomid | Hacker News Reader

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.

View on HN

I compare it to math, you can't learn it by reading it you need exercises. Same thing, reading is not sufficient. Just my experience.

Yeah if it's done as part of learning effort, then I def agree.

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.

You can't learn what good code is by reading it, you have to write code to learn what good code looks like

True, but having written enough (from many years of doing it full time), the returns from writing more are diminishing.

But yes I agree that as part of learning effort it's important to write, too.

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.

I don't really draw much distinction between debugging and writing code. You really can't do one very effectively without the other imo

But you're right. The better indication of capability is debugging skill than writing skill.

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.

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.

Reply on news.ycombinator.com