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

91–100 of 511 posts

Re: Using AI to write better code more slowly

#91

Post by halfcat »

afavour wrote: post #25
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?

I don’t think you’re quite getting what OP is describing. I work in a similar way… I am aware of all the code being written. If Claude had an outage I could write it myself. It would just take longer. You say “all that time” babysitting AIs but in my experience it isn’t that much time, if anything the back and forth at the planning stages is more productive than when I’m doing it by myself because I’m being asked que…

How do you stay aware of all code being written?

Maybe it’s just me, but I’ve never understood how one understands from reading code. Yes you can understand what that code does, but not why it was done that way instead of a different way. In the end I only understand it deeply if I end up writing it. Chatting through it is helpful to me, but having AI crank out code loses all of that context pretty quickly.

I’m not disagreeing. Just curious how you think about this, and if there are key parts of your process that help you stay contexted in.

Re: Using AI to write better code more slowly

#92

Post by bottlepalm »

DonHopkins wrote: post #67
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…

Low frequency defensive long drawn out back and forth bullet dodging vibe coding should be called "serpentine coding". The In-Laws (1979): Getting off the plane in Tijuara: https://www.youtube.com/watch?v=A2_w-QCWpS0

Heh it feels like that in a way, and the more complex the feature, the more endless the back and forth reviews can be - there seems to be always some feedback, so you need to decide when to be done with it and commit. You can easily get into review paralysis.

Re: Using AI to write better code more slowly

#93

Post by a_victorp »

themanmaran wrote: post #80

As I read this, I'm also working through a pretty dense feature that took a fair bit of iteration. The end result is actually significantly less code than it was about halfway through. And I was wondering if the AI actually helped me at all, since surely I could have written the code in the same time it took to iterate But! Because of AI I was able to rapidly hack out like 4 variants of this feature that I didn't lik…

This has been one the most significant improvements of using AI for me. Before I would have to really think through the plan of a new feature before committing to the implementation and would only catch incompatibilities with existing code after a good portion of the implementation was already written. Now I can ask AI for detailed implementation plans and find these nitty gritty detail problems in a few hours if not less

Re: Using AI to write better code more slowly

#94

Post by datadrivenangel »

Waterluvian wrote: post #73

I think my current conclusion is that AI makes more important than ever. I’m not exactly sure what is but I feel it. I think it’s quality and authenticity and craftsmanship. That difference between an expensive tool and a cheap one that you can’t easily describe but you just know it. Is there a word for this? I bet the Japanese or Germans have a word for this. I use AI a lot now. But I also do it in small steps. It i…

Quality as Pirsig would say in Zen and the Art of Motorcycle maintenance.

Re: Using AI to write better code more slowly

#95

Post by singingtoday »

zik wrote: post #38
justinlivi wrote: post #11

I find myself spending on average more time in LLM review/resolution loops than it would take for me to write the code by hand. Partially because once I'm in the flow I write very very quickly and the code pours out sometimes faster than I can write. But also because the LLM code on the first few tries is generally really really bad. What I find interesting though is that spending the time to personally review and di…

If your AI is writing bad code then you need to change your AI. No current high-end AI should be producing bad code.

The tool is important but then so it's the way you use it. I've seen small LLMs produce good code and frontier LLMs produce poor quality code. Depending on context..

Re: Using AI to write better code more slowly

#96

Post by ehnto »

foobarbecue wrote: post #52
vessenes wrote: post #24

One thing that's been interesting to me over the last few years is charting the edge of my coding laziness. As a coder, I'm lazy about boilerplate code -- I hate writing it, I hate maintaining it, etc. And so I design and architect (or used to) around that preference. Sometimes that's smart, sometimes that's not. But it was my preference, and I avoided something that was hard for me to do. When LLMs started being som…

The thing about boilerplate is that a good library or framework makes it optional, and / or automatically written. I'd much rather django-admin startproject, npm init, or meteor create and get deterministic output than prompt an LLM and get who knows what. In a mature web ecosystem, boilerplate is minimal. I worry now that we've given this task to LLMs, less development effort will go into startproject-esqe CLIs and…

I wonder this in general, what's the impetus for writing new frameworks and such? Are we already seeing a slow down in that space? HN front page certainly paints that picture.

You're better off plonking down an existing framework and getting all the structural boilerplate benefits the LLM can leverage.

LLMs are far better at frameworks they have a lot of training data for, if have been around for a while. They write more idiomatic, ecosystem friendly code. Does that still matter?

Re: Using AI to write better code more slowly

#98

Post by bottlepalm »

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…

I would never imagine this is where programming would be five years ago, but at the end of day having the AI write the code is easier, faster, and results in higher quality.

The mental model is still in my head, my brain is overloaded, but only from the amount of code reviews - like I said, I'm building v3 of a feature in the time it takes to build v1, but I am in a way doing 3x the code reviews going back and forth. That's the fall out of the iteration speed enabled by AI.

Between submitting PRs, getting feedback, iterating, re-submitting, repeat - there used to be breathing room. Now it's all compressed into an afternoon. Productivity is through the roof, but it can be draining.

Re: Using AI to write better code more slowly

#100

Post by bottlepalm »

skydhash wrote: post #44
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…

That sounds too much like three weeks of work saving you three hours of planning. In my experience, software engineering is a matter of knowledge. Understanding it and then coming up with a solution. The latter is a flash of insight that comes mostly from experience. Then you gather more information to flesh it out, or brainstorm it with your colleagues. What you're describing sounds more like a ritual of doing busy…

A lot of people say you need to go through at least three versions of something before it is mature - and v3 is not something you can design upfront. You need to see v1 both in code, and at runtime. Use it, get the feedback, and iterate. This is where AI tightens that loop immensely.

Lost you in the last paragraph - features are not "copy pasting because you already have all the building blocks" and "something may be twenty lines of code". Mid sized features often mean tearing up many layers of code across the stack to add in some sort of new capability. Tearing up existing code means there are all sorts of add-on considerations in addition to feature you are working on.

Post reply on HN