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

421–430 of 511 posts

Re: Using AI to write better code more slowly

#421

Post by bottlepalm »

skydhash wrote: post #187
bottlepalm wrote: post #160

Earlier quoted context omitted.

Refactoring is the natural evolution of a growing application. Refactoring too soon, too fast is what we call over engineering. Too little refactoring and your code becomes spaghetti slop. Regardless - the application will change across all layers across its lifetime.

How many layers does your code have? Even with clean architecture, you only have 4 fundamental layers. And once you have v1, you’re mostly doing tweaking and copy pasting. Any huge refactoring is the business switching its main strategy. Take an OS like OpenBSD. It has three main layers. The syscall layer, the kernel layer, and the machine dependent code. But an OS is more spread horizontally with various subsystems…

Lets see, front end presentation, front end service, frontend api, backend to front end (BFF) api/routing, BFF logic, BFF api, backend routing, backend logic, backend database, worker routing, worker logic, worker storage.

And then the each of the service layers can be broken into layers themselves depending on the complexity of the business logic can be broken into layers as well. So yea a change in a worker can potentially bubble up through all the layers.

Re: Using AI to write better code more slowly

#422

Post by bottlepalm »

newsicanuse wrote: post #199
bottlepalm wrote: post #153

Earlier quoted context omitted.

Unfortunately the projects are still too big. Projects with hundreds of thousands to millions of lines of code can't be maintained by a single person reviewing all the the changes. And AI only increases the speed of iteration and the amount of code to review. We may need some sort of paradigm shift - like more powerful frameworks or even higher level languages that allow us to review less, but more functional code bl…

When AI tries to improve such large code base who even is going to review the changes?

Like I said, we either need more people or some paradigm shift in tooling that allows us to do more with less.

Re: Using AI to write better code more slowly

#423

Post by bottlepalm »

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.

Yes exactly. I don't like Codex not writing comments - and even proactively removing useful comments! There was some change in the last month that causes Claude to write crazy long comments. I routinely have to ask Claude to 'tighten' up the comments before the final commit.

Re: Using AI to write better code more slowly

#424

Post by bottlepalm »

locknitpicker wrote: post #137
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…

> 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. Code is never missing contexts. If what your code is doing is not obvious to the reader, it is bad code that needs to be fixed. Things like cryptic low-level expressions should be extracted to helper functions with descriptive names or even extracted into a class, and classes ne…

Ah the classic thinking that 'code documents itself'. It does not. Some devs are so full of themselves they think their code is so good that it is obvious what their intent was. It never is obvious, and just ends up as tech debt. Write comments.

Re: Using AI to write better code more slowly

#425

Post by throwaway7783 »

cold_harbor wrote: post #303
a_bonobo wrote: post #223

Earlier quoted context omitted.

I really like this pattern and use it often, this 'not showing my cards'. The second I hint towards the LLM what I prefer it will become sycophantic and invent nonsense why my preferred solution is better. I'm sure there's an interesting study on how users 'leak' their preference unintentionally to the LLM; perhaps when users list their options, they often put their prefered option first; but not showing the cards on…

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

Obviously this is just my experience. Claude code pushes back much harder than Codex.

Re: Using AI to write better code more slowly

#426

Post by aaroninsf »

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.

This.

This is what I tell people (including non-programmers interested in vibe coding), the results you get are product of... process. Formal process.

From this naturally emerges the other thing I tell people: domain expertise (or at least, familiarity and or capacity for learning) is still determinate of outcome.

I don't touch the code. But I do push back on expedience, laziness, inconsistency, and all the other recurring unsolved problems of generated code... and continue to play whack-a-mole in pursuit of process that whacks the moles.

Re: Using AI to write better code more slowly

#427

Post by NickC25 »

I believe this thinking can be abstracted to software design via AI in general. If you are thoroughly prepared, and keep things simple, it's incredible what help Claude or GPT can be.

I have Claude basically doing all the coding for me for a simple game I am making. However I don't consider this vibe coding. I spent several hours thinking out the design on a piece of paper, playtesting it in person. I came up with a list of potential mechanical issues within the game, and asked Claude to come up with more. It found more issues, and we solved them all together. Once the game was mechanically sound and edgecases were solved for, it built an MVP. I ran the program, and found more bugs. I came up with my own solutions, and Claude did the same, and we figured out which were best to implement. Claude then wrote more code, and raised issues when they came up, and we worked through them together. I'm incredibly happy with how its turned out so far.

Re: Using AI to write better code more slowly

#428

Post by zahlman »

TACIXAT wrote: post #30

This article doesn't address writing code with AI, just code review. My issue with agentic coding is that I make numerous micro-architectural decisions while programming. I almost never have a full spec up front and develop one as I consider what I am writing. When using Claude Code or Codex, that is all gone. Claude Code is extremely eager to reach the end goal to the point that it feels like a fever dream to write…

> but I fear that workflow is just chat, search, and being a rubber duck for my thoughts.

That's still a lot of benefit, though. I have to agree with Patrick McKenzie on this one (https://x.com/patio11/status/2058631943785488815):

> If the only impact of LLMs professionally was causing people to "think out loud" in a way which was routinely captured by computer systems and then could be operated on by computer systems, that would by itself be one of the most consequential changes in practice in 100 years

Re: Using AI to write better code more slowly

#429

Post by sailfast »

This approach works well, and leads to better code being shipped. The key disconnect for me is not always the code being of high quality, but ensuring my understanding of the "Why" of the bug and the fix is good enough to justify it and then also explain it if the time comes.

That said, I'm learning to let go as much as I can and trust these things when it's "safe" and seeing how that shakes out. The risk is something falls over and I don't know how to fix it (of course) but I know it's a risk and I'm trying to avoid it so it probably won't be as bad as I catastrophize.

Re: Using AI to write better code more slowly

#430

Post by zahlman »

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?

Post reply on HN