LLM coding assistants didn't create a split between craft-lovers and make-it-go developers. They revealed one that was always there.
For craft-lovers, what's being bypassed isn't the output but the act itself. Marx called this separation from the act of production. But the alienation isn't coming from the LLM. It's coming from a market that penalizes whoever produces output more slowly.
LLM 코딩 어시스턴트는 소프트웨어 엔지니어들 사이의 分裂(분열)을 만든 게 아니다. 이미 있던 分裂(분열)을 드러낸 것이다.
匠人(장인) 氣質(기질)의 소프트웨어 엔지니어들이 느끼는 疎外(소외)의 源泉(원천)은 LLM이 아니다. 그들의 產出物(산출물)을 더 느리게 만드는 쪽에 不利益(불이익)을 주는 市場(시장)이다. Marx의 勞動(노동) 疎外論(소외론)으로 이 問題(문제)를 읽어보는 새 글을 썼다.
LLMコーディングアシスタントはソフトウェアエンジニアたちの亀裂を作ったのではない。すでにあった亀裂を露わにしただけだ。
匠人気質のソフトウェアエンジニアたちが感じる疎外の源泉はLLMではなく、産出物を遅く出す側に不利益を与える市場にある。Marxの労働疎外論でこの問題を読む新しいエッセイを書いた。
I've just submitted my post to Lobsters and Hacker News:
@hongminhee
The bio-mechanics of making a cognitive idea physical (know how-to make ) is directly connected and a feedback loop to the cognitive idea (know what-to).
How would anyone know what-to make without the know how-to feedback loop?
Ideas and imagination are infinite!
It is still the case that most of the work goes in to debugging and maintenance.
Code that has been well designed and well thought out will be easier to understand and to modify.
Putting out 'just good enough' slop means that you don't think the code will be running for very long.
@benh Poor code is a separate issue that existed even before LLMs.
This is a damn good article, and really makes me think about where I fall on the spectrum.
I didn't have to think very hard, I side firmly with Lawson.
I firmly believe that code is a craft, and I take pride in the time spent writing the code, not just in the product itself.
I mourn the impending loss of that kind of counter-culture approach to programming. Which is ironic because I don't think it's even the mainstream way of looking at coding... most devs I know would side with Orchard. Coding is a means to an end.
I too consider coding, generally, a means to an end.
However, in software development, isn't often the real problem to find out *what precisely* is the end?
"Bugs" can result from perfectly coded software if you haven't fully considered that what you really, *really* want is zig a zig ah.
@hongminhee so, I guess this is true, but maybe also the craft changes?
I am old enough to remember when it was common to embed blocks of assembly language in your C code to optimize particular functions or loops. As high level languages grew, that familiarity with hardware architecture has mostly disappeared, but we've developed other skills instead.
When I read @jesse or @simon 's posts about exploring collaboration with LLMs, I see curiosity, creativity and joy in the craft.
@evan Totally agree, and I think that's actually the point the essay is trying to make. The split isn't “LLM users vs. craft lovers” but something more like “people with room to choose how they use the tools vs. people who don't have that room.”
@mitchellh is a good example. He's clearly using LLMs as a craftsperson. So am I, I think. But both of us are in situations where we're not being measured against a colleague's output every quarter. The workplace dynamic is what compresses all of that curiosity and exploration into pure throughput.
The craft probably does survive, just not evenly distributed.
@jesse @evan @hongminhee @simon I feel so torn. LLM code tools are fun, and I probably enjoy them as much as anyone. But.
I’m ~10 years into this job, and for most of them, everybody told me that the details matter, that understanding how it worked was important.
Getting better at my job has often been synonymous with learning to pay better attention, learning how to get a handle on complexity, learning how to learn. These things generally feel at odds with use of LLMs, to me.
@jesse @evan @hongminhee @simon Many people I respect now use LLMs, people on this thread included. I use them too, but like the post author, I still get to decide when, and I try to choose carefully where to draw that line. If it’s important, or I’m learning something, I do it myself.
The day my employer tells me I’m not using enough AI, I’m not sure I’ll know what my job is anymore. I used to pride myself on how good I was at training and mentoring junior devs, but nowadays, what juniors? 🫠
@hongminhee Fantastic article. 👏 👏
I think there's one possible ray of light for the "code as craft" people - at least a subset of them. To me the craft'ers can enjoy coding for various reasons - the demo-scene folks, the "get it into the smallest amount of code" folks, the aesthetic folks.
But another camp is the "make it easy to understand and extend" folks - and that's pretty much where I fall. People like me, who like arranging things neatly, have had a great advantage for the last few decades, because tidy code is good for industry. There's a reason @mfowler 's Refactoring book is such a big seller.
What I'd argue we don't know for sure yet, is whether readable code as a valuable thing for the industry, is dead. The LLM extremists would probably say it is. But that only works if the only form of validation of code is going to be external (testing & observability, basically). I argue that if humans will still be required to "review" (whatever that ends up meaning) at least some code, then readable code is going to be advantageous.
Even if LLMs can produce readable code we still need human judgment, but for me judgment skills will come from doing, and not just reviewing. In other words, there'll still be an economic case for "developing by hand".
If I'm wrong, and external validation does become sufficient for judging code, then all bets are off. But in that situation I don't think the LLMs will end up writing code as we know it anyway - why would they? They will write whatever uses the least tokens and gets to a valid result most cheaply. Which could be in assembler.
hot metal oxide
洪 民憙 (Hong Minhee) 
julian
gabboman the wafrn dev
Ken Milmore
Dawn Ahukanna
Ben Hammond
Mateusz 🏳️🌈
gábor ugray
Tamme Schichler
Sibrosan
Evan Prodromou
Jesse Vincent
Tom Armstrong
Mike Roberts
Lars