LLM 코딩 어시스턴트는 소프트웨어 엔지니어들 사이의 分裂(분열)을 만든 게 아니다. 이미 있던 分裂(분열)을 드러낸 것이다.

匠人(장인) 氣質(기질)의 소프트웨어 엔지니어들이 느끼는 疎外(소외)의 源泉(원천)은 LLM이 아니다. 그들의 產出物(산출물)을 더 느리게 만드는 쪽에 不利益(불이익)을 주는 市場(시장)이다. Marx의 勞動(노동) 疎外論(소외론)으로 이 問題(문제)를 읽어보는 새 글을 썼다.

〈왜 코딩을 사랑하는 사람들이 코딩에서 밀려나는가〉 (한글)

I've just submitted my post to Lobsters and Hacker News:

• Lobsters: https://lobste.rs/s/vxsjiv/why_craft_lovers_are_losing_their_craft
• Hacker News: https://news.ycombinator.com/item?id=47468389

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

@hongminhee Great article! Thanks for that

Fuck

@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!

@hongminhee

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.

I have one remark: In my experience, the speed metric in a corporate environment is often misaligned with what really makes the product itself valuable. It's small scale, but for example in my indie plugin business, the increasingly available genAI plugins don't seem to compete with mine at all.

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.

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