抱歉，但你还是得思考
AI 代码生成器正在让现有应用在不同语言之间快速移植，但工程师报告说，放手不管式的重写往往会引入隐蔽的 bug、性能下降以及重要设计权衡的丢失。许多人认为，你仍然需要理解系统、明确需求并仔细审查代码，否则“workslop”只是在把工作从作者转移到审查者，并且会危及长期可靠性和可维护性。也有人认为，这只是更大趋势的一部分：管理层推动到处使用 AI、验证瓶颈日益加重，以及在日常软件工作中，谨慎的人类思考是否仍会被重视的不确定性。
AI 移植与“放手不管式”重写的局限
- 许多人原本以为基于 LLM 的移植（例如 Ruby → Rust/Elixir）会是理想场景：有测试 + 现有实现 + 明确目标。
- 但在实践中，移植出现了语义漂移、架构不匹配、性能回退和假设被破坏等问题（例如缓存与 CSRF、类型系统、并发）。
- 评论者认为，这证明你仍然需要对领域、权衡以及目标语言习惯有人的理解，而不只是盲目翻译。
思考、权衡与系统可靠性
- 多位评论者强调，真正的工作在于做权衡：兼容性 vs 速度、延迟 vs 吞吐量、内存限制、可接受的失败模式。
- AI 可以帮助实现决策，但（目前）不能负责这些决策；含糊的提示会导致任意选择。
- 有人认为，前沿模型现在会提出澄清问题，而基于旧行为的批评已经过时；也有人对此表示不同意。
代码质量、“workslop” 与审查负担
- 低成本生成加上高成本验证是一个反复出现的主题。
- 评审者描述了大量由 LLM 生成的改动集：脆弱、浅薄或架构失当，把思考负担从作者转移给了评审者。
- Brandolini 定律被引用：制造垃圾远比驳倒或修复它容易得多，尤其是在管理层施压要“把 AI 用在一切地方”的情况下。
组织激励与伦理
- 据说有些工作场所会把手工编码或对 AI 的怀疑污名化，即使 AI 输出是错误的。
- 人们担心企业可能会理性地接受更差的软件，只要它能降成本，并依赖粘性、锁定或游说，而不是质量。
如何更好地使用 AI
- 建议的模式：
- 大量用于样板代码、在强测试约束下的移植，以及琐碎的胶水代码。
- 让人类掌控架构、非功能性需求和测试设计。
- 手动输入或逐步执行 AI 建议的改动，以保持理解。
- 人们也对 AI-heavy 与 AI-light 项目的实证研究感兴趣（稳定性、漏洞、性能）。
更广泛的未来：思考、UBI 与黑客文化
- 讨论 AI + 可能的 UBI 是否会让更多人腾出时间去思考，还是资本会压制这种情况。
- 有人预见“黑客文化”和人类发明者会变得过时；也有人坚持认为，AI 远未达到取代深度工程判断的程度。