Alexandru Nedelcu 认为，AI 辅助编程的核心风险并不是某一个显而易见的错误，而是设计选择不断累积，最终使软件变得难以理解、修改和测试。他的警告与其说是针对模型本身，不如说是针对那些允许生成式代码取代人类判断，以及取代从纠正错误中积累起来的经验的组织。
这一论点首先涉及衡量问题。一个功能刚刚能够运行时，可维护性通常并不明显；架构薄弱所产生的影响可能要经过数月甚至数年才会显现。一个代码库表面上可能效率很高，但隐藏的依赖关系、不明确的不变量、重复的逻辑和脆弱的测试，会让每一次后续修改都变得更加昂贵。因此，Nedelcu 将可维护性视为一种长期属性，而不是一种可以依靠传统代码检查工具或即时测试结果来保证的质量。
这一区别十分重要，因为机器学习系统需要可衡量的反馈。如果现有奖励只反映代码今天能否运行，模型就可能改善短期行为，却无法学到由此产生的设计在经历多个版本之后是否仍能保持一致。这支持了对 Nedelcu 论点的一种更狭义的表述：自动化代码生成可能会优化那些容易观察的结果，却忽略以后才会显现的后果。但这并不能证明每个模型都缺乏有用的架构知识，也不能证明所有借助 AI 开发的项目都会逐渐恶化。
Nedelcu 还认为，专业能力离不开从失败中获得的经验。工程师会由此学会判断哪些抽象真正可以复用，哪些捷径会给未来造成限制，以及何时局部简化反而会遮蔽系统的真实意图。他认为，如果开发人员不再阅读或编写代码，就会失去作出这些判断并从其后果中学习的机会。由此产生的风险具有组织层面的影响：当责任被惯常地交给工具时，关于某项设计为何有效——或为何已经失效——的知识可能无法保留下来。
所提供的德雷福斯技能习得模型为这一部分论点提供了背景。该模型认为，学习者最初依赖明确的规则和程序，随后通过经验逐渐形成更直觉、更能结合具体情境的判断能力。它还警告说，如果持续依赖有意识的规则，可能会阻碍能力从胜任阶段继续提升。这一框架有助于理解 Nedelcu 的担忧，但它并不是证明 AI 编程会产生同样影响的独立证据。该模型描述的是一种技能发展理论；它没有测试编程智能体，没有衡量软件维护工作，也没有验证本文所作的预测。
随之而来的一个实际问题是：团队能否使用编程智能体，同时又不放弃架构判断？现有证据无法回答这个问题。不过，它确实指出了负责任的使用方式必须保留哪些环节：工程师必须检查生成的改动，理解设计权衡，维护能够检验关键行为的测试，并随着需求变化重新审视既有决定。自动化可以处理重复性工作，而人类仍应负责界定边界、维护不变量，并掌握设计背后的理由。
现有证据也未能解决一些重要比较。它没有提供 AI 辅助编写与人工编写的代码之间的对照研究，没有对维护成本进行长期跟踪衡量，也没有证明“不用 AI”的政策能够带来竞争优势。它同样没有证明代码质量不存在有用的衡量指标。可以成立的结论要狭窄得多：容易衡量的信号只是长期可维护性的不完整替代指标，组织不应把构建通过视为一项设计能够经得起时间考验的证据。
对读者而言，真正有用的启示在于实际操作，而不是反对技术。当决策的后果不会立即显现时，应继续让人参与其中。记录架构决策的理由，要求进行有实质内容的审查，并把生成的代码视为一个需要理解的提案，而不是自主智慧的来源。这种做法既能保留自动化带来的效率优势，也能应对 Nedelcu 所指出的特定失效模式：代码库现在可以运行，但随着时间推移，就连团队自身也会越来越难以修改它。