智能体
infoq.com ·
@Meryem Arik
QConAI 2030演讲：预测软件工程未来趋势
Meryem Arik在演讲中预测2030年软件工程将受token支出管理、并行智能体基础设施和非技术构建者影响，软件工程师需转向产品领导力和多智能体协调。
AI推荐理由 演讲预测2030年软件工程趋势，涉及token成本管理、并行智能体基础设施等，但内容为预测性观点，缺乏具体数据支撑。
60
正文
InfoQ主页
演讲
来自QConAI 2030的一些预测演讲
AI、机器学习与数据工程
来自QConAI 2030的一些预测演讲
查看演讲
垂直
水平
全屏
速度：
1倍
1.25倍
1.5倍
2倍
35:17
摘要
Meryem Arik讨论了她对2030年软件工程的预测。她解释了代币支出管理、并行代理基础设施和非技术构建者将如何重塑IT。她分享了关于代理驱动的供应商决策、即将到来的监管障碍，以及为什么软件工程师必须从纯编码技能转向产品领导和多代理协调的见解。
简介
Meryem Arik是Doubleword的联合创始人兼首席执行官，Doubleword是一个自托管AI推理平台，使企业团队能够在私有环境中部署领域特定或定制模型。她经常在TEDx和QCon等领先会议上发言，分享关于推理技术和企业AI的见解。
关于会议
QCon AI是一个由从业者主导的活动，完全专注于安全扩展这些工作负载所需的工程纪律。它直接提供同行组织在生产中使用的架构手册和失败指标。
文字记录
Meryem Arik：今天我要做一些非常冒险的事情，我要预测未来。众所周知，你永远不应该做预测，尤其是关于未来的预测，因为它总是会出错。一位非常聪明的人说过这句话。他实际上是波士顿的一名棒球运动员。幸运的是，我不是一个聪明的人。我是Meryem，我是Doubleword的联合创始人。我从事高吞吐量推理工作。我之所以对做出模糊预测有些自信，是因为我在这方面有相当好的记录。ChatGPT问世几个月后，我做了一个TEDx演讲，名为“AI迫在眉睫的硬件危机”，在演讲中我认为推理将非常重要，而且我们不会有足够的GPU来服务我们所需的所有推理。那是三年前，在那段时间里，NVIDIA的股价上涨了10倍。事实证明我是对的。我对过一次，可能不会再对了。
我将简要概述本次演讲的结构。我将提出我的世界观，我认为这是一个相当连贯的世界观。我将做出一系列预测，希望它们不会相互矛盾得太厉害。你可以把我演讲的各个部分看作独立的迷你演讲。我这样结构化的原因是，如果其中一个预测正确而其他都不正确，我可以在五年后剪辑出来，声称我预测未来预测得很好。它针对的是你们，所以具体来说，我将讨论我认为企业早期采用者和早期多数在2030年会关心的各种事情。最后，你可能不同意我所有的预测，这完全没问题。我倾向于认为自己是一个半理性的人，所以希望推理应该连贯。
如果你不同意我的结论，我建议你思考一下我做了哪些你不同意的假设，然后你可以从那里跟随逻辑。正如我提到的，这是针对InfoQ受众的。我将只讨论我认为对早期采用者和早期多数重要的事情。对于落后者，我们在这次会议上讨论的内容即使到那时可能仍然不相关。另外，我会指出可能的错误方向。我对自己有足够的自我意识，知道我在哪里倾向于高估和低估。我倾向于高估企业变化的速度，我认为很多人都是这样。我倾向于低估前沿改进的速度。这过去不是问题，但实际上前沿改进如此之快，以至于我们可能比我预测的要远得多。我很擅长发现瓶颈。我们在2021年决定推理将成为瓶颈，结果证明这相当准确。我还要补充一点，如果我们实现AGI，所有赌注都失效，然后我将去做我的高压清洗生意之类的。
预测框架
我将对什么做出预测？我试图选择一系列主题。我将讨论金钱以及我们在AI上花费了多少钱。我将讨论当我们的组织中有更多代码和更多构建者时会发生什么。我将讨论基础设施，我们将在什么样的基础设施之上构建。我将讨论代理，显然。我还将讨论监管，以及它如何（如果有的话）影响这里的人。然后，最后，我将讨论一下我认为AI工程师和软件工程师的职业前景。
我们如何管理和归属代币支出
让我们从金钱开始。我认为我们在2030年将花费多少？我认为它会成为讨论的话题吗？我从2022年就进入推理领域，所以相对较长。我一直认为推理成本将成为一个问题。我们会与客户讨论，推理成本是一个非常大的问题。实际上，直到大约三个月前，它才真正成为大问题，那时它似乎成了一个巨大的问题。我将讨论为什么它在那段很短的时间内成了问题。通过Twitter发布的消息称，某家未具名公司在一个月内烧掉了价值5亿美元的Claude积分。Uber在4月底之前烧光了整个代币预算。摩根大通今年在IT上的支出比去年多20亿美元。
代币支出现在正成为一个非常大的问题。我们在会议上看到了关于这个特定问题的演讲。这是一个问题，而且我们还处于早期。这是来自德勤的消息，23%的公司表示他们至少适度使用代理AI。当我们考虑“适度”意味着什么时，它通常意味着一些组织在其一些用例中使用它。我们还处于如此早期，代币支出已经是一个问题。我想破除一个神话。实际上，我们在乔丹的演讲中也听到了这个。我听到很多午餐时间的对话中流传着这样一个神话：AI实验室在补贴代币。他们最终会提高这些代币的价格，因为他们正在补贴。这不是真的。他们业务的推理部分利润很高。是的，这些组织确实亏损，尽管我认为Anthropic现在实际上在赚钱。
他们底线利润不高的原因是因为他们在基础设施和训练上花费了太多钱。首先，我要破除这个神话，我认为我们不会看到AI实验室提高其现有模型代币的价格，因为他们正在补贴。事实上，我认为代币正在变得更便宜。从经验上看，我们看到代币已经便宜了很多。它们将继续变得更便宜。如果你取一个固定的智能点，比如说固定的智商点，那个固定的智商点在过去三年中每年成本大约下降10倍。如果你在2023年使用GPT-4，那个价格在那段时间每年下降10倍。这主要是由于开源模型压力驱动的。开源模型提供商非常擅长获取前沿实验室提供的智能水平，蒸馏它们，并构建更高效的架构来交付它们。
固定智能水平的代币将继续变得更便宜。我们还将看到开源模型的兴起。这取自OpenRouter，这是一个可以访问许多不同模型的地方。使用开放模型与封闭模型的人的比例正在显著增长，部分原因是成本压力。尽管如此，支出仍在飙升，即使代币更便宜。这是非常经典的杰文斯悖论。我想我们有几个演讲提到了这一点。代币价格暴跌，但我们发现越来越多的用例来应用它们。支出持续上升。这取自高盛。我实际上认为这是一个相当保守的估计，但他们预计到2030年，代理的代币使用量将增长24倍。我实际上认为会远不止于此。用于代币的人员预算比例（我认为这是一种思考方式）将显著上升，并在2030年成为一个非常大的痛点。
我们将解锁更多用例。随着代币变得更便宜，我们找到更多应用它们的东西。我们还看到越来越多消耗代币的用例。不幸的是，或者幸运的是，每一代AI用例，从简单的聊天机器人开始，然后转向RAG，然后转向推理模型，然后转向代理，然后越来越复杂的代理，每一代都越来越消耗代币，我们应该预期这种情况会继续。我们开发的用例将更加消耗代币。然后，第三，即使我说AI实验室不会提高其现有模型的价格，他们发布的前沿模型往往更昂贵。它们往往是更大的模型，而且这些实验室也受到计算限制。预测是，这是我虚构的人在2030年QCon上做演讲，我们将看到很多像如何管理和归属代币支出以确保我们不会花费超过需要，并以正确方式归属的演讲。
我们如何处理丰富的代码？
我要做的第二个预测是关于我们如何处理丰富的代码，我们组织中更多的代码。当前的状态是，我们有非常少量或小量的代码服务于大量的用例。每个组织都有几个软件，要么内部构建，要么外部购买，然后交付给组织内可能数千名用户。我这里有一些截图，例如Salesforce。这是一个组织中许多人使用的软件，他们可能有非常不同的用例。如果我们考虑到我们在软件上一直以来的限制，这是有道理的。在我的左边，我有成千上万的用户，都有非常不同的用例。我作为IT，因为代码不是免费的，代码实际上非常昂贵，开发和维护软件都很昂贵，管理它也很昂贵。
我将把所有这些人汇集到尽可能少的应用程序中。我们最终得到的是几个应用程序服务大量用户。这是当前的状态。没有理由让导致这种情况的假设继续成立。我要提出的第一个主张是，软件成本将趋向于零。我知道这是真的，因为我在自己的世界里看到了。就在这里，我们完全重写了我们应用程序的前端，我们的产品。我认为花了我们20美元，否则会花费我们两周的工程时间。另一个例子是，因为软件成本基本上是免费的，我正在构建定制软件来计划我的婚礼，而以前我会使用Excel表格。
软件成本基本上是免费的，并将趋向于零。我们还将看到的另一件事是，业务中的任何人都将能够构建软件。它不仅对开发人员趋向于零，而且对每个人趋向于零，并且构建将变得非常容易。像Lovable这样的公司，但现在Claude和Codex也这样做。它们使构建变得异常容易，
对于
非技术人员也能构建。当代码基本上是免费的，并且技能门槛被移除时，你会看到什么？我们在组织内部看到的是，非技术人员感到有能力构建软件，而如果没有软件，他们可能只会使用Google表格。这是我组织中的一个业务发展代表构建的一个例子。
他刚大学毕业。这些都是虚拟数据，因为我让他删除了真实人员。我们在一次会议上，他在大约25分钟内构建了一个潜在客户跟踪应用，该应用连接到了我们使用的潜在客户设备，并连接到了我们的HubSpot和电子邮件系统，而这是一个完全没有技术背景的人在大约25分钟内完成的。我们将看到更多这样的情况。如果我们组织中有数千人，有数百个不同的用例，而代码不再昂贵且任何人都能构建，那么自然的结论是，我们将看到业务内部存在的不同应用出现寒武纪大爆发。我们将看到数百个极其定制的应用。这个问题已经存在。我曾在一家投资银行担任量化分析师，我们遇到过完全相同的问题，但那只是不同版本的Excel电子表格。
每个人都有自己的Excel电子表格，用不同的方式构建财务模型。这个问题已经存在，但现在它将变得更加复杂，因为它将是定制代码。很明显为什么这如此有吸引力。所有这些人都能直接以他们想要的方式解决他们的问题。同样明显的是，这将给IT带来大量我们必须应对的挑战。这很容易变成一团糟，我们会有各种形式的网络风险，也许人们使用不一致的数据，也许我们有各种数据孤岛等等，如果我们不小心，它很快就会变成一团糟。
我认为当每个人都是构建者时，我们会看到许多挑战，因为我相信这是必然的，而不是偶然的。谁对这个软件负责？谁对它的实际运行负责？如果我构建了一个应用并连接到数据源，如果它坏了，那是谁的问题？我们IT如何使这些构建者能够真正构建？Ben在这方面做了一个很棒的演讲，谈到了他的组织如何使构建者（非技术用户）能够构建这些应用。我们如何考虑网络安全，这在恶意AI攻击的世界中将成为一个日益严重的问题？我们如何拥有统一的数据标准？如果构建工具的人离开了怎么办？我们将面临大量挑战。我认为我们看到IT的角色在改变。
到目前为止，IT通常只是拥有其他人不具备的技术技能的人的归属地。例如，你很大程度上可以通过某人是否会编码来预测他们是否在技术组织。我认为这不再是区分标准了。实际上，我认为IT的角色从编写代码的人转变为赋能组织其他成员解决问题的人。我认为IT实际上变成了一个平台团队，而不是其他任何东西。我们将考虑的事情是，我们IT如何给人们提供他们需要的构建模块，以便他们能够构建完全定制的应用，但不会变成一个大麻烦？我的预测是，到2030年，我们将看到IT团队管理成千上万个内部应用的组织，我们将定义构建问责框架和赋能框架的标准，以实现这一目标。
我们使用什么基础设施？
我们将使用什么基础设施？人类对我们熟悉的事物有非常强烈的偏好。看到这一点实际上很有趣。你会看到在AWS生态系统中长大的人，他们只申请AWS的工作，因为他们有那些认证，那是他们熟悉的，他们喜欢待在自己的小圈子里。有趣的是，我们如何开始创造这种偏好。人类确实对我们非常熟悉的事物有强烈的偏好。有趣的是，代理也对它们喜欢使用的基础设施有强烈的偏好。代理喜欢使用的东西有点像配方。它们喜欢使用Supabase、Vercel、Stripe和Resend。如果你真的尝试用任何主要的编码工具（如Cursor、Claude、Codex等）构建应用，它几乎总是会使用这些工具的组合。
它们对任何事物都有强烈的偏好。这意味着几件事。我把我们的标志放在这里的原因是因为这是我们作为供应商观察到的。作为供应商，我们注意到我们的大多数客户不是工程师。我们的大多数客户是找到我们的代理，以及第一次使用我们的代理。几乎每个开发工具都必须首先为代理构建，因为代理现在是我们客户。如果你是被代理偏爱的幸运者之一，这会导致指数级增长。这是Supabase的用户增长图。它大约从2020年开始存在，现在有700万用户。你可以看到几乎所有用户都是在过去一年加入的。基本上，所有这些用户都是因为AI而来的。
下一个预测，我想在这里向Erik Peterson致敬，他也独立做出了这个预测，即代理现在正在为我们做购买决策。它
们正在决定我们使用哪种基础设施。鉴于它们选择开源工具，这没问题，但事情从来不会就此止步。代理正在为我们建立隐性的购买偏好，而企业实际上对此没有控制权。我认为这将引发非常有趣的对话：我们如何避免供应商锁定？当我们不再真正做出有意识的供应商决策时，我们如何考虑从一个工具迁移到另一个工具？不像你有一个工程师评估不同的框架并选择他们将要使用的框架。AI带着偏好而来，就像你雇佣了一堆非常有主见的工程师，他们认为Vercel是最好的。这是我们将不得不处理的事情，我认为我们将需要考虑。
我们在构建什么模式的应用？
应用模式。我们将构建什么样的AI应用？过去几年我参加了QCon，我看到了我们谈论很多关于RAG，然后是关于简单代理，现在我们谈论很多关于长时间运行的代理的历程。2030年我们将谈论构建什么样的应用？我将介绍测试时扩展的概念。基本上，测试时扩展的核心思想是，你做的推理越多，你投入问题的令牌越多，模型就越智能。这里有一些例子。在x轴上，你可以看到为解决一个问题而给出的计算量。在y轴上，你可以看到该模型在特定基准上的结果。你可以看到，给模型的计算量越多，它在基准上的表现就越好。
有两种方法可以实现测试时扩展。我们知道我们希望模型更智能。我们可以进行深度扩展或宽度扩展，或者两者结合。深度可能是，我有一个单一的代理，它可能可以访问一堆不同的工具，并以相当线性的方式行动。这是构建深度代理的一种方式。实际上，目前在企业中构建的大多数代理都采用这种相当线性的范式。或者你可以使用你的计算资源和推理资源来构建宽度代理。我向一个单一代理发送请求，但然后我有一堆不同的子代理可能在做不同的任务，或者可能都在做相同的任务并观察它们的不同之处。我基本上是在并行做很多事情。
目前大多数企业都在构建线性代理。这还没有成为企业主流。我认为有一个很好的预测是，并行代理将成为获胜的范式。我认为这有很多原因，但归结起来，第一个是延迟。运行并行推理的一个好处是，用户的端到端延迟最终会低得多，因为我只需要关心吞吐量，而不是关心一系列顺序调用。第二件事是，你可以通过智能上下文管理和智能用例专业化来构建这些并行代理，使其更便宜。然后，最后，它确实提高了准确性。你可以进行真正的试错。你也可以真正地尝试10个不同的代理做同样的事情，如果10个中有10个得到相同的答案，我对此非常有信心。
你可以做诸如此类的事情，真正提高准确性。我认为并行代理将成为获胜的范式。我对此更有信心，因为几乎所有前沿代理，比如Claude、Perplexity，都使用这种并行代理范式。我认为这些并行代理带来了很多基础设施挑战，我认为几年后我们将在QCon上讨论这些挑战。例如，一个问题是聚合。如果我有所有这些并行代理在运行，我如何实际聚合最终结果？我认为随着这些东西变得越来越大，这将是一个有趣的问题。如果我有这些非常突发的工作负载，可以从单个LLM调用立即变成一百个，我如何进行容量规划？我如何观察这一点？
如果我实际上自己托管这些东西，我如何处理内存瓶颈？我如何调度这些不同的工作负载？所有这些都将使基础设施挑战变得更加复杂。不幸的是，AI应用似乎有从基础设施简单（如简单的聊天机器人）到越来越混乱和难以管理的习惯。我认为并行代理是极其复杂、混乱的系统。我认为我们将讨论并行代理和为这些范式进行架构设计，你可以想象一个世界，我有一个提示，它可能产生10,000个子代理，每个都在做自己的事情，都在调用工具和服务。
我们在处理什么样的法规？
法规。我不确定我谈论这个是因为我是欧洲人，欧洲人喜欢谈论法规，但我确实认为这将是一个非常现实的问题，我们将需要考虑。我们一直处于一个非常奇怪的位置，鉴于这项技术的重要性，法规却很少。有欧盟AI法案，主要是在生成式AI之前起草的。然后当生成式AI出现时，他们说，我们不想过度扼杀创新，所以还没有真正的执法。他们真的不知道是否能执行。目前这相当无力。美国有指导方针，本可以规范或提供关于如何使用生成式AI的指导，但去年特朗普明确排除了生成式AI。目前的法规相当薄弱，总体上由企业和构建用例的人们来决定如何负责任地行事。
这实际上正在改变。我拍了这张截图。我实际上不认为这是任何有意义的法规，但似乎人们开始不再采取这种完全放任的方法。作为国家，我实际上会说美国可能比大多数国家有更多的阻力，或者至少在欧洲，我们已经看到普通民众对AI的非常大的阻力。我发现这个非常可爱的小女孩，显然她非常不喜欢数据中心，我们看到这种情况越来越多。普通人真的对AI不兴奋。我相信这里很多人是兴奋的，因为我们是从业者，我们非常接近它，但普通人不是，而且随着时间的推移，他们越来越不兴奋。这是皮尤研究中心的一项研究。目前50%的美国人更担心AI而不是兴奋。实际上只有10%的美国人更兴奋而不是担心。
绝大多数美国人并不真正想要这个东西，或者不一定理解为什么它是一个好主意。这有道理。它真的很可怕，作为一个行业，我们并没有帮助自己。我们谈论了很多关于世界末日的事情。我确实理解为什么它非常可怕。我要做一个预测。我的预测是，2028年美国选举活动将在很大程度上被反AI和反亿万富翁情绪主导。我确实认为反AI情绪将非常真实。我们已经看到了这一点。伊丽莎白·沃伦在谈论对AI征税。伯尼·桑德斯宣布他想没收所有主要AI实验室的50%。这也不仅仅是民主党的问题。奥利（共和党人）和罗恩·德桑蒂斯也都非常反AI。这似乎是各方都同意的事情之一。
我认为当我们开始看到AI对我们经济的影响时，我认为我们实际上还没有真正看到任何影响，这将变得越来越激烈。我预测的时间线是，在未来几年，我们将看到越来越激烈的反AI、反数据中心运动。2028年我认为我们可能会有一个反AI候选人获胜。这意味着2029年我们将看到新的AI法规。到2030年我们在这里时，我们将讨论实施这些法规。我认为这可能是相当严厉的法规，并将影响我们实际构建的方式。这是我的预测，我认为我们将越来越多地进入一个对AI更敌对的政治环境。我们很幸运，过去几年它一直不那么敌对。
2030年什么是“优秀的软件工程师”？
我要谈论的最后一件事情是，2030年什么造就一名优秀的软件工程师？在未来几年，我们需要的技能组合如何变化，以及我们如何实施AI？我取自我认为是softwareengineerscareerleveling.com或类似的网站。它讨论了什么造就一名优秀软件工程师的不同轴。有很多不同的轴。你可以有技术。这可能是人们在达到管理层之前想到的主要轴。你对技术栈和工具的了解有多好？比如你作为技术专家的天赋如何？我们谈论与团队的关系。你容易合作吗？你不好合作吗？人们喜欢你吗？谈论流程。你对开发过程的参与度如何？你在这方面有多好？我们谈论系统。我认为这一个特别有趣。
你对系统的所有权水平如何？我认为这一个特别有趣的原因是，软件职业级别框架主要作为保留工具存在。它们主要存在是为了让你不会离开。我们确实奖励那些理解系统的人。因为很难让新人进来理解整个技术栈并在此基础上构建。我们谈论你对整个系统的理解有多好。然后我们谈论影响力。这也是我们谈论管理的时候。这些是我们目前在软件工程中关心的轴。根据不同的级别和技能组合，你会在这个五边形中处于不同的水平。例如，如果你是一个工程经理6，你可能在技术上不再那么高，但你在人员和流程上会相当高。如果你以前是开发人员，你可能在每个方面都是通才。
每个人都有自己的五边形。这在很大程度上决定了他们在职业级别框架中的位置。我认为这很好地说明了在AI时代，这些中的大多数重要性将以相当激进的方式改变。我认为对技术栈的了解对大多数软件工程师来说不再那么重要，或者将继续不再那么重要。我认为有一些例外，当人们在特定类型的技术上工作时，那会改变。我认为总的来说，技术在2030年将比现在不那么重要。我认为也有很好的理由认为你与团队的关系可能不那么重要，或者至少会改变。我们越来越多地看到，人们不再需要在一个大团队中交付复杂的软件。
他们实际上与许多代理合作来交付复杂的软件。我们看到越来越多的人能够独自拥有整个项目。我认为这种关系会改变。我们衡量它的方式会改变。流程也会有所改变。有一种论点认为，软件开发周期之所以存在，很大程度上是因为有很多人参与。如果系统中有AI，不清楚这会如何改变。对系统的所有权水平我认为是一个非常有趣的。我认为在未来的新职业级别框架中，这将变得不那么重要。我认为实际上，考虑到他们有AI工具，让新人上手复杂技术栈的难度变得容易得多。奖励人们对系统的深入了解不再那么重要。
我认为影响力也可能改变。重要的是，我认为我们在这里遗漏了一个非常大的东西，那就是产品。对于许多组织，你会看到产品和工程有稍微分开的角色。我认为产品思维、需求收集和理解将成为软件工程师角色中越来越大的部分。支持这一点的证据是，寻找产品工程师的公司数量在过去一年飙升。我认为我们将看到越来越多的期望，即每个人都将成为产品工程师。我们如何使用AI我认为也成为级别划分的关键部分。我知道在许多演讲中我们谈到了tokenmaxxing，你应该tokenmax吗？那意味着什么？我倾向于同意Modal创始人Erik的观点，他说实际上我们想要最大化的是这个比率，即你交付的任何输出除以你的工资加上你的令牌使用量。
如果你能够通过每月使用价值20,000美元的令牌来最大化这个比率，那很好。如果你能够通过使用500美元来最大化它，那也很好。我认为我们将以这个指标来衡量，而不是其他任何东西。我认为当我们考虑未来什么造就一名优秀的软件工程师时，会改变的事情是，我认为深度技术技能越来越不重要，实际上产品、项目管理（因为你的工程师将被要求交付越来越复杂的项目）和需求设定将成为越来越重要的技能。有点像指挥。我们组织内部有工程师同时管理5到10个独立的代理，他们基本上成为个人团队负责人，成为指挥。我认为我们将看到更多这样的情况成为我们衡量的标准。我预测我们将有一个演讲，标题类似于“当技术技能不重要时构建软件工程职业级别框架”。这个标题有点争议，但会吸引人们参加。
回顾
我的预测。令牌支出将上升。它将成为一个非常大的管理问题。我们将有更多的代码和更多的构建者，IT的工作是弄清楚如何为他们提供框架，以免变成混乱。我们将有代理在基础设施方面做出购买决策，我认为这将是我们如何管理它的一个有趣问题。我们将有非常并行的代理，我认为这将导致许多我们需要处理的基础设施挑战。我认为我们将有一堆新的AI法规和怀疑AI的政府。最后，我认为优秀软件工程师的定义将改变。我将做最后一个预测。演讲标题是2030年我们将在QCon AI上谈论什么。也许我总体上不同意这个演讲标题。我认为2030年不会有QCon AI。我认为我们将只是在QCon，我认为这将只是我们做的所有软件工程的一部分。
查看更多带文字记录的演讲
录制于：
2026年9月5日
由
Meryem Arik
相关赞助商
此内容属于AI、机器学习与数据工程主题
相关主题：
开发
架构与设计
AI、机器学习与数据工程
治理
QCon AI波士顿2026
模式
QCon软件开发大会
AI架构
法规
文字记录
企业架构
技术趋势
生产力
政府
基础设施
代理
架构
InfoQ
相关编辑内容
InfoQ上热门
Kubernetes推广KYAML作为更安全、更一致的处理清单的方式
Airbnb通过服务器驱动架构将认证代码减少60%
OpenClaw 2.0发布，简化设置并支持协作代理
Google Mantis：用于减少误报的代理漏洞扫描工具
Java新闻综述：TornadoVM 6、JReleaser、LangChain4j、Java Operator SDK、JHipster、Yupiik Fusion
个性胜过技能：Adam Wachtel如何构建工程团队
查看原文（中文正文为 AI 翻译）
InfoQ Homepage
Presentations
A Few Predicted Talks From QConAI 2030
AI, ML & Data Engineering
A Few Predicted Talks From QConAI 2030
View Presentation
Vertical
Horizontal
Full
Speed:
1x
1.25x
1.5x
2x
35:17
Summary
Meryem Arik discusses her predictions for software engineering in 2030. She explains how token spend management, parallel agent infrastructure, and non-technical builders will reshape IT. She shares insights on agent-driven vendor decisions, upcoming regulatory hurdles, and why software engineers must pivot from pure coding skills toward product leadership and multi-agent coordination.
Bio
Meryem Arik is the Co-founder and CEO of Doubleword, a self-hosted AI inference platform empowering enterprise teams to deploy domain-specific or custom models in their private environment. She frequently speaks at leading conferences, including TEDx and QCon, sharing insights on inference technology and enterprise AI.
About the conference
QCon AI is a practitioner-led event focused entirely on the engineering discipline required to scale these workloads safely. It provides direct
access to the architectural playbooks and failure metrics that peer organizations use in production.
Transcript
Meryem Arik: I'm going to be doing something very risky today, and I'm going to be predicting the future. You should famously never, ever make predictions, especially about the future, because it always goes wrong. A very wise man said this. He actually was a baseball player in Boston. Luckily, I'm not a wise man. I'm Meryem. I'm the cofounder of Doubleword. I work on high throughput inference. The reason why I felt somewhat confident to make vague predictions is I actually have a fairly good track record of it. A couple months after ChatGPT came out, I did a TEDx talk called, AI's Looming Hardware Crisis, where I argued that inference would be very important and that we would not have enough GPUs to be able to serve all the inference that we needed. This was three years ago, and in that time, NVIDIA's stock price has gone up 10x. It turns out I was right. I was right once, I might not be right again.
I'm going to give you a brief overview of the structure of this talk. I'm going to present my worldview, which I think is a fairly coherent worldview. I'm going to make a bunch of predictions, and they hopefully shouldn't contradict each other too drastically. You can think of the sections of my talk as standalone mini-talks. The reason I structured it like this is so I can clip it up in five years' time if one of them is right and none of the others are right, and I can claim that I predicted the future really well. It's aimed at you, so specifically, I'm going to be talking about the types of things that I think enterprise early adopters and early majority will be caring about in 2030. Finally, you might not agree with all of my predictions, and that's totally fine. I tend to think of myself as a semi-logical person, and so hopefully the reasoning should follow.
If you disagree with my conclusions, I'd recommend that you think about what assumptions that I've made that you disagree with, and then you can follow the logic of where you go from there. As I mentioned, this is aimed at the InfoQ audience. I'm only going to be talking about things that I think are going to matter to the early adopters and early majority. For the laggards, the stuff that we talked about at this conference probably still won't be relevant even then. Also, I'll make a note on the likely direction of error. I'm self-aware enough of myself to know where I tend to overestimate and underestimate things. I tend to overestimate how quickly enterprises will change, which I think a lot of people do. I tend to underestimate how quickly the frontier has improved. This didn't used to be a problem, but actually the frontier has been improving so quickly that it's possible that we're actually way further than I'm predicting. I'm pretty good at spotting bottlenecks. We decided that inference would be a bottleneck in 2021, and that turned out to be pretty good. I would also caveat that if we achieve AGI, all of the bets are off, and then I'll be doing my power washing business or something like that.
Prediction Framework
What am I going to be making predictions about? I've tried to pick a range of topics. I'm going to talk about money and how much money we are spending on AI. I'm going to be talking about what happens when we have more code and more builders within our organizations. I'm going to be talking about infrastructure, what's the kind of infrastructure we're going to be building on top of. I'm going to be talking about agents, obviously. I'll talk also about regulation and how, if at all, it's going to impact people here. Then, finally, I'm going to talk a bit about what I think careers look like for AI engineers and software engineers.
How We Manage and Attribute Token Spend
Let's start with money. How much do I think we're going to be spending in 2030? Do I think it's going to be a topic of conversation? I've been in the inference space since 2022, so a relatively long time. I've always thought that inference cost was going to become a problem. We would talk about it with customers, that inference cost is a really big issue. Actually, it wasn't really a big issue until about three months ago, when it seems to be a huge issue. I'll talk about why it's become an issue in that very short period of time. It was released via Twitter that some unnamed company blew through half a billion dollars' worth of Claude credits in one month. Uber has burned through their entire token budget by the end of April. J.P. Morgan is spending $2 billion more on IT this year than it did last year.
Token spending is becoming a very big issue now. We've seen talks in the conference about this particular issue. It's an issue, and we are still so early. This is a source from Deloitte, 23% of companies say they use agentic AI at least moderately. When we think about what moderately means, it typically means that some of the organizations are using it on some of their use cases. We are still so early, and token spend is already an issue. There's a myth that I want to dispel. Actually, we heard this as well in Jordan's talk. There's this myth that I've actually heard from a lot of the lunchtime conversations that AI labs are subsidizing tokens. That they're eventually going to jack up the price of these tokens, because they're subsidizing it. That's not true. Their inference part of their businesses are highly profitable. Yes, these organizations do lose money, although I think actually Anthropic now makes money.
The reason they are not as highly profitable on their bottom line is because they are spending so much money on infrastructure and so much money on training. I'm going to firstly dispel this myth that I don't think we're going to see AI labs jacking up token prices for their existing models because they're subsidizing it. In fact, I think tokens are getting cheaper. Empirically, we've seen that tokens have gotten much cheaper. They are going to continue to. If you take a fixed intelligence point, so let's say a fixed IQ point, that fixed IQ point over the last three years has gone down and cost roughly 10x every single year. If you were using GPT-4 in 2023, that price has gone down 10x year over year in that time. That is largely driven thanks to open-source model pressures. The open-source model providers have gotten very good at taking an intelligence level provided by the frontier labs and distilling them and building more efficient architectures to deliver them.
Tokens for a fixed intelligence level are going to continue to get cheaper. We'll also see a rise of open-source models. This is taken from OpenRouter, which is a place where you can get access to a lot of different models. The share of people using open models versus closed is growing significantly, in part because of cost pressures. Despite that, spend is still skyrocketing, even with cheaper tokens. This is the very classic Jevons paradox. I think we've had a couple talks mention this exactly. Token prices are plummeting, but we're finding more and more use cases to apply them to. Spend is continuing to rise. This is taken from Goldman Sachs. I actually think it's a fairly conservative estimate, but they expect that token usage by agents will multiply 24 times by 2030. I actually think it'll be much more than this. The percentage of headcount budget, which I think is like a way to think about it, that is spent on tokens will go up significantly and will be a very big pain point in 2030.
We're going to have more use cases that are unlocked. As tokens get cheaper, we find more things to apply them to. We also are seeing more and more token-hungry use cases. Unfortunately, or fortunately, every single generation of AI use cases that have come out, so starting with simple chatbots, then moving to RAG, then moving to reasoning models, then moving to agents, and then increasingly complex agents, every single generation is getting more and more token-hungry, and we should expect that to continue. The use cases we develop will be more token-hungry. Then, thirdly, even though I said that AI labs are not going to jack up the prices of their existing models, the frontier models that they release tend to be more expensive. They tend to be bigger models, and also these labs are pretty compute-constrained. The prediction, this is my imaginary person giving a talk at QCon in 2030, that we're going to be seeing a lot of talks like how to manage and attribute token spend to make sure that we are not spending more than we need to and that we're attributing it in the right way.
How Do We Deal with Abundant Code?
The second prediction that I want to make is about what we do with abundant code, with more code in our organizations. The current state of play is that we have a very small number or a small amount of code that services a huge number of use cases. Every organization has a couple pieces of software that they either build internally or that they buy externally and they deliver that to maybe thousands of users within their organization. I've got screenshots here of, for example, Salesforce. It's a piece of software that is used by many people in the organization who might have very different use cases. This makes sense if you take the limitations that we have had on software. On my left, I have hundreds of thousands of different users all with very different use cases. I, as IT, because code is not free, code is actually very expensive, it's expensive to both develop software and kill software, and it's expensive to manage that as well.
I'm going to funnel all of these different people into as few apps at the end of the process. What we end up is we have a couple apps servicing a huge number of users. That's the current state of play. There's no reason why the assumptions that made this happen should continue to hold. The first claim that I want to make is that the cost of software is going to trend towards zero. I know this is true because I've seen it in my own world. Right here, we made a complete frontend rewrite of our application, of our product. I think it cost us $20 to do it, and otherwise it would have cost us two weeks of engineering time. Another example is because the cost of software is essentially free, I'm building custom software to plan my wedding, in a way that I otherwise would have used an Excel sheet.
The cost of software is basically free and is going to trend towards zero. The other thing that we're going to see is that anyone in the business is going to be able to build software. It's not just trending towards zero for developers, but it's trending towards zero for everyone, and it's going to get very easy to build. Companies like Lovable, but now also Claude do this, and Codex do this. They're making it exceptionally easy for non-technical people to build. When you have code that is free, essentially, and the skill barrier is removed, then what are you going to see? What we've seen within our organization is that we have seen non-technical people feel empowered to build software in a way that otherwise they would have not used software and would maybe have just used a Google sheet. This is an example of something that a BDR in my organization built.
He's fresh out of college. This is all dummy data because I asked him to remove real people. We were at a conference and he built in about 25 minutes a lead tracking app that connected to the lead device that we were using and connected to our HubSpot and connected to our email systems as well, and this is a completely non-technical guy who did this in about 25 minutes. We're going to see way more of that. If we have thousands of people in our organization with hundreds of different use cases, and code is no longer expensive to build and it's also the case that anyone can build, then the natural conclusion is that we're going to see a Cambrian explosion in the different applications that exist within our business. We're going to see hundreds of incredibly bespoke applications. This problem already exists. I used to be a quant working in an investment bank, and we had this exact same problem but this was just different versions of Excel spreadsheets.
Everyone had their own Excel spreadsheet with their own different way of building their financial models. This problem has already existed but now it's going to be even more complex because it's going to be custom code. It's really obvious why this is so appealing. All of these people get their problem directly solved exactly in the way they want it to be solved. It's also obvious that it's going to raise a huge number of challenges for IT that we're going to have to deal with. This can very easily turn into a bit of a mess where we have various forms of cyber risk, maybe people are using non-consistent data. Maybe we have various data silos or whatever it is, it can turn into a mess really quickly if we're not going to be careful.
I think we're going to see a number of challenges when everyone is a builder, because it is a when and not an if, I believe. Who is accountable for this software? Who is accountable that it actually works? If I build an application and it's connected to a data source, if that breaks, whose problem is that? How do we as IT enable these builders to actually be able to build? Ben did a great session on this on talking about how his organization is enabling builders, non-technical users, to build these applications. How do we think about cyber, which is going to become an increasing problem in the world of malicious AI attacks? How do we have single data standards? What happens if the person who built the tool leaves? There's a huge number of challenges that we're going to have. I think we see the role of IT changing.
Until now, IT has often just been a home of the people that have technical skills that other people don't have. For example, you can largely predict whether someone is in the tech org or not by whether or not they know how to code. That's no longer going to be the distinction I don't think. I actually think the role of IT goes from being the people that write code to the people that are enabling the rest of the organization to solve their problems. I think IT actually turns into way more of a platform team than it does anything else. The kinds of things that we'll be thinking about is, how do we as IT give people the building blocks they need such that they can build their completely custom bespoke app but in a way that doesn't turn into a big headache? My prediction is that by 2030 we're going to have organizations where IT teams are managing thousands and thousands of internal apps, and we're defining the standards of what it means to build accountability frameworks for this and build enablement frameworks to make this happen.
What Infrastructure Are We Using?
What infrastructure are we going to be using? Humans have very strong preferences for things that we're familiar with. It's actually really quite funny to see. You'll see someone who's been brought up in the AWS ecosystem and the only jobs they'll apply to are AWS jobs because they've got those certifications and that's what they're familiar with, and they like being in their own little bubble. It's actually very interesting how we've started to create that. Humans really have very strong preferences for things that we're very familiar with. What's fun is that agents also have really strong preferences on the infrastructure they like to use too. There's a bit of a recipe of like what agents like to use. They like to use Supabase and Vercel and Stripe and Resend. If you ever really try to build an app with any of the major coding tools like Cursor, Claude, Codex, whatever it is, it'll almost always use a combination of these tools.
They've got strong preferences from whatever it is. There are a couple things, of what that means. The reason I included our logo in this is because this is something we're observing as a vendor. As a vendor, we are noticing that the majority of our clients are not engineers. The majority of our clients are agents who find us and agents who use us for the first time as well. Almost every single dev tool is having to build agent first because agents are our customers now. This is causing exponential growth if you are one of the lucky ones that the agents prefer. This is the user count growth for Supabase. It's been around since about 2020, and it's got 7 million users now. You can see pretty much all of those users came in the last year. Basically, all of those users are users that have come thanks to AI.
The next prediction, I want to give a shout out here to Erik Peterson who made this prediction as well independently earlier on, that agents are now making our buying decisions for us. They're deciding which infrastructure we're using. That's fine given they're picking open-source tools, but it never really stops there. Agents are building implicit buying preferences for us that the business actually has no control over. I think this is going to lead to really interesting conversations about, how do we avoid vendor lock-in? How do we think about migrating from one tool to the other when we're not actually making conscious vendor decisions anymore? It's not like you have an engineer evaluating the different frameworks and picking the framework they're going to use. AI is coming with preferences, and it's like you've hired a whole bunch of engineers that are super opinionated that Vercel is the best. This is something that we're going to have to deal with and I think we're going to be thinking about.
What Pattern of Applications Are We Building?
Application patterns. What kinds of AI applications are we going to be building? I've been to QCon for the last couple years, and I've seen the journey of us talking a bunch about RAG and then about simple agents and now we're talking a lot about longer running agents. What kind of applications are we going to talk about building in 2030? I'm going to introduce the concept of test time scaling. Essentially the idea around test time scaling is that the more inference you do, the more tokens you throw at a problem, the more intelligent that the model gets. Here are some examples. On the x-axis you can see the amount of compute that is given to solve a problem. On the y-axis you can see the results of that model on a particular benchmark. You can see the more compute you give a model, the better it performs on benchmarks.
There's two ways that you can implement test time scaling. We know we want models to be smarter. We can either have deep or we can have wide scaling, or we can have a combination of both. Deep might be, I have a singular agent which maybe has access to a bunch of different tools and it acts in a fairly linear way. This is a way that you could build a deep agent. Actually, the majority of agents that are being built in enterprise right now take this paradigm of being fairly linear. Or you could use your compute resource and you could use your inference resource instead to build wide agents. I send a request to a singular agent, but then I have a bunch of different sub-agents maybe doing different tasks, maybe all doing the same tasks and seeing where they differ. I'm essentially doing a lot of things in parallel.
Most enterprises right now are building linear agents. This is not something that has hit enterprise mainstream yet. I think there's a pretty good prediction to be made that parallel agents are going to be the winning paradigm. I think this for a lot of reasons, but to boil it down, the first one is latency. One of the nice things about running parallel inference is my end-to-end latency for a user ends up being much lower because I just need to care about throughput as opposed to caring about a bunch of sequential calls. The second thing is you can actually construct these parallel agents to be much cheaper by doing smart context management and also by doing smart use case specialization as well. Then also, finally, it really improves accuracy. You can do genuine trial and error. You can also do genuine, I want to try 10 different agents to do the same thing, and if I get 10 out of 10 with the same answer, I'm really confident in that.
You can do things like that that really improve accuracy. I think parallel agents are going to be the winning paradigm. I'm also more confident by this because pretty much all the frontier agents, so like your Claude, Perplexity, they all use this paradigm of parallel agents. I think these parallel agents come with a lot of infrastructure challenges that I think we're going to be talking about at QCon in a couple years. For example, one problem is aggregation. If I have all of these parallel agents going off, how do I actually aggregate what the end result is? That's I think going to be an interesting problem as these things get bigger and bigger. How do I do capacity planning if I end up having these very bursty workloads where I can go from a single LLM call to immediately then going to a hundred? How do I observe this?
How do I deal with the memory bottlenecks if I'm actually hosting these things myself? How do I schedule these different workloads as well? All of this will end up making the infrastructure challenges much more complicated. Unfortunately, AI applications seem to have the habit of going from more infrastructurally simple, like a simple chatbot, to more and more chaotic and difficult to manage. I think parallel agents are incredibly complex, chaotic systems. I think we're going to be talking about parallel agents and architecting for these paradigms where you can imagine a world in which I have a single prompt and that's spawning potentially 10,000 sub-agents all doing their own thing, all calling tools and all calling services.
What Kind of Regulation Are We Dealing With?
Regulation. I'm not sure if I'm talking about this just because I'm European and Europeans love talking about regulation, but I do actually think it's going to be a very real problem that we'll be thinking about. We've been in this very weird place where there's been very little regulation given how consequential the technology is. There was the EU AI Act that was mainly drafted before GenAI. Then when GenAI hit, they were like, we don't want to stifle innovation too much, and so there's not really enforcement yet. They don't really know if they can enforce it. That's not pretty toothless for now. The U.S. had guidance that would have regulated or provided guidance on how to use GenAI, but then Trump explicitly excluded GenAI last year. The current regulation is pretty weak, and on the whole it's up to businesses and enterprises and people building use cases to figure out how to be responsible.
This is actually changing. I took this screenshot. I don't actually think this is any meaningful regulation, but it does seem like people are starting to not take this complete free-jump approach. As countries, and I would actually say the U.S. probably has more resistance than most countries or at least in Europe, we're already seeing very big resistance from the general population to AI. I found this very cute little girl who apparently really doesn't like data centers, and we're seeing this more and more. The average person is really not excited by AI. I'm sure a lot of people here are, because we're practitioners and we're very close to it, but the average person is not and they're getting less and less excited as time goes on. This is a Pew Research study. Currently 50% of Americans are more worried about AI than they are excited. Actually only 10% of Americans are more excited than they're worried.
The vast majority of Americans do not really want this thing or do not necessarily understand why it's a good idea. It makes sense why. It is really scary, and as an industry we don't help ourselves. We talk a lot about the end of times. I do really understand why it's very scary. I'm going to make a prediction. My prediction is that the 2028 U.S. election campaign is going to be largely dominated by anti-AI and anti-billionaire sentiment. I do think that the anti-AI sentiment is going to be very real. We've seen this already. Elizabeth Warren is talking about taxes on AI. Bernie Sanders announced that he wants to seize 50% of all of the major AI labs. This is not just a democratic issue as well. Orly, a Republican, and Ron DeSantis have both been very anti-AI as well. It seems to be one of the things that there's cross-all agreement on.
I think as we start seeing the impact of AI in our economy, and I don't think we've actually really seen any impact yet, this is going to get more and more intense. The timeline I'm predicting is that over the next couple years we're going to see more and more intense anti-AI, anti-data center campaigning. 2028 I think we can get an anti-AI candidate that wins. That means 2029 we'll be seeing new AI regulation. By the time we get here in 2030 we'll be talking about implementing that regulation as well. I think it will probably be regulation that is probably quite toothy and will impact the way that we're actually building. That's my prediction that I think we will increasingly be entering into a more AI hostile political environment. We've been pretty lucky with how un-hostile it's been over the last couple years.
What is a 'Good Software Engineer' in 2030?
The final thing I'm going to talk about is, what makes a good software engineer in 2030? How do the skill sets that we need change over the next couple years, and how we implement AI? I took this from I think it's softwareengineerscareerleveling.com or something like that. It talks about the different axes of what makes a good software engineer. There's a bunch of different axes. You can have technology. This is probably the main one that people think about before they get to management level. How good is your knowledge of the tech stack and tools. Like how talented a technologist are you? We talk about relationship with the team. Are you easy to work with? Are you not easy to work with? People like you. Talk about process. What is your engagement with the development process? How good are you at that? We talk about system. This one I think is particularly interesting.
What is your level of ownership over the system? The reason I think this one is particularly interesting is because software career leveling frameworks exist mainly as a retention tool. They exist mainly so that you're not going to go and leave. We really reward people who understand the system. Because it's very difficult to get new people to come in and understand the entire tech stack and build from there. We talk about how good your understanding is of overall systems. Then we talk about influence. This is when we talk about management as well. These are axes that we currently care about in software engineering. With different leveling and different skill sets, you'll be at different levels in this Pentagon. For example, if you are an engineering manager 6, you probably won't be that high in technology anymore, but you'll be pretty high in people and process. If you were a developer before, you might be a generalist everywhere.
Everyone has their own Pentagon. That largely decides where they are in the career leveling framework. I think that's really a good reason to say that most of these really change in importance in the AI era in pretty radical ways. I don't think knowledge of technology stacks really matter that much anymore or will continue to matter that much anymore for the majority of software engineers. I think there's some exceptions of when people are working in particular types of technology where that will change. I think on the whole, technology will be less important in 2030 than it is now. I think there's also a good reason to think that your relationship with your team might be less important as well or at least will change. What we've been seeing more and more is that people aren't necessarily working in a large team anymore to deliver complex software.
They're actually working with a lot of agents to deliver complex software. That we're seeing more and more people able to own entire projects by themselves. I think that relationship changes. The way we measure that changes. The process also changes somewhat as well. There's an argument to which you say that like the software development cycle exists largely because you have a lot of people going on. If you have AIs in that system, it's not clear how that changes as well. Level of ownership of the system I think is a really interesting one. I think that will become way less important in the new career leveling frameworks of the future. I think actually the difficulty of onboarding a new person onto a complex tech stack given they have AI tools becomes much easier. It's not as important to reward people for deep level of knowledge of your system.
I think influence could also change. Importantly, I think we're missing a very big thing here which is product. For a lot of organizations, you see product and engineering having slightly separate roles. I think product thinking, requirements gathering and understanding will become an increasingly large proportion of the software engineer role. Evidence to support that is the number of companies looking for product engineers has skyrocketed over the last year. I think we're going to see more and more expectation that everyone will be a product engineer. How we use AI I think also becomes a key part of leveling. I know that in a number of talks we've talked about tokenmaxxing, and should you tokenmax and what does that mean? I tend to agree with Erik the founder of Modal here when he talks about actually the thing that we want to max is this ratio of whatever the output you deliver is divided by the salary plus your token usage.
If you are able to maximize that ratio by using $20,000 worth of tokens a month, great. If you're able to max that by using $500, that's also great. I think we're going to be measured by this metric going forward as opposed to anything else. I think the things that will change when we think about what a good software engineer looks like going forward is I think deep technical skills matter less and less, and actually product, project management because your engineers will be required to deliver more and more complex projects, and requirement settings will become increasingly important skills. Kind of like being a conductor. We have engineers within our organization who simultaneously manage between 5 and 10 separate agents, and they're basically becoming team leads as individuals and they're becoming conductors. I think we'll see a lot more of this becoming the thing that we're measuring against. I predict that we'll have a talk titled something like, building software engineering career leveling frameworks when technical skills don't matter. It's a bit controversial as a title but gets people attending.
Recap
My predictions. Token spend will go up. It'll become a very big issue of how we manage it. We will have a lot more code and a lot more builders, and it's the job of IT to figure out how to provide them the framework so that doesn't turn into chaos. We're going to have agents making buying decisions with infrastructure, and I think that'll be an interesting question of how we manage that. We're going to be having very parallel agents and I think that will lead to a lot of infrastructure challenges that we will need to deal with. I think we will have a bunch new AI regulation and AI skeptic administrations. Finally, I think the definition of what a good software engineer looks like will change. I'll make one final prediction. The talk title was what we'll be talking about at QCon AI in 2030. Maybe I disagree with this talk title on the whole. I don't think there will be a QCon AI in 2030. I think we will just be at QCon, and I think this will just be part of all software engineering that we do.
See more presentations with transcripts
Recorded at:
Sep 05, 2026
by
Meryem Arik
Related Sponsors
This content is in the AI, ML & Data Engineering topic
Related Topics:
Development
Architecture & Design
AI, ML & Data Engineering
Governance
QCon AI Boston 2026
Patterns
QCon Software Development Conference
AI Architecture
Regulation
Transcripts
Enterprise Architecture
Technology Trends
Productivity
Government
Infrastructure
Agents
Architecture
InfoQ
Related Editorial
Popular across InfoQ
Kubernetes Promotes KYAML as a Safer, More Consistent Way to Work with Manifests
Airbnb Cuts Authentication Code by 60% with Server Driven Architecture
OpenClaw 2.0 Releases with Simplified Setup and Collaborative Agents
Google Mantis: an Agentic Vulnerability Scanning Harness for Reducing False Positives
Java News Roundup: TornadoVM 6, JReleaser, LangChain4j, Java Operator SDK, JHipster, Yupiik Fusion
Personality Over Skillset: How Adam Wachtel Builds Engineering Teams