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

431–440 of 511 posts

Re: Using AI to write better code more slowly

#431

Post by sailfast »

tikhonj wrote: post #329
zendist wrote: post #317

Earlier quoted context omitted.

> models write much better code than humans can What? I think this is either over exaggerating model capabilities or you haven't seen much good code from humans? My experience is that my colleagues which have bought into model-first development have regressed in quality of the PRs they send out. LLMs are not better coders, in my experience. They lack holistic understanding and often need course correction for that re…

Over my time in the industry I've become increasingly convinced most people haven't seen what good human programmers are like. Otherwise we wouldn't have the popularity of things like Scrum, Clean Code (the book, not the concept), etc. I was lucky enough to see some good teams when I was a student (both at Berkeley itself and by interning at Jane Street), and it totally changed my intuition for what good programming…

I think you can get to "easier" if you have the a) budget to hire the people that are good enough and b) the time and discipline to create the abstractions so it gets easier over time.

Most shops will not have that kind of time and money, so the default will be "harder". Also, to be fair, most shops will not be led by individuals that understand why ensuring things get easier / faster is important in the short term, so that also complicates things a bit.

Re: Using AI to write better code more slowly

#432

Post by zahlman »

tikhonj wrote: post #329
zendist wrote: post #317

Earlier quoted context omitted.

> models write much better code than humans can What? I think this is either over exaggerating model capabilities or you haven't seen much good code from humans? My experience is that my colleagues which have bought into model-first development have regressed in quality of the PRs they send out. LLMs are not better coders, in my experience. They lack holistic understanding and often need course correction for that re…

Over my time in the industry I've become increasingly convinced most people haven't seen what good human programmers are like. Otherwise we wouldn't have the popularity of things like Scrum, Clean Code (the book, not the concept), etc. I was lucky enough to see some good teams when I was a student (both at Berkeley itself and by interning at Jane Street), and it totally changed my intuition for what good programming…

> Clean Code (the book, not the concept), etc.

Thank you for drawing the distinction. I've noticed that while ~80% of Uncle Bob's ideas are good, he doesn't seem to have been very good at implementing them, and he often does so in ways that contradict other principles. Much the same with Fowler and other names from that era/community.

> But the surprising thing was how "obvious" the dynamic was in both cases, even though the two cases are exact opposites of each other! If you ask one group or the other they'd just tell you that, well, that's simply how programming works. Of course things get (easier|harder) over time. That's built into people's fundamental understanding of what programming is and how to do it. And that's exactly what I mean by incommensurable paradigms.

Although I mostly see it get harder over time, it certainly feels like it's supposed to get easier.

Re: Using AI to write better code more slowly

#433

Post by habinero »

bottlepalm wrote: post #421
skydhash wrote: post #187

Earlier quoted context omitted.

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…

Lets see, front end presentation, front end service, frontend api, backend to front end (BFF) api/routing, BFF logic, BFF api, backend routing, backend logic, backend database, worker routing, worker logic, worker storage. And then the each of the service layers can be broken into layers themselves depending on the complexity of the business logic can be broken into layers as well. So yea a change in a worker can pot…

In a worker? ...How? I seriously want to know.

Re: Using AI to write better code more slowly

#434

Post by zahlman »

etothet wrote: post #125

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

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

Hence "seem". Of course people are not in the habit of describing their process output as "low quality", let alone supposing that that's the point. But when people clearly prioritize speed, and when the result is low quality, it's easy to get the impression of intent.

Re: Using AI to write better code more slowly

#435

Post by halis »

This was a really good article. I typically code with Sonnet or Opus, but I'm going to start using Codex to review local changes before I do a PR. It does a great job at identifying issues and then patching them. I just feel weird having Anthropic review it's own code so this will be my workflow for now. For complex features I also use Opus to cook up an implementation plan ahead of time that a lot of the time I have Sonnet implement. I may also have Codex start devil's advocating the plan before I start too, just to catch issues earlier.

Re: Using AI to write better code more slowly

#436

Post by exe34 »

locknitpicker wrote: post #291
exe34 wrote: post #177

Earlier quoted context omitted.

yeah that's how a simple algorithm that would fit on a napkin gets broken up into a soup of ravioli that I have no hope to understand. I often end up refactoring it into a simple function in a branch so I can figure out wtf is going on.

> yeah that's how a simple algorithm that would fit on a napkin gets broken up into a soup of ravioli that I have no hope to understand. No, not really. You get spaghetti code by being unable to refactor your code to follow inconsistent level of detail across calls. That's the textbook definition. Once you start to follow basic code quality and software engineering principles, you'll notice right away that your code…

My code is fine, thanks. It's other people's code that I have a problem reading.

Re: Using AI to write better code more slowly

#437

Post by rootnod3 »

forlorn_mammoth wrote: post #370
efitz wrote: post #32

Earlier quoted context omitted.

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.

I don't think that analogy holds. Within Civ, you are in one game. Playing 4 instances of Civ, or better: 4 instances of 4 different games is more likely the comparison.

Re: Using AI to write better code more slowly

#438

Post by zahlman »

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 feel like, if an LLM can one-shot a say 500 LOC project from a single-line prompt, and doesn't require the user to make any choices, and the result is actually acceptable, then 499 of those LOC are definitionally "boilerplate". They have been demonstrated, by this process, to have no more design-information content than the prompt, except perhaps a few constants where effectively random / statistically likely values were good enough.

> In a mature web ecosystem, boilerplate is minimal.

I don't think I even have words for my level of disagreement here.

> I worry now that we've given this task to LLMs, less development effort will go into startproject-esqe CLIs and good opinionated defaults.

I certainly hope not. I feel like an LLM-powered project could very much benefit from having those kinds of pieces to work with.

Re: Using AI to write better code more slowly

#440

Post by bigfishrunning »

halfcat wrote: post #111
ianm218 wrote: post #53

Earlier quoted context omitted.

There is things you really can't do by yourself. I've been working on porting some large codebases to Rust lately to experiment with fixing memory safety bugs. There is just no way you can write 100k LOC in a week of production code with tons of tests etc. Even "10X" engineers just can't type that fast.

How would one even know if the port of 100k LOC was successful? Are there language-agnostic tests (CLI STDIN/STDOUT) or similar involved?

Vibes, man!
Post reply on HN