Turn your @FastAPI into agent friendly, token efficient MCP server just in two lines of code Agent could send multiple queries in just one round, and pick fields from payload Try github.com/KLR-Pattern/fasta…

2023 年的时候，@gneubig 曾经让我读过 Steve Hicks 在 2021 年写的这篇工程博客，讲的是如何写 Small, Focused Pull Requests。到了 2026 年，再重新读这篇文章，觉得其中的工程准则比以前更加珍贵。 这篇文章讲了一个在今天 AI 生成代码的时代特别容易被忽略的区别：small 不等于 focused。五个互不相关的改动，即使总共只有几十行，也可能是一个很糟糕的 PR；一个完整的 feature 即使目标非常明确，如果改动范围太大，也可能根本没有办法被认真 review。真正好的工程实践，是把代码组织成一个其他工程师能够理解、验证，并且愿意对其负责的变更单元。 文章给出了很多非常实际的方法：先搭建能够运行的 walking skeleton，再逐渐完善功能；把 infrastructure change 和 feature implementation 分开；把有争议的架构决策与常规实现隔离；尽量增量集成，而不是等一个巨大功能全部完成之后，再一次性提交一个庞大的 PR。 我觉得 AI coding 让这些原则变得更加重要了。我们已经极大降低了代码生成的成本，但并没有同等程度地降低理解代码的成本。Agent 可以在一个下午生成几千行看起来相当合理的代码，但这不代表 human reviewer 就突然获得了在同样时间里认真理解几千行变更的能力。 更麻烦的是，如果一个巨大的 AI-generated PR 同时混合了 refactoring、架构设计、性能优化和新功能，即使测试全部通过，我们仍然很难判断其中哪些假设需要特别谨慎地审查。最终，我们只是把原本开发者需要承担的认知成本，转移给了 reviewer 和未来的 maintainer。 我非常喜欢（至少似乎不得不用） coding agent，也完全不想回到（其实我还挺想回到的，但不能只是我一个人回到）每一行代码都必须亲手写的时代。但我一直强调，AI-assisted software engineering 并不只是如何生成更多代码，而是如何把这些代码组织成能够被人类真正理解、验证和维护的变更。 Small, focused PR 不是一种过时的工程仪式，而是避免开发速度最终演变成 review debt 的重要手段。 我自己的工程启蒙很大一部分来自 Graham。我从他那里学到的远远不只是科研。他大概是最早教会我应该怎样严肃地思考软件工程的人。非常感谢 @gneubig @vijaytarian artsy.github.io/blog/2021/03…