Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Using AI to write better code more slowly

nolanlawson.com

Post reply on HN
Print view View original

501–510 of 511 posts

Re: Using AI to write better code more slowly

#501

Post by ianm218 »

halfcat wrote: post #111
ianm218 wrote: post #53

Earlier quoted context omitted.

There is things you really can't do by yourself. I've been working on porting some large codebases to Rust lately to experiment with fixing memory safety bugs. There is just no way you can write 100k LOC in a week of production code with tons of tests etc. Even "10X" engineers just can't type that fast.

How would one even know if the port of 100k LOC was successful? Are there language-agnostic tests (CLI STDIN/STDOUT) or similar involved?

I was using large official test suites + lots of tests I generated that test input/ output is byte identical over thousands of commands.

You wouldn’t want to ship it straight to prod but it’s a start.

Re: Using AI to write better code more slowly

#502

Post by ianm218 »

ultimaweapon wrote: post #224
ianm218 wrote: post #53

Earlier quoted context omitted.

There is things you really can't do by yourself. I've been working on porting some large codebases to Rust lately to experiment with fixing memory safety bugs. There is just no way you can write 100k LOC in a week of production code with tons of tests etc. Even "10X" engineers just can't type that fast.

What language you are trying to port from?

C to Rust. c2rust exists but isn’t particularly helpful if you want it to be safe/ performant code anyway.

Re: Using AI to write better code more slowly

#505

Post by mordv »

zahlman wrote: post #430
justinlivi wrote: post #11

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…

>the code pours out sometimes faster than I can write. Meaning that you type the code faster than you would normally type prose? Or just what?

Meaning the code comes to you out of nowhere faster than you could write it down. At peak performance, there is no you in the process, you just not preventing it from happening. That's what flow state is. The more skills, the better tools you have (such as typing speed, fine tuned IDE) the longer you could stay there.

Re: Using AI to write better code more slowly

#506

Post by golly_ned »

aomix wrote: post #59
bottlepalm wrote: post #4

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.

From the other end, I've seen this go wrong a couple ways:

When I'm doing it: I can go on way too long trying to consider way too much, when really, putting down some code and reading it and writing it myself would give me a better understanding.

When others are doing it: they can get very entrenched in a certain way of thinking, and are sure it's correct because of their AI conversations. Some context or data point was missing from their conversations with the AI.

Re: Using AI to write better code more slowly

#509

Post by notgenerated »

scosman wrote: post #19
bottlepalm wrote: post #4

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…

yes exactly. Too many people ask AI to one-shot complex tasks, and wonder it behaves like a junior asked to rush something. I have my own skill: 5 rounds of research/planning/test-planning. Interactive with me in loop for all important decisions. Starts with high level shape, then details. Planning can take 2-3 days of my time, then the implementation agent can take many hours (Opus 4.7). It splits the implementation…

I think that in general, people need to understand that they need to invest most of their time in the planning phase. High level plan, then spec are the baseline imo
Post reply on HN