Live data from Hacker News

Using AI to write better code more slowly

nolanlawson.com

201–210 of 511 posts

Re: Using AI to write better code more slowly

#201

“A lot of people seem convinced that the point of AI coding is to write low-quality code as fast as possible.” A lot of people think a lot of things, but I don’t think the majority of people think the point of using LLMs is so they can produce low-quality code. Do they produce low-quality code sometimes or often? Of course. But they also produce high-quality code very often. And sometimes they just a “fine” job. One…

> We can debate as to how successful we’ve been toward the two goals above

No not really. These are separate questions from what the article posits. The argument is about how do we use these tools, our approach as developers, and if the results are going to be as rosy as advertised.

Re: Using AI to write better code more slowly

#202

Earlier quoted context omitted.

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.

Same. I've been creating "research" documents where I let it do a freeform survey of possible solutions/have sketch out it's own solution. I'll then sketch out a plan based on what I think is good or what I think it missed, and then I'll have it interrogate me for a final PRD document. It then implements the feature in reviewable chunks, and I'll give it feedback or tweak the PRD doc as needed. Finally feel like I ha…

Same here. Step 1 is usually a research doc where I simply describe the task and tell it to research the relevant parts of the codebase. This gets refined to a high-level plan, which gets distilled to a detailed step-by-step implementation plan.

When it comes to the actual implementation I prefer to work through it in small steps, where the AI explains to me exactly what it's about to do and why (and I approve) along the way. This enables me to catch it if it's about to do something I disagree with beforehand. And reduces the time I need to spend reviewing in the end.

Re: Using AI to write better code more slowly

#203

Earlier quoted context omitted.

> 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 basica…

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

Re: Using AI to write better code more slowly

#205
post #182
post #128

Earlier quoted context omitted.

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!

[flagged]

Re: Using AI to write better code more slowly

#206

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.

Overengineering is totally a thing, yes. If you want to make a proof of concept or you have no customers, that's fine, ship it.

There's such a thing as under engineering, and if you find yourself changing "all the layers" for a feature, your codebase is poorly designed.

Re: Using AI to write better code more slowly

#209
Very much agreed. Something specific that has helped me a lot (beyond just automatic formatting, linting and testing) was putting a hard fail on any file with more than 1500 lines or so, with an allowlist for specific files with specific reasons for their length. I realized the agents were squirreling away code without wanting to do any sort of refactor. Every time one of these rat's nests has turned up, the codebase has been much improved with a small refactor, to the point it doesn't feel like such a pile of slop anymore.

Re: Using AI to write better code more slowly

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

That might be true on general-population social media, but the opposite is the case in niche groups, and in particular, this very industry we're in - software - was largely built on terminally online hobbyists.
Post reply on HN