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

181–190 of 511 posts

Re: Using AI to write better code more slowly

#181

Post by democracy »

batshit_beaver wrote: post #168
democracy wrote: post #69

Earlier quoted context omitted.

You can be right but quite often it helps keeping focus on the forrest rather then getting lost in the trees - at least for me. Boilerplate steals a lot of attention, focus and can just be mentally exhausting.

Can someone explain these complaints about boilerplate to me? What are y’all doing where boilerplate is the majority of your code? Am I the only one mostly writing concise business logic where most lines are important in one way or another?

one man's boilerplate is another man's concise business logic )))

Re: Using AI to write better code more slowly

#182

Post by brabel »

rdedev wrote: post #128
aomix wrote: 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.

How would you approach this problem if you are let's say token constrained due to per month limits set in your company? What I've tried to do is make the bot write detailed spec documents, slowly building it over time as I explain the full problem. It works for the most part but it's you have some non standard requirement, the agent seems to skip over that part of the spec document when it starts to code. Or it would…

As the post says, after an agent implements the plan, have another agent review it. Make sure to mention it must ensure the plan is fully executed. It works wonders!

Re: Using AI to write better code more slowly

#183

Post by democracy »

busterarm wrote: post #85
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?

Company I'm familiar with that went all in on Codex ran out of tokens for a week and wouldn't increase their spend. I pretty significant number of their engineers flat out refused to work. Like publicly said so. "Increase our plan or I'm taking the week off."

so how did this go?

Re: Using AI to write better code more slowly

#184

Post by locknitpicker »

well_ackshually wrote: post #147
locknitpicker wrote: post #138

Earlier quoted context omitted.

> congratulations on your soon to be coming burnout. Multitasking does not mean burnout. It just means you are not wasting time while idling. Multitasking was not invented for AI coding assistants. What do you think feature branches are used for?

The constant context changes, mental overload, inability to focus on one thing and do it well is exactly what every software developer has been fighting against for the past thirty years because it leads to shit quality and burns you out. You're automating the burnout. Idling is a necessity, not an illness. Your feature branch is to put things aside and send them to CI, or wait and think on them. Not to have four of…

> The constant context changes, (...)

After you put together a plan, today's models can take well over a minute to execute it. Also, your work shifts to code review and executing acceptance tests, followed by either tweaking your current change or moving on to the next change.

This is really not about context changes. This is about not having to switch contexts because your focus stays on architecture+review instead of having to do deep dives to type code around.

> Your feature branch is to put things aside and send them to CI, or wait and think on them.

No, not really. Feature branches, as well as most types of branches, is to set aside work fronts that are in progress and run in parallel.

Re: Using AI to write better code more slowly

#185

Post by theK »

nullsanity wrote: post #77
qsera wrote: post #65

Earlier quoted context omitted.

>I argue about design and architecture all day with a robot. You will outgrow it at some point.

Its like that phase people go through where they argue with morons on reddit, and then one day grow up and realize that most of these people are unemployed/underemployed terminally online nobodies aren't ever going to learn anything, and even if they did it wouldn't impact the world since they were just some below average hobbyist anyway and aren't in charge of anything more important than a box of paperclips.

Mostly with you, though in recent years I have wondered whether those people are part of what caused the latest boom of political populism. If there is no one there to debate the problematic ideas, problematic ideas will become the rhetoric after all.

Re: Using AI to write better code more slowly

#186

Post by bottlepalm »

Animats wrote: post #176
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…

How much are you spending a day for the tokens to do that? Ingest big project, comment on it gets expensive. I'm not sure how expensive.

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

Re: Using AI to write better code more slowly

#187

Post by skydhash »

bottlepalm wrote: post #160
jcgrillo wrote: post #131

Earlier quoted context omitted.

It happens in poorly factored codebases. If you find it happening that's a sign you need to refactor. If you find it happening repeatedly in the same codebase that means you failed to refactor properly the first time.

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 (process and memory, io and other device, ipc,…)

If you’ve captured your problem’s domain and adopted a pragmatic architecture, you will rarely have to change across all layers. That’s costly and happens mostly due to business reasons.

Re: Using AI to write better code more slowly

#188

Post by theK »

dawnerd wrote: post #76
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…

When I use ai to code this is pretty close to my workflow too but I find it ends up taking at best just as long as if I were to write the code myself. If m some cases I’ve thrown away what the ai has done and just done it myself. I think that’s just a skill people need to learn - at a certain point you have to cut your losses. I’ve seen some coworkers argue back and forth with an llm trying to get it to do something.…

I've stumbled upon that too! Funnily I see it having two forms:

1. Some bad idea gets embedded into the context that you just can't argue away

2. Some important idea gets lost in compression and the ai wheres off into funland without recourse.

In both cases if is often better to start over or just do it yourself. I sometimes find myself asking for a summary, editing it and then using the edited one to seed a new session.

Edit: s/Finland/funland/

Re: Using AI to write better code more slowly

#189

Post by vcdk »

rootnod3 wrote: post #12
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…

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?

Whenever Anthropic is down, I switch to my other alternative AI provider. If that is also unavailable, or no more tokens left, then I can switch to my local AI. Not the same in terms of quality and speed, but good enough for an experienced engineer to still be more productive than falling back to doing it by hand. For my principal activity I do not want to be dependent on a sole provider. Besides that, I expect that the pending token price increases are going to hurt a lot of people/companies.

Re: Using AI to write better code more slowly

#190

Post by well_ackshually »

locknitpicker wrote: post #184
well_ackshually wrote: post #147

Earlier quoted context omitted.

The constant context changes, mental overload, inability to focus on one thing and do it well is exactly what every software developer has been fighting against for the past thirty years because it leads to shit quality and burns you out. You're automating the burnout. Idling is a necessity, not an illness. Your feature branch is to put things aside and send them to CI, or wait and think on them. Not to have four of…

> The constant context changes, (...) After you put together a plan, today's models can take well over a minute to execute it. Also, your work shifts to code review and executing acceptance tests, followed by either tweaking your current change or moving on to the next change. This is really not about context changes. This is about not having to switch contexts because your focus stays on architecture+review instead…

>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 basically the prompt you wrote or the nth SELECT * FROM table CRUD piece of crap), or you're context switching and it's fucking you over. The context isn't about remembering how you write if err != nil, it's the expected behaviour of what you're working on.

You're not getting a promotion from doing this, you're getting burnout.

> Feature branches, as well as most types of branches, is to set aside work fronts that are in progress and run in parallel

They're not running in parallel, unless you use work trees. They were put to the side, because you can't continue or finish the work they're about. Even just three branches in parallel in a modestly active repo that happen to be long lived drift enough that just keeping them up to date with develop makes it a waste of time.

Focus on one or two things, and do them well.

That, or get checked for ADHD.

Post reply on HN