Live data from Hacker News

Using AI to write better code more slowly

nolanlawson.com

81–90 of 511 posts

Re: Using AI to write better code more slowly

#82
post #65
post #59

Earlier quoted context omitted.

Talking the problem to death with the AI before implementation is a nice zone for me. I feel productive, get good results out of the AI, and still largely understand the code. That’s the part of the AI revolution that I feel has made me a better engineer because I argue about design and architecture all day with a robot.

>I argue about design and architecture all day with a robot. You will outgrow it at some point.

nullsanity's comment is dead and downvoted to oblivion but also incredibly underrated.

I was more annoyed than anything that I didn't hit this moment until my 40s.

Except it's not just reddit (I quit reddit 15 years ago). It's the whole internet.

Re: Using AI to write better code more slowly

#83
post #59

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…

Talking the problem to death with the AI before implementation is a nice zone for me. I feel productive, get good results out of the AI, and still largely understand the code. That’s the part of the AI revolution that I feel has made me a better engineer because I argue about design and architecture all day with a robot.

Despite the cynical sibling reply, I also feel like there's real value here. Contrary to the meme, I don't think Claude just tells me I'm brilliant, but really does push back on directions that are unproductive, helps identify when a part is overcomplicated or a dependency has become redundant, etc. Those are important things to have at least a sightline on before getting too deep into the code, even (or maybe especially) in a world where an awful lot of code can be created basically for free.

Re: Using AI to write better code more slowly

#84
post #65
post #59

Earlier quoted context omitted.

Talking the problem to death with the AI before implementation is a nice zone for me. I feel productive, get good results out of the AI, and still largely understand the code. That’s the part of the AI revolution that I feel has made me a better engineer because I argue about design and architecture all day with a robot.

>I argue about design and architecture all day with a robot. You will outgrow it at some point.

Or learn something at some point.

https://en.wikipedia.org/wiki/Rubber_duck_debugging

Re: Using AI to write better code more slowly

#85

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…

And then Anthropic has an outage and you what...have a coffee break until then? All that time babysitting the AIs just to be a little faster but probably with less knowledge/control over what they did?

Company I'm familiar with that went all in on Codex ran out of tokens for a week and wouldn't increase their spend.

I pretty significant number of their engineers flat out refused to work. Like publicly said so. "Increase our plan or I'm taking the week off."

Re: Using AI to write better code more slowly

#86

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…

And then Anthropic has an outage and you what...have a coffee break until then? All that time babysitting the AIs just to be a little faster but probably with less knowledge/control over what they did?

What do you do when your search engine goes down?

Re: Using AI to write better code more slowly

#87
post #65
post #59

Earlier quoted context omitted.

Talking the problem to death with the AI before implementation is a nice zone for me. I feel productive, get good results out of the AI, and still largely understand the code. That’s the part of the AI revolution that I feel has made me a better engineer because I argue about design and architecture all day with a robot.

>I argue about design and architecture all day with a robot. You will outgrow it at some point.

I think this is OK though. We can still micromanage[0] the code generation part for a useful productivity boost, I think.

[0] At least, in my experience, "micromanaging" the AI is what gives me the best results. Iterating on the initial design, then iterating on the plan, then reviewing the proposed code changes (including tests), then getting an independent code review from another LLM, etc. If you give an LLM too much latitude that's when the really shitty code and ill-considered breaking changes/obliteration of existing functionality starts to creep in.

Re: Using AI to write better code more slowly

#88

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…

maybe it's dumb question, but how do you feed the results of one agent to another? do you copy and paste manually? or how do you do it programmatically?

Yea I'll take the review feedback from one, validate it, and then copy/paste it into the other session saying like, "hey I got this feedback, what do you think?" So I'm not even telling the other AI the feedback is valid, I want it to independently validate it. Often the feedback is not like a bug, but a red flag, design consideration, or trade off.

Often depending on how complex the feedback, I'll do it one at a time addressing each one individually. And after the feedback is addressed, I'll go back to the AI that generated the feedback and say like, "I handled 4/5 items you found, can you double check."

It's similar to handling PR feedback, where you do it, validate it, but then still have to submit it for peer review.

Re: Using AI to write better code more slowly

#89

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…

At this point one might as well code by themselves

Re: Using AI to write better code more slowly

#90
post #38

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…

If your AI is writing bad code then you need to change your AI. No current high-end AI should be producing bad code.

Source trust me bro.
Post reply on HN