杰里米·弗里曼（Jeremy Freeman），Allstacks联合创始人兼CTO – 采访系列

杰里米·弗里曼，Allstacks联合创始人兼CTO，是一位软件工程师、技术架构师和企业家，拥有跨软件开发、硬件工程、机器学习和产品创新等领域的职业生涯。自2017年联合创立Allstacks以来，他领导了公司核心平台的架构和开发，通过预测分析和AI驱动的预测帮助变革软件交付管理。在Allstacks之前，弗里曼在Ravioli Labs和CertiRx担任领导职务，在那里他从事软件工程、研究、防伪技术和产品开发。早期职业生涯中，他在初创公司、企业技术公司和学术界积累了经验，包括在Wake Technical Community College教授Web开发。他的技术背景涵盖嵌入式系统、硬件设计、大规模软件平台、机器学习和工程领导，为他提供了对构建数据驱动产品的独特视角，这些产品帮助组织改善软件交付成果。

Allstacks是一款软件工程智能和价值流管理平台，帮助组织提高软件开发的可预测性和效率。该平台集成了整个软件开发生命周期中使用的工具的数据，包括项目管理、源代码控制和部署系统，然后应用AI和机器学习来识别风险、预测交付成果并提供可行的见解。通过为工程和产品领导者提供对项目健康状况、团队绩效和开发趋势的可见性，Allstacks使组织能够做出更明智的决定、减少交付不确定性并更好地将工程工作与业务目标对齐。其技术旨在帮助公司超越基于直觉的规划，利用实时运营数据提高软件交付性能和战略执行。

您有一个从领导研究和工程团队应用机器学习到软件开发数据再到2017年联合创立Allstacks的独特旅程。您观察到了哪些具体的差距或反复出现的问题，最终促使您建立了这家公司？

当我们开始Allstacks时，我们花了很多时间进行客户发现，出现的模式是连贯的：公司接公司都有大量的数据，但仍然不知道实际发生了什么。尽管拥有最聪明的人，但交付软件仍然不可预测。

很快就清楚了，这不是一个报告问题或集成问题。它是一个关系问题。要知道某事是否处于风险之中，您需要知道工作项如何连接到分支，分支如何连接到PR，PR如何连接到冲刺目标，冲刺目标如何连接到业务计划。这种图表在标准工具链中默认情况下不存在。您必须构建它，并且构建得好，基本上是一个推理问题，这就是ML背景直接有用的地方。

从开始，我们的目标不是让个别开发人员在特性X上更快。我们的目标是让整个组织变得更好。如何将工程工作与业务成果对齐？如何使工程真正为业务服务，而不仅仅是与业务并行存在？您需要更好地理解数据关系才能回答这些问题。正是这些问题驱动了我们几乎每一个产品决策。

Allstacks专注于分析整个软件开发生命周期的数据。哪些类型的信号或模式在识别交付风险时最具预测性？

我不认为有一个单一的指标集可以预测好坏，但不同阶段和类型的组织有不同的模式。我发现更有用的方法是认识到，工程组织会经历改进的季节。这一个月可能是数据库性能，下一个月可能是跨团队的沟通，然后可能是“为什么我们无法关闭任何PR？”然后是可观察性。作为一名工程领导者，您会接收到各种信号：一些用于诊断，some用于监控，还有一些只是噪音。

有帮助的是，从您实际看到的问题开始，而不是您想要改进的指标。例如，如果您问“为什么感觉我们交付的东西比去年少”，这是正确的起点。从那里开始，我认为您需要三种类型的指标：第一，如何知道问题是真实的（也许是每个开发人员的PR数量随时间变化）；第二，正在做出什么改变以及如何跟踪它们（例如，如果您的干预是采用AI PR审查器，那么跟踪其采用情况）；第三，问题对业务的重要性。您的直觉可能是正确的，即您正在交付20％少的代码，但真正的故事可能是QA现在需要三倍的时间。您需要所有三个视角才能知道是否解决了正确的问题。

您曾在医疗保健、能源和技术等行业工作过。软件交付挑战在这些行业中如何有所不同，这又如何塑造了Allstacks平台？

我非常珍视我在非纯技术领域的经验。在SaaS公司中，很容易陷入软件本身就是目标的想法。但是，当您处于一个业务不是直接销售软件的行业时，您的角色变得更加明确：技术是为了支持业务。我经常开玩笑说，如果业务可以在不需要处理我的情况下以相同的速度完成一切，他们会毫不犹豫地选择这种选项。

这种观点实际上是有用的。它为我们在这个行业所做的所有事情提供了背景，并将许多技术辩论置于其应有的位置。业务不关心您使用Python还是Go。花费时间在重写上可能不是真正的回报所在。

