Live data from Hacker News

Don't call yourself an artisanal programmer

purplesyringa.moe

41–50 of 72 posts

Re: Don't call yourself an artisanal programmer

#41

Earlier quoted context omitted.

I've gone back over most of my contributions to open source using LLMs and honestly, even though it was my best work at the time, there are big gaps that they find right away. The myth that we've been shipping perfect code for years, but you can't trust LLMs, is just subjective blindness. People can't see the issues that they can't see, definitionally. You can absolutely use the exact techniques we used to use in "th…

Likewise, I've found many bugs using LLMs in the small software libraries I hand wrote and considered complete and correct - even though it was my sole focus at the time and I thought I had perfected it

I have had the same experience.

I’m still in the process of revisiting and refining the many hand-coded dependencies that I’ve created, over the years.

Most of the issues found, were corner cases, that would likely never be encountered, but they are issues, nonetheless.

Re: Don't call yourself an artisanal programmer

#42

Earlier quoted context omitted.

I've gone back over most of my contributions to open source using LLMs and honestly, even though it was my best work at the time, there are big gaps that they find right away. The myth that we've been shipping perfect code for years, but you can't trust LLMs, is just subjective blindness. People can't see the issues that they can't see, definitionally. You can absolutely use the exact techniques we used to use in "th…

We definitely haven't been writing completely correct code in the past. But even so, the code LLMs write has more issues than the code humans write.

This seems to be changing, in the year of heavy LLM use that I’ve done.

When I started, I had to review every line, and frequently found bugs, but lately, I’ve been impressed with the quality of the code. I don’t think that I’ve had to make any code-level adjustments, in a while.

Re: Don't call yourself an artisanal programmer

#43

Engineering is about creating something that serves a purpose, while operating within a set of constraints. Part of that is realizing that "100% correct/reliable in all circumstances" is an unrealistic goal, since implementation time and cost is one of those constraints. A good engineer will acknowledge this tradeoff between robustness and cost and behave accordingly. For example, if you're working on safety critical…

> LLMs just change certain parts of the equation. For example, code writing is far less of a bottleneck than before, so "we can just try with a throwaway impl and see if this works" is suddenly economically viable.

The economic costs of LLM use have been abstracted away, but they're still very much there. The ecological cost of building and running data centres will be a pretty heavy economic cost somewhere in the future. It's not obvious, but it still exists.

(I'm not dumping on LLMs — otherwise I wouldn't even be here. I'm not a glutton for punishment. I know well that HN users excited about LLM use now vocally outweigh, and are pretty intolerant of people who are more on the cautious/negative end of the spectrum. I don't want that trouble in my life).

Re: Don't call yourself an artisanal programmer

#47
Thank you for sharing this. This is a concern many of us had — I sure did — but I always felt like an unfortunate bystander with little control over the situation. This posts shows how we can at least start talking about this in a constructive manner.

Re: Don't call yourself an artisanal programmer

#48

But can they compete with my shade grown software? It does result in a 40% markup, but there's no putting a price on being raised in a loving environment, is there.

I carefully bottle feed every function by hand, and let it out to pasture at least twice a day.

Re: Don't call yourself an artisanal programmer

#49

Engineering is about creating something that serves a purpose, while operating within a set of constraints. Part of that is realizing that "100% correct/reliable in all circumstances" is an unrealistic goal, since implementation time and cost is one of those constraints. A good engineer will acknowledge this tradeoff between robustness and cost and behave accordingly. For example, if you're working on safety critical…

> Engineering is about creating something that serves a purpose, while operating within a set of constraints.

A builder fits that description. Even a cook fits that description.

Engineering is something else. It's hard to describe what it is, probably why it has its own word. Dictionaries probably offer a definition.

> A good engineer will acknowledge this tradeoff between robustness and cost and behave accordingly.

An engineer will never intentionally produce something shoddy for cost reasons. They will simply refuse to do it. What you are getting at it some tasks don't require an engineer at all. You want to build a bridge to span a kilometer of water? You need an engineer. You need to occasionally cross a ditch? Anyone could lay plank across. No engineer required. The author makes this point too, with software craftsmen.

Post reply on HN