每当我说我不喜欢调试，并且我的编程习惯都围绕着避免调试而制定时，总会有人反驳：“你肯定没用过好的调试器。”
总结一下我的观点：我希望我的软件具有反脆弱性（感谢纳西姆·塔勒布提出这个概念）。代码库维护的时间越长，修复 bug 就应该越容易。
每次对代码进行修改都可能造成压力。如果不采取任何措施，代码质量会逐渐下降，更难维护，也更容易出现错误。幸运的是，这种情况是可以避免的。
这不自然。对于大多数缺乏深厚专业知识的开发者来说，随着代码库的增长，修复 bug 会变得越来越困难：你需要在层层代码中追踪症状，寻找那些在调试器中消失的“海森堡式 bug”，或者修复一个 bug 后又会引入另一个。代码越多，情况就越糟糕。这样的代码非常脆弱。添加新功能可能会破坏原有的、看似无关的部分。
在我看来，无法编写反脆弱代码解释了编程中极端的幂律分布：我们每天依赖的大部分代码都是由掌握了反脆弱性的程序员中的一小部分编写的。
如何逆转这种情况？如何确保你花在代码上的时间越长，bug 就越浅？
有一些众所周知的技术，添加大量的测试和检查肯定有帮助。你可以编写不依赖测试或调试时检查的反脆弱代码……但你需要功能上等效的替代方案。
那些影响深远的条条框框（“你必须使用X语言、Y工具、Z方法”）通常是盲目照搬的无稽之谈。照搬Linus Torvalds的工具或粗俗的语言风格并不能保证成功。但反脆弱性并非一条条条框框，而是一种理想的结果。
防御性编程本身并无争议——然而，它在 20 世纪 80 年代并不常见，而且至今仍不是许多人的默认选择。
当然，采取全面的防御策略并非总是适用或值得付出代价。
例如，如果我用即兴创作的方式快速开发一个网页应用，但 JavaScript 代码多到我懒得去读，我就会直接在浏览器的调试器里运行它。一切正常。我又不是用这段代码来控制心脏起搏器，我也不指望圣诞节半夜被人叫醒来修它。
如果你的程序只有 500 行代码，而且你一年只运行 20 次，那么追求反脆弱性就不值得了。
大型语言模型可以生成防御性代码，但如果你从未自己编写过防御性代码，并且主要在人工智能的辅助下学习编程，那么你的软件可能仍然会很脆弱。
你可以快速添加代码，但添加的代码越多，问题也就越大。
这就是问题的关键所在。编写代码从来都不是难点——我12岁就能写代码了，如今无数12岁的孩子也能编写简单的游戏和应用程序。同样，12岁的孩子也能用锤子、钉子和木头搭建狗窝。完成80%的工作一直都很容易。
在不导致系统崩溃的情况下扩展复杂性——这才是难点。
原文： https://lemire.me/blog/2025/11/29/antifragile-programming-and-why-ai-wont-steal-your-job/