Live data from Hacker News

Using AI to write better code more slowly

nolanlawson.com

211–220 of 511 posts

Re: Using AI to write better code more slowly

#211

I find myself spending on average more time in LLM review/resolution loops than it would take for me to write the code by hand. Partially because once I'm in the flow I write very very quickly and the code pours out sometimes faster than I can write. But also because the LLM code on the first few tries is generally really really bad. What I find interesting though is that spending the time to personally review and di…

[flagged]

Re: Using AI to write better code more slowly

#213

Very much agreed. Something specific that has helped me a lot (beyond just automatic formatting, linting and testing) was putting a hard fail on any file with more than 1500 lines or so, with an allowlist for specific files with specific reasons for their length. I realized the agents were squirreling away code without wanting to do any sort of refactor. Every time one of these rat's nests has turned up, the codebase…

200 is my preferred limit, and I think you can find that in a few highly regarded books on coding.

Re: Using AI to write better code more slowly

#214
Another thing that I feel is underappreciated about agentic coding is that you can actually learn from it. I am a programmer with 25+ years of experience and I tend to do a lot of stuff according to fixed patterns/habits. Seeing how my coding agents do stuff helps me break out of these patterns, lets me consider new approaches, helps me pick up idioms and teaches me new hacks and tricks. That is very satisfying in its own right.

Re: Using AI to write better code more slowly

#215

I've hit this point with AI where it's not a simple process, but a long drawn out back and forth. I'll use AI to design the implementation of a medium sized, cross cutting feature. Review all the details, maybe iterate on just that. Then implement with Claude 4.7 Max - which runs slower, but does a better job. Then review the implementation, then have Codex GPT 5.5 xhigh fast review it - which almost always finds cor…

This exactly my process as well. Although interestingly I swap Codex and Claude; having found Claude way more pedantic in its reviews and codex more pragmatic in its implementation. Maybe it differs per programming language.

Re: Using AI to write better code more slowly

#216

I find myself spending on average more time in LLM review/resolution loops than it would take for me to write the code by hand. Partially because once I'm in the flow I write very very quickly and the code pours out sometimes faster than I can write. But also because the LLM code on the first few tries is generally really really bad. What I find interesting though is that spending the time to personally review and di…

This feels like a comment from 2 years ago; by now the most modern models write much better code than humans can in much shorter time.

But if you're not used to code reviewing, it can certainly help to still write yourself.

Re: Using AI to write better code more slowly

#217

Earlier quoted context omitted.

I think as long as it continues to be tangibly better these people will still exist and the intersection will continue to be valuable enough to survive.

> as long as it continues to be tangibly better these people will still exist Sure. But how long will that last? LLMs are getting better at programming much faster than I am. Imagine a plot with time on the X axis and LLM skill on the Y axis. The line goes up and to the right. On the left is GPT3, or GPT3.5 with the very first glimmers of programming ability just a few short years ago. In the middle is Opus 4.7 now.…

I think the problem is is that coding is not wholly a 'writing code' problem. It's a translation from idea to outcome. Often I think the bad code generated by an LLM is less to do with it's 'ability' and more to do with an instruction that hasn't adequately accounted for the possibility of what code satisfies the criteria. I'm not sure how a newer model can improve on this per se - sure there will be imrpovement on outright mistakes but for me at least, that's been and gone with more or less with any model released in te last 6 months.

Re: Using AI to write better code more slowly

#219

I've hit this point with AI where it's not a simple process, but a long drawn out back and forth. I'll use AI to design the implementation of a medium sized, cross cutting feature. Review all the details, maybe iterate on just that. Then implement with Claude 4.7 Max - which runs slower, but does a better job. Then review the implementation, then have Codex GPT 5.5 xhigh fast review it - which almost always finds cor…

I am not switching the different LLMs as much, but my approach is similar:

1. I write a list of things I want to have without AI support

2. I discuss the list with an LLM, which occasionally reveals obviously missing things I hadn't thought about or just things that would be smart to have. Or sometimes the LLM doesn't get it and wants to funnel me down a commonly walked path, which is a non-goal

3. From that list I draft an implementation plan containing things like how the code shall be structured, which language, libraries, build systems, etc to use. This may even contain some data models and considerations that are more detailed, like for example ideas about how a specific interaction shall be event sourced. I work on that, till I feel a satisfactory level of clarity has been reached

4. Actual writing of code as a back and forth between manual writing, letting an LLM write something and so on. LLMs suck at writing CSS that feels like good UX design to me, so usually templates, layout and CSS will be (re)written entirely by hand

5. Bug-hunting and guessing potential edge cases is one thing where LLMs really shine. Often if the work before that was quality the LLM has an okay time coming up with fixes that are no worse than what I would have done.

Re: Using AI to write better code more slowly

#220

Earlier quoted context omitted.

congratulations on your soon to be coming burnout. Keeping that many tasks in parallel, running all the time will kill you.

It's great to work from home so you can take nice little micro naps while code's generating, reviewing, building, and deploying. A calm attentive alternative of vibe coding: restful coding. It's much easier to read and review code after a refreshing cat nap, especially with a real cat. Too bad that's not usually acceptable to do that in the office. It should be! Slacking off by sword fighting all day is too exhaustin…

Nap while you can. The baseline is slowly raising; AI fed with organization context will hunt you down and lay you off, as it has done at multiple companies this spring already.
Post reply on HN