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

461–470 of 511 posts

Re: Using AI to write better code more slowly

#461

Post by skydhash »

bottlepalm wrote: post #421
skydhash wrote: post #187

Earlier quoted context omitted.

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 pot…

Then I’d suggest you take a step back and truly think about the design of your project. Before even coding, you should start thinking about contracts (interfaces) between those so implementation changes does not ripple across the whole project. Having a change in a worker bubble up is a sure sign of a big ball of mud[0].

[0] https://www.laputan.org/mud/mud.html#BigBallOfMud

Re: Using AI to write better code more slowly

#462

Post by bitexploder »

jerf wrote: post #345
bitexploder wrote: post #335

Earlier quoted context omitted.

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 evalua…

They do still attenuate their latent space on prior conversations turns as authority. That is why I like pure design/review sessions and pure coding sessions, often at the same time. I can often keep design and review in the critic and review role without becoming a sycophant. Coding agent just picks up dispatches and works with very little opinion at all.

Re: Using AI to write better code more slowly

#464

Post by jimbokun »

nickcw wrote: post #233
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 are very prone to priming in my experience. That is the human psychology name for what you are describing; whether it should be applied to LLMs I don't know, but it describes the phenomenon perfectly.

Makes sense as priming is at the core of how an LLM is trained.

“Given these words, predict the next word.”

Re: Using AI to write better code more slowly

#466

Post by hackerthemonkey »

epolanski wrote: post #364
8cvor6j844qw_d6 wrote: post #336

Earlier quoted context omitted.

> LLMs flip positions when users push back Same experience. Claude rarely pushes back once you give a plausible/logical reason for your initial decision, even if it flagged concerns at first.

Skills help there. I have a linus-reviewer skill that focuses on architectural integrity, no bs, etc modeled on Torvald's code preferences. And I have an enrico-reviewer one (I'm Enrico), that focuses on correct design, strict typing, simplification. They have different prios, but they both push back on feedback, till you convince them.

Care to share the skill behind the Linus reviewer ? I tend to as it to do that but leave it up to LLM to decide what the means. Interested to see any specifics you might have included there if it’s ok to share.

Re: Using AI to write better code more slowly

#467

Post by fransje26 »

germanptr wrote: post #237
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…

I follow a similar approach and use multiple LLMs per task. The quality improvement is surprisingly large. Lately I’ve been experimenting with adding an explicit reward function so the models optimize for measurable output quality. This creates a generate, critique, revise loop where candidate answers compete for a higher score. It feels promising because it reduces the amount of handholding for every task. It is als…

> I follow a similar approach and use multiple LLMs per task.

Pardon my ignorance, but how would go about doing that on, say, a standard c++ project?

I get the part where one can use codex/claude with an ide and/or extension. But how does one connect two LLMs together in such a setup?

Re: Using AI to write better code more slowly

#468

Post by juanre »

This sounds very right. My rule of thumb is at least 50% of the AI work is supervising, reviewing, guiding and bug-finding. A codex session that started a pretty significant chunk of work this morning has just informed me that it thinks that it's done,

Final usage: 5,245,839 tokens over about 10 hours 3 minutes.

It's quite remarkable that the result looks actually correct. But through all this time two more agents (one claude code and another codex under pi) were working alongside reviewing, criticising code, and finding bugs. It would have been impossible otherwise.

Re: Using AI to write better code more slowly

#469

Post by hackerthemonkey »

cladopa wrote: post #257

Exactly. That is what we do. We do software that can kill people and it is very sophisticated, like controlling robots and we prototype using LLMs and it is amazing. People believe that you can only use LLMs for sloppy programming. But you can also use it for writing ten times more code of Swiss cheese model tests, and domain specific languages. You write ten times more code than necessary and all that extra code is…

> Now we write tests and when all test pass we write new test for checking the tests

Care to expand on how is this accomplished?

Re: Using AI to write better code more slowly

#470

Post by epolanski »

hackerthemonkey wrote: post #466
epolanski wrote: post #364

Earlier quoted context omitted.

Skills help there. I have a linus-reviewer skill that focuses on architectural integrity, no bs, etc modeled on Torvald's code preferences. And I have an enrico-reviewer one (I'm Enrico), that focuses on correct design, strict typing, simplification. They have different prios, but they both push back on feedback, till you convince them.

Care to share the skill behind the Linus reviewer ? I tend to as it to do that but leave it up to LLM to decide what the means. Interested to see any specifics you might have included there if it’s ok to share.

Sure.

Would be interested in the experience others may have, took me weeks of iterations to get reviews in a format and utility I liked.

https://gist.github.com/enricopolanski/2bde8619f53307c9bcd5e...

Post reply on HN