Jacob Lauritzen：AI 工程、法律工作与 Legora 的建设

Legora 首席技术官 Jacob Lauritzen 与 Harry Stebbings 讨论 AI 辅助工程、企业软件和法律工作。Stebbings 说自己是 Legora 的投资人；Lauritzen 对公司产品和竞争对手的评价来自他在公司的角色。

Lauritzen 说，Legora 是他工作过的第一家达到这一规模的公司，他既将缺乏既有经验视为实验机会，也认为这要求自己保持谦逊。他预计，随着工具变化，工程组织需要不断修订流程。

他说 Legora 工程师使用 Claude Code 和 Cursor 等工具，按照他的经验，他们可以更快发布和调试。这个生产率比较是他对团队的判断，并非受控测量，也不能证明所有 AI 生成的软件都更好。

Lauritzen 将软件开发分为产品探索、实现和审查。当编写代码变得更便宜时，他认为产品定义以及审查架构、安全和可靠性影响正成为更大的瓶颈。他仍在探索如何最有效地改善产品流程。

Legora 使用 AI 审查工具，但 Lauritzen 认为这些工具还不成熟。他希望更好的工具能突出系统层面的影响和取舍，而不是迫使审查者检查每一行；他认为重大变更仍需要人类判断。

他预测工程师会花更多时间设计系统和赋能智能体，包括建立环境和反馈循环。这是对工作方式的预测，并非代码生成或维护已经能够在没有监督的情况下安全运行的证据。

对于在不断扩大的代码库中运行的智能体，Lauritzen 强调设置防护边界：明确允许的操作、数据访问和系统边界。这类控制可以降低风险，但不能保证智能体在所有情况下都正确行动。

被问及 Legora 的 AI 生成代码时，他说根据近期的一次内部查看，Claude 和 Cursor 贡献了远超一半的产出。他没有提供测量方法，因此该百分比应视为他的估计。

Lauritzen 同意生成更多代码可能带来安全问题，并说 Legora 仍对每个 pull request 进行人工审查。他希望风险评分能提高效率，但说防御尚未达到自己希望的水平。他提到一次内部供应商事件，并称客户未受影响；节目没有独立验证其范围。

他介绍了用事件处理智能体检查日志和遥测数据、协助撰写事后复盘，同时仍由人员参与响应。他说，产品经理也可以先制作原型并与用户测试，再交给工程师可靠地整合到系统中。

Lauritzen 认为设计可能从讨论每个独立功能，转向关注一致的导航、视觉语言和判断。Legora 仍为此使用 Figma；他承认存储和设计工作流程可能会演变。

他将产品“品味”定义为公司对自己是什么、不是什么作出的鲜明选择，而不是让通用 AI 输出使所有产品看起来一样。Stebbings 质疑品味能否长期形成差异化；Lauritzen 相信它可以帮助创造独特体验。

Lauritzen 认为，一个复制品可能很快看起来相似，但企业产品还需要处理边缘情况、访问控制、审计日志和可靠行为。这是他对 Legora 所处市场的竞争论点，并不保证某个具体实现安全或具有防御力。

他区分了模型开发、产品开发和人类采用的速度。他说，对法律客户而言，工作是把快速变化的技术转化为可用工作流程，并帮助客户采用；他希望这能减少常规工作，让人有更多时间进行判断。

Legora 也尝试内部构建工具。Lauritzen 举例说，一名员工创建了帮助同事从加拿大搬到瑞典的指南；这是生产率方面的轶事，不是法律建议，也不能证明该应用完整或保持最新。

关于自建还是购买，他区分了范围广但相对浅的应用，与隐藏着复杂细节的深层系统。他说，前者如果需要大量定制，自建可能有吸引力；后者可能不适合从头重建。

产品经理应该成为全职工程师吗？Lauritzen 认为取决于业务。在 Legora，他认为客户研究和信息综合是瓶颈，因此产品经理应使用原型清楚传达想法，但不应花太多时间编码而耽误探索。

他给计算机科学应届生的建议是学会学习，并随着工具变化不断适应。他认为适应能力和雄心很重要，但没有声称存在一条必然成功的职业道路。

Lauritzen 认为，Legora 的价值不只取决于底层模型：他提到法律工作流程、企业功能和模型路由。他说模型仍然不可或缺，模型改进也有助于产品。这是 CTO 对公司产品的描述，并非独立比较。

他说，团队会针对不同任务评估约十个模型，通常将输出质量置于延迟或成本之上。他举例说，律师可能愿意等待更久以获得更好的回答；这并不能证明任何 AI 回答在法律上正确，也不能证明它适合在未经审查的情况下使用。

Lauritzen 欢迎开放模型的进步，并举例说自己在本地运行较小模型。他希望出于主权和安全原因拥有竞争以及更多欧洲和美国开放模型，但没有声称任何模型因为开放就自动安全。

