It's interesting how the words can be ambiguous like that. If I think of the distinction in the context of e.g. clothes, there's likely more engineering in fast fashion and more crafting in bespoke clothing. With food, more engineering in the food items you'd find at a gas station and more crafting at a restaurant.

>> “artisanal” coders who value the experience of coding over the final product

I don't see "artisanal" as that. It may be more that they value the details rather than the experience of coding. They value the details of the final product. Details that most people will not care about. The details that are present in bespoke clothing but missing in fast fashion, the details that are present in a good restaurant's food but missing from a gas station food item.

id consider that a craftsman tends to build without constraints. an enginner meets the constraints with a defined safety factor.

an engineer uses tools that represent the current state of the science, while a craftsman uses tools passed down as archaic art that require meticulous skill to use rather than repeatable math

Software is ephemeral.

Very little of it lasts for long. And if it does, it's legacy banking or some ossified terrible thing people are afraid to touch - not something revered.

Every piece of software today will be rewritten. By 2100 much of it will be dead and gone. Like punch cards that have rotted away.

[dead]

In food contexts when I see "artisinal" I usually just think of rich white people buying the same stuff in nicer packaging and typography for twice the price.

The actual artisans don't need to advertise themselves as artisans, they just sell shit.

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

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

Strong agree. I think the fundamental challenge of working in fields that increasingly become AI-enabled will be the ability to understand and direct large or intricate systems without prior knowledge/the advantage of having built the model as implemented. That’s already how it works in complex domains or large businesses.

It does require a different kind of ego/abilities than before. My (negative) framing of the whiplash effect is that it’s a reckoning of “process fetishism”/a bad kind of careerism in the tech hiring market (because for the labor market to work, candidates need to be evaluable and sortable by businesses, and many people build an identity/optimize for legibility around “best practices” or very particular “technologies” which might get them a job).

Ultimately, you need to know and learn/be responsible for stuff, and be able to help people with your labor, not be “a type of person” that isn’t effective at the task of helping. But at the same time knowing things and being able to take accountability/help people remains critical, especially because that’s what people will want to pay for even as “time spent typing it in” decreases.

Personally, I think it will be a good thing because software and “tech” will become a more strongly domain-driven/enabling medium for real-world or specialized things. IE it is the end to “software for its own sake” or “willingness to type it in and play with Jira/jenkins/frameworks” and the beginning of something that is more applicable or knowledge-building rather than “being the X for Y at Z”. Harder but more fun :)

A whole bunch of assumptions and beliefs passed off for truths.

LLMs have very little to do with engineering, unless you let a pair of dice decide how you build a house.

Cars are not built by AIs, they're built by extremely precise robots, over precise instructions.

I'd VERY much want a hand-made car over an LLM-made car, thank you.

Because I do want the precision, reliability and performance that an LLM-made car won't ever be able to guarantee.

You mean by vibecoding? Don't call that programming, for God's sake

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

it's organic right?

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 "the old days" to produce reliable code with LLMs generating most of it. The issue is, it's really not a lot less conceptual and intellectual effort than in "the old days", at root. You speed up the programming part, but the rest is still a hard slog, so nobody is out here doing really thorough testing in ways we used to dream of.

I won't lie, of course my code has bugs. The difference, as I see it, is the kinds of bugs that manifest, and how well they can be avoided.

There are two steps to writing the program: building a model in your head to map understanding to algorithms, and then implementing the algorithm in code (and of course this can get recursive if the algorithm relies on other high-level mechanisms, like data structures).

I have found that most of the time, the kind of bugs that unit tests find are typos, i.e. mistakes in the second step; but the errors that actually cost time to resolve are errors in understanding, i.e. the first step.

They can't be found with testing or verification because what it means for code to be correct depends on the specification, and the error is that the specification itself is incorrect. Asking an LLM to check this one specific part of the software is thus useless, and whole-program analysis is not cheap enough to employ at this point.

So what about avoidance? When I say hand-written code is 100% correct (or at least approaches that number), I mean that with experience, I learn more about which models tend to be correct, and thus avoid bugs of the latter kind by construction. Of course typos still exist, which is why I write unit tests, and I expect LLMs to be able to find them as well; but I believe the only way to avoid incorrect models is to learn stuff by doing, failing and failing again, figuring out nitty-gritty low-level details, until at some point you become an expert in that area and know what to use.

It may not be 100%, but human code is objectively more reliable and higher quality than any LLM generated slop code.

I also write 100% correct code, it does exactly what I wrote it to do (not compile).

she*

I think you might be interested in reading the post Are We Really Engineers (https://www.hillelwayne.com/post/are-we-really-engineers/), which in part covers the point about whether "engineer" is closer to a profession designator or a respectable title. It really surprised me when I read it first time!

Exactly, when the real question is "why are you using notepad++ instead of emacs, you philistine?"

> I would call myself an artisanal programmer. Software Engineers are (...) very condescending (...) They need the title of Engineer because deep down they are very insecure.

Jokes really do write themselves sometimes...

Sounds similar to Rust programmers

Yes, these are the only two options. That is definitely true.

It's of course impossible to have any nuance or middle ground here where you use LLMs to assist while you still focus on the engineering design decisions and the quality.