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

111–120 of 511 posts

Re: Using AI to write better code more slowly

#111

Post by halfcat »

ianm218 wrote: post #53
ai_fry_ur_brain wrote: post #45

Just dont use it lol, it does nothing you cant do by yourself. You're nerfing parts of your brain by relying on it.

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?

Re: Using AI to write better code more slowly

#112

Post by atomicnumber3 »

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…

"yes exactly. Too many people ask AI to one-shot complex tasks, and wonder it behaves like a junior asked to rush something."

Because this version of AI is worth 10 trillion dollars.

While the pragmatic versions from realists you can find all over this thread are ultimately probably less of a speed boost than just having your CEO/local micromanager be conveniently on vacation during critical periods when the work actually gets done.

Re: Using AI to write better code more slowly

#114

Post by bottlepalm »

halfcat wrote: post #91
afavour wrote: post #25

Earlier quoted context omitted.

I don’t think you’re quite getting what OP is describing. I work in a similar way… I am aware of all the code being written. If Claude had an outage I could write it myself. It would just take longer. You say “all that time” babysitting AIs but in my experience it isn’t that much time, if anything the back and forth at the planning stages is more productive than when I’m doing it by myself because I’m being asked que…

How do you stay aware of all code being written? Maybe it’s just me, but I’ve never understood how one understands from reading code. Yes you can understand what that code does, but not why it was done that way instead of a different way. In the end I only understand it deeply if I end up writing it. Chatting through it is helpful to me, but having AI crank out code loses all of that context pretty quickly. I’m not d…

If you can't understand why the code is done in a certain way from reading it then the code is missing comments or needs to be refactored.

Even code you write yourself, given enough time, you will forget the why unless you wrote comments. In a way comments are as much for you as they are for others.

Even before AI, understanding code you didn't write is essential to working on a team of other developers. If you can't understand the code from reading it, then that's part of the feedback loop - too complex, needs comments, etc..

On large teams you'll spend as much time reading code as you do writing it. And long term when it comes to writing maintainable code - the ability for others to read and understand it, including the why of it, is paramount. Your code could literally be around for decades.

Re: Using AI to write better code more slowly

#115

Post by hintymad »

On the other hand, some companies are pushing the idea that engineers should build robust self-evaluating agent pipeline with human feedback in the loop so that agents write most of the production code. Creao's CEO said that they rearchitected their entire production systems in two weeks this January. He also claimed that their agents implemented so many features so fast that they had to wait their business development to catch up.

I wonder how we can evaluate these two options: using AI to 100X the output versus using AI to advance one's craft.

In the meantime, the productivity gain of AI is real. Case in point, An engineering org of Snowflake has met all its OKRs ahead of time in the first quarter for the time in the company's history. It had never happened, and usually meeting 70% of the planned OKR would be considered an achievement. I can imagine the stress of the engineers when they see such outcome.

Re: Using AI to write better code more slowly

#116

Post by qsera »

busterarm wrote: post #82
qsera wrote: post #65

Earlier quoted context omitted.

>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.

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

Yes, I thought the same as well because that was the same line of thought that made me write my comment.

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

Yea, they are like a slingshot. You need to let go at some point or else it will drag you back.

Re: Using AI to write better code more slowly

#119

Post by bottlepalm »

habinero wrote: post #106
bottlepalm wrote: post #100

Earlier quoted context omitted.

A lot of people say you need to go through at least three versions of something before it is mature - and v3 is not something you can design upfront. You need to see v1 both in code, and at runtime. Use it, get the feedback, and iterate. This is where AI tightens that loop immensely. Lost you in the last paragraph - features are not "copy pasting because you already have all the building blocks" and "something may be…

> Mid sized features often mean tearing up many layers of code across the stack to add in some sort of new capability What? No, it shouldn't. I've worked on a lot of codebases and if you have to do this, something is very, very wrong.

Nothing wrong at all. Some features you can bolt on, and some features fundamentally change how a system works requiring changes at many different levels of the stack. Happens all the time.

Re: Using AI to write better code more slowly

#120

Post by vatsachak »

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.

I agree with this take. But this take also means that actual productive token use is not as high as people currently make it out to be.

AI is an excellent rubber duck and test writer. Maybe I sniff my farts too much but I like my code just the way I want it lol

Post reply on HN