谈到模型架构和训练效率，他说自己不知道当前方法是否会进入平台期，也不知道什么会取代它。他提到一项新基准，但明确表示需要验证；访谈没有确定任何比较结果。

Lauritzen 预计企业需要人员构建和维护内部 AI 系统。他说，Legora 目前使用前置部署工程师来教育和帮助客户，同时预测未来对这类支持的需求可能下降。

被问及竞争对手 Harvey 做得更好的方面时，他说 Harvey 招聘更积极。Lauritzen 后悔低估了 Legora 自身的工程需求，并说录制时团队约有 80 名工程师；这一人数是他的陈述，未经独立验证。

他希望自己更早组建开发者体验团队。他说，目前三人团队改善本地环境、构建后台编码和审查智能体，并帮助新工程师通过代码仓库文档寻找答案。这些是他对内部工具及其收益的描述。

Lauritzen 对欧洲和美国招聘提出宽泛印象，并明确承认自己在概括。他说 Legora 也曾需要向一些欧洲候选人解释股权薪酬；这一经历不应被视为对任一地区劳动者的规则。

谈到 token maxing，他批评仅为用量设置排行榜并在绩效考核中奖励消耗的做法。他更倾向于通过演示和认可有效产出来激励员工，并认为路由和支出限额可以帮助企业合理使用不同模型。

Stebbings 和 Lauritzen 讨论了据报道涉及 Cursor 与 xAI 的收购及其可能对模型独立性的影响。他们将交易作为讨论前提，但节目没有独立确定其条款或影响。Stebbings 在讨论其他地方说自己投资了竞争公司。

Lauritzen 预测，集成开发环境将发生变化，可能更偏向以图形形式呈现系统和架构，而不是主要围绕代码行。他说自己不知道下一代界面会是什么样。

被问及愿意为每名工程师花多少 AI 工具费用时，他说机会成本比固定百分比更重要：在 Legora 的竞争环境中，更快的学习和产出可能证明支出值得，而其他公司的正确计算可能不同。

他后悔过晚投资开发者体验，也低估了增长速度。现在他要求团队考虑系统能否承受大得多的用量，包括大型文档处理任务产生的突发负载。

对于跨多份文档提取信息的表格，Lauritzen 描述了公平排队：大型任务可以等待，同时让小型任务保持快速响应。这是工程设计示例，并不是所有法律文档都能被正确理解的主张。

如果只能在六个月内选择领先模型或更优秀的工程师，他会选工程师，因为他相信强大的团队能在模型变化时持续改进系统。他还说自己会评估 CTO 的工作表现，如果其他人能更好地解决公司问题，他愿意让出角色。

Lauritzen 说，有经验且具备技术能力的管理者可能很难招聘，并介绍了由产品经理和亲自参与技术工作的工程经理组成的小团队。管理者仍需对团队状态和优先级负责，而不是只增加一层协调。

他说，在 Stockholm 紧密合作帮助 Legora 快速推进，同时承认目前的方式并不适合每一位希望远程工作的工程师。这是公司的偏好，并不能证明远程工程师普遍能力较弱或生产率较低。

被追问员工人数预测时，Lauritzen 猜测到 2027 年底约有 270 名工程师，并说自己很可能会猜错。他宁可没有达到人数，也不愿降低招聘标准；这个数字是不确定的猜测，不是宣布的招聘承诺。

谈到收购，他说收购小公司可以带来一组已经合作默契的人，有时也能带来技术经验。是否保留原有代码库因情况而异；他将较顺利的整合归因于关注共同问题而非头衔的人。

Lauritzen 反思了招聘错误：尽管有所保留，他仍因候选人更资深而听从对方的判断。他说自己会尽早给出直接反馈和改进机会，同时承认自己描述的最严厉警告后，他还没有见过有人成功扭转局面。

他说，CEO Max 会参与重大产品发布和产品愿景，而较小的决策则交给团队。Lauritzen 还说，以 Jude Law 为主角的宣传活动为 Legora 带来了关注；这是公司方面的评价，没有独立活动指标支持。

在快问快答环节，Lauritzen 说自己对招聘改变了看法：现在他认为公司需要更多人。他认为，长期最大的威胁不是某一个竞争对手，而是失去持续适应的能力。

被问及对法律未来的大胆预测时，Lauritzen 设想律师最终可能更多关注谈判策略和可接受风险，而不是亲自起草每个条款。他明确称这只是直觉，并说自己并不确定；这不是对当前法律 AI 能力的描述，也不是跳过专业审查的建议。

他建议与大型既有企业竞争的初创公司努力工作并保持专注，同时对大公司员工的动力提出宽泛个人看法。这种概括并非有关具体员工的证据，也不保证初创公司成功。

被问及年底收入时，Lauritzen 和 Stebbings 试探性地猜测会超过 2.5 亿美元和 2.72 亿美元。他们随即对这一说法加以限定；这些是非正式预测，不是公司指引或经独立验证的未来结果。