日本云公司grasys云开发部门负责人品地哲弥：把AI写码的审核卡点从代码评审前移到测试用例
日本云基础设施公司grasys的云开发部门负责人品地哲弥介绍了一种应对AI代码生成速度超过人工审查能力的具体方法：在实现代码生成之前，先让AI根据GitHub Issue生成测试用例，由工程师审核并批准这些测试用例作为'可执行的要件定义'，然后AI在已批准的测试框架内自主实现并自我纠错。这把Human-in-the-loop的卡点从代码评审前移到了测试用例审批，使人工介入集中在需求对齐而非逐行检查上。
品地哲弥是日本云基础设施公司grasys的云开发部门负责人，2024年4月加入该公司，负责内部基础开发和客户大规模系统的运维开发。他在接受技术评论社gihyo.jp采访时描述了一个当前AI驱动开发团队普遍面临的瓶颈：AI生成代码的速度远超工程师的理解和确认速度，导致提交Pull Request时工程师自己并未真正理解逻辑，只是看到本地能跑就交了。品地哲弥列举了由此产生的具体问题——重构时只做了表面修补、被删除的函数在别处遗留未处理、一个函数里混入了多个不相关操作、面向人的注释缺失。他认为根本原因在于使用AI的一方自己不清楚要让AI做什么。
grasys的应对方式是把人工审核的卡点从代码评审前移到测试用例审批。具体流程是：工程师在GitHub上创建一个用日语写的、AI容易理解的Issue（例如'为演示用电商网站实现商品搜索功能'），然后指示AI按照tdd-playbook创建feature分支并开始TDD流程。AI首先根据Issue内容自主生成测试用例的框架，此时流程暂停等待人工审批。工程师审核的不是生成的实现代码，而是这些用日语定义的测试用例的规格和逻辑——确认AI将要实现的范围与人类预期的需求没有偏差。如果测试用例与业务要件完全一致，就将其提交到仓库作为'绝对正解的框架'，然后通知AI开始实现。
这个设计的机制在于：测试用例比实现代码更小、更聚焦于需求本身，因此更容易被人类快速准确地验证。一旦测试框架确定，AI在实现阶段即使出现临时错误，也能通过运行测试自主发现并修正，不需要工程师每次都重新下达指令。品地哲弥把这种做法称为'シフトレフト'（shift-left），即把Human-in-the-loop从下游的代码评审前移到上游的测试用例审批。结果是：当工程师最终进行代码评审时，实现已经通过了所有测试，手返（返工）消失，评审的属人化问题也同时得到缓解。
不过品地哲弥也明确指出了这一方法无法完全解决的另一面：初级工程师可能因此丧失建立深层'心智模型'的机会。过去，工程师通过反复对照官方文档、调试报错、艰难排查来构建对系统内部结构的理解；现在这个过程被大幅省略，'只要交给AI，即使内部结构是黑箱也能跑起来'的状态很容易出现。他认为这是未来人才培养的课题，但grasys目前的策略是在组织层面设定必要的安全边界（IAM权限继承、AI无法访问工程师个人无权访问的数据），同时在边界内给予现场工程师最大裁量，让每个人自己判断哪些环节该交给AI、哪些必须自己确认。