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

341–350 of 511 posts

Re: Using AI to write better code more slowly

#341

Post by surajrmal »

manmal wrote: post #129
bottlepalm wrote: post #114

Earlier quoted context omitted.

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…

Codex barely writes any comments, while Claude makes a slop article for every one line commit. I’d enjoy something in the middle.

Try antigravity. I think it generally has the right level of comments.

Re: Using AI to write better code more slowly

#342

Post by kobe_bryant »

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.

even if that were true its the exact opposite point the article is trying to make

Re: Using AI to write better code more slowly

#343

Post by topheroo »

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…

This is where I’m at too lol.

Re: Using AI to write better code more slowly

#344

Post by busterarm »

democracy wrote: post #183
busterarm wrote: post #85

Earlier quoted context omitted.

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

so how did this go?

management flinched first.

Re: Using AI to write better code more slowly

#345

Post by jerf »

bitexploder wrote: post #335
cold_harbor wrote: post #303

Earlier quoted context omitted.

LLMs flip positions when users push back ~70% of the time even when they were right. RLHF optimizes for approval, not correctness

I almost always end with something like: “, but I am not sure, evaluate.” Or other things and avoid ever stating a preference.

I don't think that "fixes" the problem, but it does seem to help. I also have found adding "please feel free to ask questions" seems to help it stop from making an assumption and spinning merrily onward for tens of thousands of tokens based on a bad idea rather than asking you something. I theorize this is because the training and refinement data overprioritize one-shot solutions, both because that's easier to evaluate at training time and improves their benchmarks. But I emphasize the italicized words because that's all gut feel and I can't prove any of it.

Re: Using AI to write better code more slowly

#346

Post by deaton »

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 think this is honestly the #1 best use case for AI in development. If you use it right it can be exactly the annoying junior who questions every decision you make that you need.

Re: Using AI to write better code more slowly

#347

Post by biorach »

habinero wrote: post #197
bottlepalm wrote: post #155

Earlier quoted context omitted.

Semantics. In reality yes it is the v3 version equivelent in terms of maturity and iteration. I know because I've been doing this for a long time. We are getting to v3 and beyond faster than ever before. In the new world there is no time to put out v1 quality code and it is borderline reckless given how easily things are getting hacked now. You need to be putting out heavily reviewed code that covers all the corner c…

No, you're getting to v1 in the same or more amount of time. I know v3 sounds better, but coding and throwing it away is literally just redoing it. If you're not releasing it, it's not a new version. There's no such thing as "v1 quality code", you just haven't finished it yet.

You've missed the point

Re: Using AI to write better code more slowly

#348

Post by surajrmal »

well_ackshually wrote: post #46
efitz wrote: post #32

Earlier quoted context omitted.

If you only have one AI window open, you’re doing it wrong. You task swap to another window/agent, get it working on something, rinse and repeat. I can keep 4 busy most of the time. When I task swap I also check in on what the other agents are doing to make sure they’re on track, not blocked and not struggling.

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

If you have ever TL'd a team, it doesn't sound too crazy. I have 8 folks I generally talk to very consistently throughout the day. If I'm not in 1:1s with them I'm usually reviewing their changes or chatting with them over chat. I don't think I can do all of that and work with a bunch of AI windows, but I do think they could likely do something similar to me with several agents running in parallel.

Re: Using AI to write better code more slowly

#349

Post by sarchertech »

dozerly wrote: post #154
goatlover wrote: post #130

Earlier quoted context omitted.

Hopefully not, but there was recent thread with multiple posters arguing that code quality doesn't matter, and quality produced by humans in the past was often terrible. So who cares, ship it was the sentiment. Let the AIs handle the growing maintenance cost, I guess? Kind of a shocking thing to see argued on HN. Maybe it's just the vibe coders.

The vast majority of corporate-employed programmers write bad code. I think maybe 10% of the people I’ve come across have shown any interest or care in the quality of code they write. There will be a large majority of people who hold these opinions, because they weren’t capable of or didn’t care enough to write good code in the before times

The real problem with these conversations is that code quality isn’t something we have any kind of consensus on.

To a lot of engineers code quality means upper-case C Clean Code. Other engineers are in the Grug brain camp where they think that premature abstraction is the worst kind of code.

But to your point I think the majority of engineers think they high quality code is anything that compiles or passes their (almost definitely insufficient) test suite.

Re: Using AI to write better code more slowly

#350

Post by econ »

sarchertech wrote: post #349
dozerly wrote: post #154

Earlier quoted context omitted.

The vast majority of corporate-employed programmers write bad code. I think maybe 10% of the people I’ve come across have shown any interest or care in the quality of code they write. There will be a large majority of people who hold these opinions, because they weren’t capable of or didn’t care enough to write good code in the before times

The real problem with these conversations is that code quality isn’t something we have any kind of consensus on. To a lot of engineers code quality means upper-case C Clean Code. Other engineers are in the Grug brain camp where they think that premature abstraction is the worst kind of code. But to your point I think the majority of engineers think they high quality code is anything that compiles or passes their (alm…

HQ is 0 lines
Post reply on HN