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

351–360 of 511 posts

Re: Using AI to write better code more slowly

#351

Post by gabble »

danielbln wrote: post #203
well_ackshually wrote: post #190

Earlier quoted context omitted.

>today's models can take well over a minute to execute it. A full, whole, entire _minute_ ?! Sixty seconds ! Oh no, they must be optimized away, we do not deserve our free time like so, we should toil until we fall over because... Growth? It's still context switching. Either what you're doing is surface enough that you don't give a shit, it doesn't matter and you don't review it anyways (so the only context is basica…

Don't be so dismissive. Every person is different, and you struggling with multitasking doesn't mean everyone is.

From [1]

The scientific study of multitasking over the past few decades has revealed important principles about the operations, and processing limitations, of our minds and brains. One critical finding to emerge is that we inflate our perceived ability to multitask: there is little correlation with our actual ability. In fact, multitasking is almost always a misnomer, as the human mind and brain lack the architecture to perform two or more tasks simultaneously. By architecture, we mean the cognitive and neural building blocks and systems that give rise to mental functioning. We have a hard time multitasking because of the ways that our building blocks of attention and executive control inherently work. To this end, when we attempt to multitask, we are usually switching between one task and another. The human brain has evolved to single task.

[1] https://pmc.ncbi.nlm.nih.gov/articles/PMC7075496/

Re: Using AI to write better code more slowly

#352

Post by freedomben »

8cvor6j844qw_d6 wrote: post #336
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

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

I have noticed this as well, but I think it's somewhat a good thing. I know what I want for my application more than Claude does for example, especially when it comes to what's in production.

An example from earlier, Claude strongly suggested a migration that would run a full vacuum on postgres. However, in production this would lock tables which would grind the application to a halt. After I informed Claude that there were millions of rows in production, it accepted that and helped me get to the right thing.

Another example, I'm developing a TOTP authentication app because I'm dissatisfied with all those that I've tried. I want something strictly local, and with a very easy use case when you have dozens or even a hundred or more accounts on there, that is also efficient when left open for long periods of time. Claude strongly suggested that we force users to encrypt their vault with a passphrase all the time. However this makes the CLI extremely painful to use if you are using a strong passphrase. I told Claude about the user experience impacts and that I wanted to allow users to optionally use a vault with no passphrase encryption, and it accepted that and suggested as a medium that we have a checkbox for the user to explicitly acknowledge that they're creating an unencrypted vault on disc. This is the right thing IMHO.

Re: Using AI to write better code more slowly

#353

Post by jwillmer »

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…

Check out jwillmer/ai-status at GitHub @bottlepalm. It helps keep track of all the small fixes that are going on simultaneously. I crated the tool for me since I have similar workflows.

Re: Using AI to write better code more slowly

#354

Post by danielbln »

gabble wrote: post #351
danielbln wrote: post #203

Earlier quoted context omitted.

Don't be so dismissive. Every person is different, and you struggling with multitasking doesn't mean everyone is.

From [1] The scientific study of multitasking over the past few decades has revealed important principles about the operations, and processing limitations, of our minds and brains. One critical finding to emerge is that we inflate our perceived ability to multitask: there is little correlation with our actual ability. In fact, multitasking is almost always a misnomer, as the human mind and brain lack the architecture…

Fair enough, so it's a misnomer. Let's call it task switching then, since we don't actually do tasks at the same time, but switch from one to the other. A Claude Code session helpfully prints a small tldr summary of the ongoing session, so that one can quickly onboard again to the task at hand. I do not find that draining, personally.

Re: Using AI to write better code more slowly

#355

Post by pcoyne »

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.

Yeah I feel like a rubber ducking with some feedback has been very helpful

Re: Using AI to write better code more slowly

#356

Post by TacticalCoder »

tags2k wrote: post #226
bottlepalm wrote: post #186

Earlier quoted context omitted.

$200/month split between Claude Code Max and Codex Pro. Given how many hours a month I spend programming, my hourly rate, the amount of time saved, and the productivity/quality boost - I would pay a whole lot more if I had to.

You are definitely going to have to. I see these massive skills as soon-to-be artefacts of the past, they will be unwieldy in the non-subsidised world. I won't pretend to know what replaces them.

We have lots of open-weight models like DeepSeek V4 Pro that are very close to SOTA and we know the cost of running them.

This helps keeps the other players honests: there's a limit to which they can raise prices when there are already alternatives today and when there's zero lock in.

That those companies can make revenues but only at the cost of burning investors money: that's not my problem.

My take on it is simple: "Give me something MUCH better than the best open-weight models at a price that's not crazy or you're not getting my money".

And it happens to be the take of many devs.

I'm still paying Anthropic, Google and OpenAI (OpenAI because I didn't manage to cancel my subscription and now their model is competitive vs Anthropic's models again) but eye'ing a "Pi + open weights" solution.

Raise the prices too much and those companies selling access to private models aren't getting my money anymore.

Re: Using AI to write better code more slowly

#357

Post by skydhash »

tikhonj wrote: post #329
zendist wrote: post #317

Earlier quoted context omitted.

> models write much better code than humans can What? I think this is either over exaggerating model capabilities or you haven't seen much good code from humans? My experience is that my colleagues which have bought into model-first development have regressed in quality of the PRs they send out. LLMs are not better coders, in my experience. They lack holistic understanding and often need course correction for that re…

Over my time in the industry I've become increasingly convinced most people haven't seen what good human programmers are like. Otherwise we wouldn't have the popularity of things like Scrum, Clean Code (the book, not the concept), etc. I was lucky enough to see some good teams when I was a student (both at Berkeley itself and by interning at Jane Street), and it totally changed my intuition for what good programming…

I’ve seen both side of the fence and if there’s one quality that seems to define that fence, it’s caring about the process. Both sides wants to archieve the same goal, but one care about the process (enough to make it less tedious) and the other don’t (whatever seems to work is Ok).

That’s why they say the best programmers are lazy. Not in the sense of avoiding any kind of work, but avoiding the kind of senseless stuff that’s surely to come down the line if you’ve not taken care of the process

Re: Using AI to write better code more slowly

#358

Post by blehn »

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 seems like a typical AI workflow, but isn't it dreadfully boring?

Re: Using AI to write better code more slowly

#359

Post by user43928 »

i_love_retros wrote: post #63
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 all sounds insane. If it requires so much back and forth with the AI why on earth wouldn't you just write the code yourself? At least then you build the mental model of the code and keep your brain healthy. Reading the comments in here about all the hoops people are having to jump through just to do the same thing they were doing a year ago without AI... and spending a fortune to do it! I think you've all got AI…

[dead]
Post reply on HN