AI驱动开发：Cubeia的组织变革之路
瑞典软件公司Cubeia在AI辅助开发之旅中已迈入第三阶段。公司从最初允许开发者自由采用AI，发展到如今构建结构化的AI驱动开发流程。现在，他们面临一个更深层次的问题：当编写代码不再是主要制约因素时，整个组织应该如何运作？Cubeia首席运营官Stefan Grenstad明确表示，公司已100%采用AI驱动开发流程。目前，焦点已转向如何充分利用AI所创造的额外产能。
从代码替代到全面流程再造：AI效率提升显著
六个月前，Cubeia的实验主要集中于用AI生成的代码替代人工编写。自那时起，这一进程已演变为更广泛的变革：它带来了全新的开发管道、开发者与质量保证（QA）部门角色的转变、团队组织方式的革新，以及日益紧密的客户关系。Cubeia的第一阶段是开放式AI应用，开发者可按需使用。第二阶段则引入了结构化流程，所有员工使用相同的AI代理，并遵循统一的AI驱动管道。这要求Cubeia解决质量、可靠性以及AI代理协同工作等问题，同时帮助员工适应新的工作模式。Grenstad认为，这项工作已基本完成。
“在第一季度的混合模式期间，Cubeia解决了259个问题。一旦转向AI驱动流程，这一数字飙升至421个，增长了62%。大型项目也从17个增至58个。因此，答案是肯定的：转向AI驱动开发极大地提升了我们的产出。”Grenstad说道。
重心转移：深挖业务价值与客户需求
然而，现在更重要的问题是Cubeia如何利用这些新增的产能。“因为我们不再花费大量时间编写代码，所以我们有更多时间投入到业务中：讨论价值并理解领域。”Grenstad解释。团队不再仅仅是按要求构建产品，而是日益被期望理解构建某项功能的深层原因及其应创造的价值。正如Cubeia市场总监Paul Crisp所指出的：“如果目标是增加10%的流量，我们如何衡量？我们需要建立基线，实施变更，进行测量，并观察是否达到10%的增长。如果只增长了1%，可能我们需要进行另一次迭代，因为我们尚未实现目标。”
客户主导：开放平台赋能AI创新
Cubeia的下一步发展正日益由客户驱动。Grenstad解释，公司现在开始思考客户希望用AI做什么。“我们最近开始问，‘这对客户意味着什么？客户究竟能用这个做什么？’我认为，如果不是客户主动找上门说：‘我们能否让自己的AI代理处理你们的数据流并使用你们的平台？’我们可能还会继续寻找这个答案。”
Grenstad回忆道，一位客户构建了自己的赌场落地页，并希望使用Cubeia的API使其与平台协同工作。另一位客户则希望利用Cubeia的玩家账户管理系统来构建自己的功能，包括个性化奖金。其核心理念并非Cubeia提供另一个AI工具，而是让其平台和数据对客户已在构建的AI基础设施开放。Cubeia目前正基于落地页的用例运行一个试点项目。Grenstad表示，这在六个月前可能还不在计划之内，但他现在相信Cubeia最终应该能够对客户使用自有AI工具构建的产品“说好”。“我们已经意识到，我们将成为其中的一部分。”Grenstad说。
团队重塑：敏捷响应与瓶颈转移
产能的提升也正在改变Cubeia的开发团队组织方式。公司正在尝试设立一个专注于小型客户请求和突发事件的快速响应团队，以及另一个负责大型项目和长期路线图的团队。目前的团队规模分别为5人和8人，但Grenstad认为它们最终可能会变得更小。“在我的梦想中，团队将是两三人。”他说。开发者也可以根据自己的兴趣和最能有效贡献的领域，在快速响应项目和长期项目之间流动。
然而，产能增加并非意味着Cubeia消除了所有瓶颈。随着AI代理并行生成多条工作流，公司仍在努力寻找个人能够管理和审查的工作量的最佳平衡点。“瓶颈变成了审查一切的人。这并不意味着我们从不审查代码本身。对于系统中敏感或关键的部分，我们仍然会更仔细地审视实现，特别是在架构、性能、安全和可靠性方面。但我们不再对所有内容都进行这种程度的手动代码审查。”Grenstad表示。
招聘策略变革：领域知识优先于纯技术
向AI的转变也正在改变Grenstad对招聘的看法。例如，一个负责玩家旅程的团队需要理解赌场、iGaming以及优秀玩家体验的人才。“我不会像以前那样，优先考虑高级Java或前端专家。”Grenstad解释道。“技术技能仍然很重要，特别是对于那些能够评估架构并确保系统保持可靠性的人员，但领域知识正变得越来越有价值。我宁愿选择一个在领域内表现出色但不懂Java的人。”
这引发了一个关于未来开发者如何进入行业的问题。如果Cubeia不再以同样的方式需要传统的前端或初级Java开发者，那么从初级程序员到高级工程师的传统路径就变得不那么清晰了。“我们如何避免最终出现大量‘老Java开发者’，却没有人理解Java，因为初级开发者从未被雇佣？这是一个超级有趣的问题。我们如何随着时间的推移补充年轻人才？这是我们一直在讨论的问题。”
QA角色演变与转型挑战
Cubeia也正在摆脱传统的开发流程，即开发者构建产品，然后将其移交给QA。Grenstad表示，在旧模式中，产品负责人决定构建什么，开发者决定如何构建，QA进行测试，最终由运维处理发布。正如上个月讨论的，QA已成为流程的一部分，而非最终阶段。产品工程师从规划阶段就开始考虑哪些可以自动化，哪些需要手动测试，而QA专家现在则负责强化自动化并识别覆盖范围的空白。对一项工作的责任日益从识别问题延伸到构建、发布和衡量结果。
这场转型并未消除Cubeia所有的担忧。不可避免地，一些编码人员怀念他们最初的角色。“我们仍然有一些人热爱编码部分——用代码解决问题，编写优美的代码。他们正在与这种变化作斗争。对于一些人来说，他们真正热爱的工作中一个重要部分现在已经消失了。”此外，还存在关于对AI供应商依赖的战略性问题。Cubeia目前严重依赖Claude，Grenstad质疑如果AI供应商提高价格或改变质量会发生什么。然而，目前Grenstad将这种不确定性视为Cubeia可以学会管理的事情。“我们相信，这些问号将在我们解决它们的过程中得到解答。我们会看到问题，学会如何管理它们，并进行适应。”
超越代码：聚焦技术应用与未来发展
当Cubeia开始他们的AI之旅时，目标很简单。“当我们开始这段旅程时，我唯一的愿景是：‘八月我们不再写代码。’”Grenstad说。Cubeia旨在消除代码作为软件开发的制约因素，但在这样做的过程中，公司发现代码只是一个更大系统中的一个制约因素。随着瓶颈的转移，对组织的要求也随之变化：转向领域知识、产品思维、质量、优先级排序以及对客户需求的理解。因此，技术本身在故事中的重要性反而下降了。Cubeia如何利用这项技术向前发展，成为了新的焦点。