然而，一个始终保持一致的事情是碎片化问题。无论行业如何，每个工程组织都有分散在十几个工具中的数据，并且这些工具之间的连接很有限。具体细节会有所不同：受监管的行业有更长的规划周期，对需求中的模糊性有更低的容忍度，因为构建错误事物的成本更高。高速度的技术店更快地积累了隐藏的债务。但核心的故障模式是相同的。团队可以告诉您什么已经交付，但他们无法追踪为什么某事物滑倒，什么是其成本，也无法在问题成为问题之前确定风险。这就是塑造我们如何构建该平台的因素。

有一个日益增长的叙事，即AI正在加速编码本身，同时暴露其他领域的弱点。为什么需求、规划和规格准备正在成为真正的瓶颈？

我们每天都能看到这一点。有了一个好的代理和一个坚实的围栏，您可以从想法直接到生产，通常直接从客户的嘴里出来，在几个小时内完成。

这种转变如此重要的部分原因是反馈循环的变化。使用类似copilot的工具时，人类始终处于建议循环中。AI提供一个完成；您立即接受或拒绝它。当它出错时，您会快速发现。建议的爆炸半径是一行代码。代理式编码的工作方式不同：您为代理提供一个目标，它分解工作，执行多步骤计划，并交付一个可用的模块。人类在交付后审查输出，而不是每一步。规格错误时，代理会根据错误的规格构建整个实现，您在审查时才会发现。

听起来像是纯粹的优势，直到您意识到以前的延迟时间实际上发挥了真正的作用。延迟时间曾经有过真正的目的。多轮聪明的人审查、规划、测试和处理想法以产生更好的系统。

现在的诱惑是绕过所有这些直接处理。但代理和围栏还没有准备好处理整个软件开发生命周期。速度是真实的，但以前那些较慢步骤中发生的质量控制没有被取代。那就是差距。

许多组织仍然使用过时的指标来衡量生产力。在AI驱动的开发环境中，领导者对生产力有何根本性的误解？

人们在这个话题上已经有了很大的进步，自从我们开始Allstacks以来。衡量标准已经转向真正重要的事情，框架也变得更加复杂。AI颠覆了这一切。

传统的软件开发从根本上受到开发人员编写符合业务和底层技术要求的代码的速度限制。这种成本正在接近零。我们正在转向更接近于个别开发人员作为代理的管理者的东西。这种模型需要一种完全不同的生产力衡量方法，这种方法的基础不是生成的令牌或花费的开发时间。

当前指标的危险之处在于，它们隐藏了团队层面实际发生的事情。具有AI工具的高级工程师正在加剧他们的优势：他们拥有代码库的背景，并且具有指导代理输出和捕获其故障的判断力。早期职业生涯的工程师通常会生成相同的代码量，但会花费更多时间审计他们无法完全评估的输出。总体速度看起来很好，甚至可能有所改善。两组人之间的差距在标准仪表板中没有体现出来。正确的问题是，不是“我们变得多快”，而是“我们交付的东西第一次就正确了多少”。

我们还没有在行业中达成对正确测量模型的共识，但开始跟踪输出质量和返工率的团队，而不仅仅是跟踪吞吐量和采用率，将比等待其他人解决这个问题的团队更好地应对挑战。

您的平台连接了项目管理系统和代码仓库等工具的数据。统一这些分散的数据源有多重要，组织如果不这样做会发生什么？

Allstacks之所以在这个领域成功，是因为我们在“上下文图”成为一个术语之前就已经开始构建它们了。我们认识到连接所有数据的必要性，以回答客户实际提出的问题。

当这种连接不存在时，操作工程数据的AI只能看到图表的一部分。它可以分析项目管理系统中的内容，也可以分析代码仓库中的内容。但是，它无法将交付延迟追溯到跨三个工具的阻塞依赖项，因为这些信号之间的关系在数据层中不存在。您最多只能获得肤浅的分析，或者在最坏的情况下，会有自信但错误的建议。模型质量并不能解决这个问题。您可以将最有能力的模型放在原始API集成之上，但仍然会错过问题的实际原因，因为数据没有编码信号之间的关系。垃圾输入，垃圾输出，无论模型有多智能。

这种连接是基础。它使我们能够成为第一个拥有这些功能的市场领导者，这些功能至今仍然无法被复制。

随着AI代理越来越深入地融入开发工作流程，准备充分的工程组织与不准备充分的组织相比如何？

讽刺的是，这与准备好接收一批暑期实习生并没有太大差异。你需要强大的自动化测试套件，良好的文档，成熟的CI/CD管道，以及你在将受信任但未经训练的开发人员添加到团队时会采取的防护措施。

同样重要的是，人们往往低估这一点，即定期回顾基础知识的重要性：您的代理规则，您的AGENTS.MD文件。您可以做一个良好的第一次尝试，但很容易陷入一种节奏，即以新的方式交付并忘记您实际上可以训练掉很多糟糕的默认设置。例如，教代理在每次提交之前运行测试不应该需要每次都有人类提醒。

