Don’t call yourself an artisanal programmer

别再自称“手工匠人式程序员”了

September 13, 2026 2026年9月13日

So I’ve been meaning to write about something, but got sucked into this rabbit hole, and now I’m kinda scared if I’ve been a subject of propaganda that worked on me. 我一直想写点什么，但却陷入了一个思维怪圈。现在我有点害怕，担心自己是否已经成了某种宣传攻势的受害者。

A common theme in software development AI discourse is that there are “serious” engineers who value the end result the most, and “artisanal” coders who value the experience of coding over the final product. This dichotomy doesn’t correctly describe me and likely many others, but let’s play along with it for now. 在软件开发与人工智能的讨论中，一个常见的主题是：存在着最看重最终结果的“严肃”工程师，以及比起最终产品更看重编码体验的“手工匠人式”程序员。这种二分法并不能准确地描述我，也可能无法描述许多其他人，但我们姑且先顺着这个逻辑讨论下去。

I want my programs to be reliable. Patience and care are two important ingredients for this. When designing programs from ground up and taking my time, I just know that they’re correct, and that any mistake is due to a typo. Unit tests, LLM reviews, and provers can guarantee the code is 99% right, but not that it’s 100% right: optimal, maintainable, readable, and that it doesn’t rely or break due to undocumented incompliant behaviors. I want that 100%. I can only begin to achieve this with deep connection to code, so I refuse to use LLMs, since they isolate me from the low-level details that matter and cannot guarantee correctness by construction. 我希望我的程序是可靠的。耐心和细心是实现这一点的两个重要因素。当从零开始设计程序并花时间打磨时，我确信它们是正确的，任何错误都仅仅是拼写失误。单元测试、大模型（LLM）审查和形式化验证工具可以将代码的正确率保证在99%，但无法保证100%——即达到最优、可维护、可读，且不会因为未记录的非合规行为而产生依赖或崩溃。我追求的是那100%。只有与代码建立深层联系，我才能开始实现这一目标，所以我拒绝使用大模型，因为它们将我与关键的底层细节隔离开来，且无法从构建层面保证正确性。

Contrast

对比

Which is where the dichotomy falls apart in my eyes. By the book, I’m an artisanal coder, since I don’t use LLMs. But if the industry calls the opposite of “artisanal programmer” a “software engineer”, isn’t there a subtext that I’m not an engineer? This may seem like a minor point, but it matters on a subconcious level. Care, attention, and precision are the defining characteristic of engineering – so why is this term appropriated by people who are becoming closer and closer to managers? 这正是这种二分法在我眼中崩塌的地方。按照定义，我不使用大模型，所以我属于“手工匠人式程序员”。但如果行业将“手工匠人式程序员”的对立面称为“软件工程师”，这是否暗示了我不是一名工程师？这看起来可能是一个小问题，但在潜意识层面却很重要。细心、专注和精确是工程学的定义性特征——那么，为什么这个术语会被那些越来越像管理者的人所挪用呢？

Back in my day (ahem), developers hated management that wouldn’t allocate time to dealing with tech debt, and the “move fast and break things” attitude was considered childish. Nowadays, common knowledge among developers says that vibecoding (I’m using the term loosely) is the norm, and wasting time on reliability work is unserious. Who is in the right? 想当年（咳咳），开发者们痛恨那些不愿分配时间处理技术债务的管理层，“快速行动并打破常规”的态度曾被认为是幼稚的。如今，开发者间的共识似乎是“氛围编程”（vibecoding，我在此泛指该术语）才是常态，而在可靠性工作上浪费时间是不务正业。究竟谁是对的？

Redefining terms

重新定义术语

To me the answer seems obvious: you can’t earn the title of Software Engineer by building stuff blindly. An engineer should know what they’re doing. But let’s ask someone more knowledgeable about this topic. 对我来说，答案显而易见：你不能通过盲目地构建东西来获得“软件工程师”的头衔。工程师应该清楚自己在做什么。但让我们问问在这个领域更有见地的人。

In 2021, Hillel Wayne ran the crossover project, where he interviewed multiple people moving to software engineering from other engineering fields. His goal was to answer the question: do people with actual experience in both fields consider our job engineering? The answer was “yes”, but here’s the part that interests me more: 2021年，Hillel Wayne发起了“跨界项目”（crossover project），采访了多位从其他工程领域转行到软件工程的人。他的目标是回答这个问题：那些在两个领域都有实际经验的人，是否认为我们的工作是工程学？答案是“是的”，但下面这段话更让我感兴趣：

That said, many of the crossovers also added an additional qualification: software engineering is real engineering, but a lot of people who write software aren’t doing software engineering. This is not a problem with them, rather a problem with our field: we don’t have a rich enough vocabulary to talk about what these developers do. Not everybody who works with electricity is going to be an electrical engineer; many will be electricians. And this is okay. […] But we use things like “programmer”, “software engineer”, and “software developer” interchangeably. What is the difference between a software engineer and a software developer? Some people propose the word “software craftsman”. “话虽如此，许多跨界者也补充了一个限定条件：软件工程确实是工程学，但许多写软件的人并没有在进行软件工程。这不是他们的问题，而是我们领域的问题：我们缺乏足够丰富的词汇来描述这些开发者所做的事情。并不是每个与电打交道的人都是电气工程师；许多人是电工。这没问题。[……] 但我们却把‘程序员’、‘软件工程师’和‘软件开发者’混为一谈。软件工程师和软件开发者有什么区别？有些人提出了‘软件工匠’这个词。”

