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

301–310 of 511 posts

Re: Using AI to write better code more slowly

#301

Post by mns »

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…

When I first read the comment I thought this must be satire, it sure does sound like a Silicon Valley episode, but in modern times. I've been a skeptic for quite some time, but managed to get quite good results with Claude in general, not even going through the normal limits for a Pro account, but what people are describing here seems like just tokenmaxing, brute forcing a solution, I don't understand what code people need to write and what projects people are building, is everyone just constantly rewriting systems from scratch, or what is everyone spending these insane amounts of tokens on?

Re: Using AI to write better code more slowly

#302

Post by justbees »

democracy wrote: post #66
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…

Similar approach, but I also go a step further with some basic manual architecture/high level contract/stubs setups, just to keep it consistent with other systems (and easier reading as well).

I've been doing the same thing lately and I definitely feel like stubbing out the high level architecture at the beginning makes a difference. The codebase I'm in now has very particular ways of doing things and claude doesn't always pick that up.

Style can be as important as substance.

I still do a lot of back and forth about the plan - have it written to a file. Read through the file, make changes by hand and have claude read my changes and on and on. But starting with the basic architecture there's less ambiguity.

Re: Using AI to write better code more slowly

#303

Post by cold_harbor »

a_bonobo wrote: post #223
throwaway7783 wrote: post #141

Earlier quoted context omitted.

I follow the same process. I have a design in mind for the problem at hand, but I don't reveal it to Codex. I go back and forth a bit to see if its proposals are better than mine. I go back and forth on tradeoffs of various approaches. And then I ask it to compare its proposals with mine. I "win" most of the time but there are many times where it shows a me a better, or simpler approach, or makes me rethink the solut…

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

Re: Using AI to write better code more slowly

#304

Post by bonoboTP »

leetrout wrote: post #296
bonoboTP wrote: post #292

I find that it really is effective when you iterate and plan and review, but the problem is more psychological on the human side. It's just too easily available to take the lazy option and just let it do the thing, postpone the thorough reviewing and you end up in a similar situation as tech debt. In an ideal world with no deadline pressure and infinite discipline, AI can be used in productive ways for sure. But when…

I discovered something about myself a few years ago... I have to simmer in my work and let my head get wrapped around it. My visual for this is a capybara soaking https://www.gettyimages.com/detail/news-photo/capybaras-take... I am very visual and spatial. The first investment I make in my home or even visiting somewhere for more than 3-4 days where I will need to work without coworking is buying a whiteboard. So now…

I can't comment on cleaning toilets as a job (luckily I don't have to do that), but cleaning at home does provide a sense of accomplishment similar to solving a coding task elegantly and cleanly, while uninvolved AI-assisted coding is more like up and down voting or liking posts in algo feeds. Not fully like that of course, but it's a step towards that kind of "I like this part, I don't like that part" feedback-giving that can leave me depleted/drained. Coding before AI was more like when you feel one with the machine, like when you drive your car on autopilot, and with AI it's like sitting in the passenger seat like a driving instructor saying how to go about the driving. You do t quite know what it will answer, maybe it will push back on your idea when unnecessary and then I have to expend effort in arguing in text in a chatbox with a machine, or it goes forward too easily without asking clarifying questions or pushing back when what I ask collides with previous things. Many programmers get depleted in meetings and in language-based argumentation and charge up with the more puzzlesolving-like flow state, but this AI wrangling is often more like team meetings.

Re: Using AI to write better code more slowly

#305

Post by bonoboTP »

convenwis wrote: post #294
bonoboTP wrote: post #292

I find that it really is effective when you iterate and plan and review, but the problem is more psychological on the human side. It's just too easily available to take the lazy option and just let it do the thing, postpone the thorough reviewing and you end up in a similar situation as tech debt. In an ideal world with no deadline pressure and infinite discipline, AI can be used in productive ways for sure. But when…

"It's just too easily available to take the lazy option and just let it do the thing" This seems to me to be one of the key problems for AI usage in general. Students have this problem where it can be incredibly helpful in actually learning but late at night with the assignment due early tomorrow the temptation is just too strong to have it do the thing.

