Live data from Hacker News

Using AI to write better code more slowly

nolanlawson.com

361–370 of 511 posts

Re: Using AI to write better code more slowly

#361
post #59

Earlier quoted context omitted.

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.

One strategy I use in the planning phase is even when I know how I'd implement the solution, I ask the Claude/Codex how they would solve the problem or implement the feature without giving them any clues - and then compare their solutions to my own. Often I am pleasantly surprised by alternative ways of doing things and ideas that we integrate into the final design.

I like this, though it does leave me feeling more nervous when I really don't know how I'd solve the problem, still requires trust.

Re: Using AI to write better code more slowly

#362

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…

> If it requires so much back and forth with the AI why on earth wouldn't you just write the code yourself?

Maybe I'm too far gone down the AI rabbit hole, but that seems a really strange take to have. If you replaced 'back and forth with the AI' with 'pair programming' or 'brainstorming' this phrase would be really strange, after all these are all techniques to sharpen your ideas. Even 'rubber ducking' is widely accepted as an effective way to go through a problem, and you can definitely use AI as a rubber duck.

For me the idea of chatting with the AI about a problem/solution is just another tool to help us work. It's not the best solution because it has a lot of downsides you should be aware while using it, but that is true for any technique including 'writing the code yourself'.

Re: Using AI to write better code more slowly

#363
post #59

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.

Yet, so many internet users seem to only understand "hand crafted" vs "vibe coded" as if there wasn't tons of middle grounds and different uses.

Re: Using AI to write better code more slowly

#364

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.

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.

Re: Using AI to write better code more slowly

#366

The bottleneck moved. It used to be writing code. Now it's knowing what to ask for, in what order, and how to validate what comes back. That's a fundamentally different skill than coding.

Only if your job was to write code alone, which isn't what most people do. Most of my job for the past 10 years was explaining to people what had to be done, how and then verifying they did it.

Any senior/staff engineer was already doing this, if they weren't they were on the wrong job or had the wrong title.

Re: Using AI to write better code more slowly

#367
post #358

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?

Yes, but still lucrative so here we are.

Re: Using AI to write better code more slowly

#368

Earlier quoted context omitted.

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.

Your team members can be held "accountable" of the code they write: they can explain it, defend it in a PR, take ownership of it.

Your LLM has forgotten whatever shit it wrote when you opened a new tab, and that responsibility is now on you. And it wrote absolute dog shit

Re: Using AI to write better code more slowly

#369

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’ve found that it’s a lot like discovering a feature instead of designing it all up front. Like chiseling marble.

I’ve found it useful to write out a list of feedback / issues and have a bunch of sub agents work on them in worktrees with a loop bringing them all back together. That way it can work for a few hours while I just can review a bulk at a time.

Re: Using AI to write better code more slowly

#370
post #32

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?

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.

So exactly like playing Civ or some other building game. You constantly jump around between your various units and correct what they are doing.

I do wonder how much of how people approach coding is shaped by the games they played when younger.

Post reply on HN