我会问任何工程领导者一个诊断问题：您能告诉我上一个冲刺周期代理产生了什么，哪些输出被原样接受，哪些被修订，以及修订工作集中在哪里？如果您能回答这个问题，那么您就有了改进的工具。如果您不能，那么您就是凭感觉在做决定。

您强调了将工程工作与业务成果对齐的重要性。组织如何在实践中以可衡量的方式弥合这一差距？

我看到两种主要的失败模式。第一种是公司没有将工程团队与产品配对。许多团队结构是遗留的，已经存在很长时间了。一个团队可能拥有三种不同产品的一部分，而另一个团队可能拥有四种产品。工程投资在很大程度上取决于人数，当团队不与产品对齐时，很难看到业务期望与现实之间的差异。

第二种失败模式是没有考虑到构建和维护软件所做的所有工作。有大量的商业不可见的工程工作。我的最喜欢的例子是保持软件包更新。非技术的商业领导者通常难以理解其价值或为什么它是持续的和不可预测的。但他们可以理解投资类别。如果您将其框定为“关键安全升级”，并显示它平均消耗多少容量，那么您正在使用他们可以合作的语言。

如果您要求销售领导者在某个npm包更新和他们需要关闭的功能之间进行选择，功能会赢得每一次。但是，如果您将其框定为“我们将不符合SOC合规性，或者我们交付这个功能”，那么您现在正在向他们展示两个他们可以评估的权衡。这种重新定义就是整个游戏。我们已经看到客户仅通过使工作分类自动化而不是手动化，就将研发资本化报告时间减少了三分之二以上。机制是相同的，无论目标是资本化报告、人力资源证明还是证明AI的投资回报率：连接的数据取代了相关的电子表格。

考虑到您在工程和教学Web开发方面的背景，您如何看待开发人员在AI承担更多编码工作量时的角色演变？

坦率地说，我有点担心，尽管我相信聪明的人会想出办法。

我的担忧是真实的。新毕业生很快就会进入职场，他们从未在没有编码代理的世界中编码过。教育是否跟上这一步伐？工具正在快速发展，但高等教育并不总是与它们保持同步。另一方面，我正在关注的转变是高级工程师和高级产品人员之间的界限变得模糊。新模型中最成功的从业者是那些深深致力于产品思维的工程师。

变得更加有价值的是判断力：定义问题的精确能力，以便代理可以解决它，评估解决方案是否正确，并捕获代理输出中微妙的失败，这些失败可以通过CI，但会在以后造成架构问题。高级工程师正在加剧他们的优势，因为他们可以引导代理输出，并且知道哪些输出可以信任。早期职业生涯的担忧在于，传统的建立判断力的方式是编写大量代码并从错误中学习。这种反馈循环正在以行业尚未完全解决的方式发生变化。

话虽如此，历史提供了一些保证。曾经有一大批人认为编译器会让汇编开发人员失业。技术转变如他们所预测的那样发生了。那些没有跟随相同脚本的开发人员发生了什么？在接下来的十年里，开发人员的总数增加了。许多汇编程序员学习了一种新语言，并因为他们的基础知识而在这方面表现出色。我认为这种模式再次发生。

展望未来，您如何看待AI在未来三到五年内重塑软件开发生命周期，并且公司将在哪里获得最大的竞争优势？

我们将看到前所未有的功能竞争。随着构建成本的接近于零，公司，甚至大公司，都面临着新的约束：收集和验证足够的客户反馈，以便以可扩展的方式构建高质量的产品。

必须发生的转变是，构建的标准需要提高。当前的约束在大多数工程组织中很简单：五个首要任务，也许两个已经完成。随着代理的出现，比例发生了逆转。您可能有五个首要任务，十个次要任务和二十个可能的任务，并且可以交付一百个。问题是，最后六十五个如何避免被设计和执行得很差。

我对未来三到五年窗口相当有信心的两件事是：工程AI中的竞争优势将来自上下文的深度和广度，而不是模型质量。模型正在变得像基础设施一样；每个工具都将拥有有能力的模型。将领先平台与其他平台区分开来的将是它们对您特定组织的理解深度：您的存储库、您的团队结构、您的交付历史、您的部署模式。了解您系统的工具将产生与不了解系统的工具根本不同的答案。第二，反应性与主动性的转变。今天的工具在被问及时回答问题。在几年内，领先的工具将不断观察并在您问之前表明风险。现在构建上下文层的组织正在积累优势。下一代工具必须解决大规模的质量问题，首先解决这个问题的组织将拥有真正的优势。

感谢您这次精彩的采访，希望阅读本文的读者可以访问 Allstacks 以了解更多信息。