Somehow I find that interacting with AI doesn't make me feel the same way as diving through Wikipedia rabbit holes. With AI it feels more like, it starts saying how there is indeed an answer to some science question I was unsure about, about some phenomenon or about how some technology works, and it starts explaining it but I feel disinterested in actually reading it's answer. I see it's general shape and I feel satisfied in the existence of the answer. It may be the glazing sycophancy too, but it seems that I get the "satisfaction" from just getting the answer, while with Wikipedia I only got it once I dug up the info that I needed. And the AI answer is ephemeral, while the Wikipedia page is there for everyone, it's a thing, even if it can change.

Same with AI images. It feels good for 2 seconds to see what I asked for and I'm immediately disinterested. Same way, I've generated many Suno songs, but I don't care about them after a few listens.

Re: Using AI to write better code more slowly

#306

Post by skydhash »

gitaarik wrote: post #86
rootnod3 wrote: post #12

Earlier quoted context omitted.

And then Anthropic has an outage and you what...have a coffee break until then? All that time babysitting the AIs just to be a little faster but probably with less knowledge/control over what they did?

What do you do when your search engine goes down?

I have all the relevant sites for my projects in my browser history. A search engine is just a quicker way to get to a particular page.

Re: Using AI to write better code more slowly

#307

Post by KronisLV »

jillesvangurp wrote: post #260
KronisLV wrote: post #252

Earlier quoted context omitted.

> Regardless of what model you use, agentic coding tools are indeed pretty good at finding issues if you target them a bit. And they have no respect for their own code or any sense of shame. So, you can just point them at their own code with a new thread. Many AI models seem biased to cutting corners by default when generating code, even when you ask them not to. But a few simple follow up prompts can address that. T…

This can backfire a bit on token usage where it gets a bit to trigger happy running expensive things for trivial changes. I tend to not use sub agents for this reason. I actually manage to cover most my needs on the 20$/month codex subscription. I might switch to the 200$ plan at some point. But right now I just need to be economical as our company is fairy resource constrained. That's also why I prefer Codex over Cl…

I just have the Anthropic 100 USD Max plan and it's enough for daily work - I sometimes do hit the 5 hour limits by mid day, but weekly ones usually cap out at around 80% or thereabout, even with this approach. I usually use xhigh, sometimes max, both still result in situations where I need to intervene plenty, not even on that complex use cases (some LLM stuff, mostly web based CRUD, some light data processing, integrations with Jira and GitLab, processing PDFs and so on, sometimes ML training and geospatial work, like the Sentinel-2 satellite data, nothing crazy).

If I had to pay per token, I'd probably look at DeepSeek. In general it feels like it's a bit early for the technology - either our software methods are wasteful, or the hardware hasn't caught up. To me, it appears that we often need to throw more tokens at these problems, not less, since otherwise it's just one-shot slop.

Re: Using AI to write better code more slowly

#308

Post by Strom »

rtpg wrote: post #300
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…

tbh I'm just confused at why people ask AI to design features. Do you not know how to design a feature? Do you not know what you want? This stuff works so much better when you just tell it what to do

The designing is the hard part. Writing code from a comprehensive design spec is a small part of the task.

So, people do know how to design a feature, but they also know it takes a lot of time and effort. They want AI to do that work for them.

Re: Using AI to write better code more slowly

#309

Post by KronisLV »

esperent wrote: post #259
KronisLV wrote: post #252

Earlier quoted context omitted.

> Regardless of what model you use, agentic coding tools are indeed pretty good at finding issues if you target them a bit. And they have no respect for their own code or any sense of shame. So, you can just point them at their own code with a new thread. Many AI models seem biased to cutting corners by default when generating code, even when you ask them not to. But a few simple follow up prompts can address that. T…

> once all the code seems okay, you will run THREE parallel sub-agents for code review: each looking at ALL changed code I did some evals with a prompt like this when I had some subscription tokens to burn, a few months ago. I think using Opus 4.5. What I found was: 1. Running two subagents was somewhat useful 2. Running three started to get redundant 3. Any more than three was pointless (at least when using the same…

You can get reasonably close with fewer, however more agents give better signal: e.g. if 3/3 flag something as an issue, the outer one that orchestrates them can view it as something to give more attention to, whereas if it's just 1/3, then it probably begs more consideration. Ofc more doesn't always imply right.
Post reply on HN