What jumps out to me is that the titles Wayne uses are completely opposite to the ones popular nowadays. He calls the people who care, and who today we call artisanal coders, “engineers”, and on the opposite side, he calls those who we label vibecoders “craftsmen”. At least to me, this is more intuitive naming! There is arguably more art in prompt engineering than writing code by hand. 让我感到震惊的是，Wayne使用的头衔与当今流行的完全相反。他将那些细心的人（即我们今天所说的“手工匠人式程序员”）称为“工程师”，而将我们贴上“氛围编程者”标签的人称为“工匠”。至少对我来说，这种命名更直观！可以说，提示词工程（prompt engineering）中蕴含的艺术成分，比手写代码要多得多。

“Artisanal” made sense as the antonym of “vibecoded” historically, but claiming this term freed up “engineer” and effectively gave up the debate on whether vibecoding is a form of engineering. Vibecoding became the obvious default, and artisanal coding the outlier. How did we get here? 从历史上看，“手工匠人”作为“氛围编程”的反义词是有道理的，但认领这个术语实际上让“工程师”这个词被闲置了，并有效地放弃了关于“氛围编程是否属于工程学”的辩论。氛围编程成了显而易见的默认选项，而手工编码成了异类。我们是怎么走到这一步的？

Talking points

谈话要点

If you look for this change in “common sense”, you’ll find it everywhere. The “only” “correct” approach changed radically. Why did we use to consider PVS-Studio posts promotional material, but now we worship automated review tools? How did we jump from strong type systems to free-form specifications so quickly? 如果你去观察这种“常识”的转变，你会发现它无处不在。所谓的“唯一”“正确”的方法发生了根本性的改变。为什么我们过去认为PVS-Studio的文章是宣传材料，而现在却对自动化审查工具顶礼膜拜？我们是如何如此迅速地从强类型系统转向自由格式规范的？

Nothing like this has happened before in the programming community. Sure, there were arguments about which type system or web framework is better, and the common opinion changed over time, but this is different. A devoted believer in strong type systems would consider a PHP developer an idiot, but still a developer. Even a caricature Rust zealot was still a Rust programmer. And the arguments were based on whether one option is more reliable, easier to use or learn than the other, not whether you should worry about reliability or misuse at all. 编程社区以前从未发生过这样的事。当然，过去也有关于哪种类型系统或Web框架更好的争论，大众观点也会随时间改变，但这完全不同。强类型系统的忠实信徒可能会认为PHP开发者是白痴，但仍会承认他们是开发者。即使是刻板印象中的Rust狂热分子，也仍是Rust程序员。当时的争论基于哪种方案更可靠、更易用或更易学，而不是关于你是否应该关心可靠性或滥用问题。

This is different – vibecoding is portrayed not as a better solution, but as the only sane solution, spitting in the face of past experience. Someone who doesn’t use LLMs is not a software engineer, they’re an artisanal coder. It’s an attack on an identity. 这次不同了——氛围编程被描绘的不是一种更好的解决方案，而是唯一理性的解决方案，这简直是对过往经验的唾弃。不使用大模型的人不再是软件工程师，而是“手工匠人式程序员”。这是对身份认同的攻击。

History

历史

Redefining terms and portraying yourself as the sane side and others as beings not worthy of consideration is a new tactic in the software world. I’ve seen it before, though: it’s very much part of the fascist playbook. 重新定义术语，将自己描绘成理性的一方，而将他人描绘成不值一提的存在，这是软件世界中的一种新策略。但我以前见过这种手段：这很大程度上是法西斯主义剧本的一部分。

I remember the time when we were all joking “the antonym of vibecoder is software engineer”, and then like a month passed and suddenly everyone was comfortable calling themselves artisanal programmers and leaving “software engineer” to “responsible” AI users. The term propagated with the speed of memes, seemingly without any natural reason. 我还记得我们都开玩笑说“氛围编程者的反义词是软件工程师”，然后过了一个月，突然间每个人都心安理得地自称“手工匠人式程序员”，而把“软件工程师”留给了那些“负责任的”AI用户。这个术语像模因（meme）一样迅速传播，似乎没有任何自然的理由。

I don’t believe this is a psyop, but I do think we should be more mindful about what we call ourselves, because words have power. Real composers call themselves composers, not artisan composers; AI writers have to call themselves AI writers; but the term “programmer” has not been debated, and this has real-world consequences. 我不认为这是一场心理战，但我确实认为我们应该更加审慎地对待自己的称呼，因为语言是有力量的。真正的作曲家称自己为作曲家，而不是“手工匠人式作曲家”；AI写作者必须称自己为AI写作者；但“程序员”这个术语却从未被讨论过，而这会产生现实的影响。