Swedish software company Cubeia’s journey towards AI-assisted development has entered its third phase as the company has moved from allowing developers to adopt AI as they see fit, to building a structured AI-driven development process.

It now faces a broader question: how should the organisation work when coding is no longer the main constraint?

“We’re doing this 100%,” COO Stefan Grenstad says of Cubeia’s AI-driven development process.

Now, the focus is on what the company does with the additional capacity AI has created. Six months ago, Cubeia’s experiment was essentially about replacing human-written code with AI-generated code.

Since then, it has evolved into something broader: a different development pipeline, a different role for developers and quality assurance (QA), a different way of organising teams and, increasingly, a different relationship with customers.

Creating business value

Cubeia’s first phase was an open approach to AI. Developers could use it whenever they wanted. Phase two brought structure, with everyone using the same agents and working through the same AI-driven pipeline. That required Cubeia to solve questions around quality, reliability and how agents could work together, while getting employees comfortable with the new way of working. Grenstad believes that work has largely been completed.

“During the hybrid period in Q1, Cubeia solved 259 issues. Once it moved to the AI-driven process, that figure rose to 421 – a 62% increase. Larger projects increased from 17 to 58. So the answer is yes: moving to AI-driven development has increased our output tremendously,” Grenstad says.

But the more important question now is what Cubeia does with that capacity. “Because we’re not spending as much time coding, we’re spending more time on the business: talking about value and understanding the domain,” he says.

Rather than simply building what is requested, teams are increasingly expected to understand why something is being built and what value it should create.

As Paul Crisp, Cubeia’s head of marketing, points out: “If the objective is 10% more traffic, for example, how do we measure it?

“We need to establish a baseline, implement the change, measure it and see whether it goes up by 10%. If it only goes up by 1%, maybe we need another iteration because we haven’t fulfilled the objective.”

‘Say yes‘

The next development is increasingly being driven by Cubeia’s customers. Now the company is asking what customers will want to do with AI, Grenstad explains.

“We [recently] started asking, ‘What does this mean for the customer? What can the customer actually do with this?’ And I think we would have continued looking for that answer if the customer hadn’t come to us and said: ‘Can we let our AI agent deal with your data streams and use your platform?'”

One customer built its own casino landing page and wanted to use Cubeia’s APIs to make it work with the platform. “Another wanted to use Cubeia’s player account management system to build its own functionality, including personalised bonuses,” Grenstad recalls.

The idea is less about Cubeia providing another AI tool than making its platform and data accessible to AI infrastructure customers are already building themselves. Cubeia is now running a pilot based on the landing-page use case.

This was not necessarily on the horizon just six months ago, Grenstad says, but now he believes Cubeia should ultimately be able to “say yes” when customers arrive with products built using their own AI tools.

“We’ve realised we’re going to be part of it,” Grenstad says.

A different development structure

The increase in capacity is also changing how Cubeia organises its development team. The company is experimenting with a rapid-response team focused on smaller customer requests and incidents, alongside another team working on larger projects and the longer-term roadmap.

The current teams have five and eight people, but Grenstad believes they could eventually become much smaller.

“In my dream, it would be two- or three-person teams,” he says.

Developers can also move between rapid-response and longer-term projects depending on their interests and where they can contribute most effectively.

But more capacity does not mean Cubeia has eliminated bottlenecks. With AI agents producing several streams of work in parallel, the company is still trying to find the right balance of how much work an individual can manage and review.

“The bottleneck becomes the person reviewing everything. That does not mean we never review the code itself. For sensitive or critical parts of the system, we still look more closely at the implementation, particularly from an architecture, performance, security and reliability perspective. But we no longer apply that level of manual code review to everything.” Grenstad says.

The shift to AI is also changing how Grenstad thinks about recruitment. A team working on the player journey, for example, needs people who understand casinos, iGaming and what a strong player experience should look like.

“I would not necessarily prioritise senior Java or front-end specialists in the same way as before,” Grenstad explains. “Technical skills remain important, particularly for people who can assess architecture and ensure systems remain reliable, but domain knowledge is becoming increasingly valuable. I’d rather take someone who’s good in the domain but doesn’t know any Java.”

That raises a question about how future developers will enter the industry. If Cubeia no longer needs front-end traditional junior Java developers in the same way, the traditional path from junior programmer to senior engineer becomes less clear.

“How do we avoid ending up with lots of old Java developers and nobody who understands Java because the juniors were never hired? That’s a super-interesting question. How do we fill up with younger people over time? That’s something we’ve been discussing.”

Big changes and unknowns

Cubeia is also moving away from the traditional process in which a developer builds something and then hands it to QA.

In the old model, Grenstad says, the product owner decided what to build, the developer decided how to build it, QA tested it and operations eventually handled the release.

As discussed last month, QA has become part of the process rather than a final stage. Product engineers consider from the planning stage what can be automated and what needs manual testing, while QA specialists now strengthen automation and identify gaps in coverage.

The responsibility for a piece of work increasingly extends from identifying the problem to building, releasing and measuring the result.

The transformation has not eliminated all of Cubeia’s concerns. And inevitably some coders are missing their original role.

“We still have people who loved the coding part – solving problems with code and writing beautiful code. They’re struggling with the change. For some people an important part of their work that they genuinely loved is now gone.”

There are also strategic questions around dependence on AI providers.

Cubeia is currently heavily reliant on Claude, and Grenstad questions what could happen if AI providers raise prices or if quality changes. For now, however, Grenstad sees the uncertainty as something Cubeia can learn to manage.

“We’re confident that the question marks will be solved as we work through them. We’ll see the problems, learn how to manage them, and adapt.”

Sharing the journey

When Cubeia began their AI-journey, the objective was simple.

“When we started this journey, my only vision was: ‘Let’s not be writing code in August,’” Grenstad says.

Cubeia set out to remove coding as the constraint on software development, but in doing so, the company has discovered that coding was only one constraint in a much larger system. As the bottleneck moves, so do the demands on the organisation: towards domain knowledge, product thinking, quality, prioritisation and understanding what customers need.

The technology itself has therefore become less important to the story.

What Cubeia does with the technology moving forward has become the focal point.

瑞典软件公司Cubeia在AI辅助开发的道路上已进入第三阶段,从允许开发者自行决定是否采用AI,转向构建一套结构化的AI驱动开发流程。

如今,它面临一个更广泛的问题:当编码不再是主要瓶颈时,组织应如何运作?

“我们正在100%推进这件事,”COO Stefan Grenstad在谈及Cubeia的AI驱动开发流程时表示。

现在,焦点在于公司如何利用AI所创造的额外产能。六个月前,Cubeia的实验本质上是用AI生成的代码替代人工编写的代码。

此后,它已演变为更广泛的东西:不同的开发流水线、开发者与质量保证(QA)的不同角色、不同的团队组织方式,以及与客户日益不同的关系。

创造商业价值

Cubeia的第一阶段是对AI采取开放态度。开发者可以随时使用它。第二阶段引入了结构,所有人都使用相同的智能体,并通过相同的AI驱动流水线工作。这要求Cubeia解决质量、可靠性以及智能体如何协同工作等问题,同时让员工适应新的工作方式。Grenstad认为这项工作已基本完成。

“在第一季度的混合期间,Cubeia解决了259个问题。转向AI驱动流程后,这一数字上升至421个——增长了62%。大型项目从17个增加到58个。所以答案是肯定的:转向AI驱动开发极大地提升了我们的产出,”Grenstad表示。

但如今更重要的问题是Cubeia如何利用这些产能。“因为我们花在编码上的时间减少了,我们把更多时间投入到业务上:讨论价值、理解领域,”他说。

团队不再只是简单地构建所要求的东西,而是越来越多地被期望理解为什么要构建某个东西,以及它应该创造什么价值。

正如Cubeia市场负责人Paul Crisp所指出的:“例如,如果目标是流量增加10%,我们如何衡量它?

“我们需要建立一个基线,实施变更,进行衡量,看看它是否上升了10%。如果只上升了1%,也许我们需要再迭代一次,因为我们没有实现目标。”

‘说可以‘

接下来的发展越来越多地由Cubeia的客户推动。Grenstad解释说,公司现在正在询问客户希望用AI做什么。

“我们[最近]开始问,‘这对客户意味着什么?客户实际上能用这个做什么?’我认为如果客户没有来找我们说:‘我们能不能让我们的AI智能体处理你们的数据流并使用你们的平台?’我们可能还会继续寻找答案。”

一位客户构建了自己的赌场落地页,并希望使用Cubeia的API使其与平台协同工作。“另一位客户希望使用Cubeia的玩家账户管理系统来构建自己的功能,包括个性化奖金,”Grenstad回忆道。

这个想法与其说是Cubeia提供另一个AI工具,不如说是让其平台和数据对客户已经在自行构建的AI基础设施开放。Cubeia目前正在基于落地页用例开展试点。

Grenstad表示,这在六个月前未必在视野之内,但现在他认为,当客户带着用自己AI工具构建的产品到来时,Cubeia最终应该能够“说可以”。

“我们已经意识到,我们将成为其中的一部分,”Grenstad说。

不同的开发结构

产能的增加也在改变Cubeia组织开发团队的方式。公司正在试验一个快速响应团队,专注于较小的客户请求和事件,同时另一个团队负责大型项目和长期路线图。

目前的团队分别有五人和八人,但Grenstad认为它们最终可能会变得小得多。

“在我的设想中,会是两到三人的团队,”他说。

开发者还可以根据自己的兴趣和最能有效贡献的领域,在快速响应和长期项目之间流动。

但更多产能并不意味着Cubeia已经消除了瓶颈。由于AI智能体并行产出多条工作流,公司仍在努力寻找个人能够管理和审查多少工作的合适平衡点。

“瓶颈变成了审查一切的人。这并不意味着我们从不审查代码本身。对于系统的敏感或关键部分,我们仍会更仔细地审视实现,特别是从架构、性能、安全和可靠性角度。但我们不再对所有内容都应用那种级别的人工代码审查。”Grenstad说。

向AI的转变也在改变Grenstad对招聘的思考。例如,一个负责玩家旅程的团队需要了解赌场、iGaming以及优秀玩家体验应该是什么样的人。

“我不一定会像以前那样优先考虑资深Java或前端专家,”Grenstad解释道。“技术技能仍然重要,特别是对于能够评估架构并确保系统保持可靠的人,但领域知识正变得越来越有价值。我宁愿要一个在领域方面很擅长但完全不懂Java的人。”

这引发了一个问题:未来的开发者将如何进入这个行业。如果Cubeia不再以同样的方式需要前端传统初级Java开发者,那么从初级程序员到高级工程师的传统路径就变得不那么清晰了。

“我们如何避免最终变成有很多年老的Java开发者,却没有人真正理解Java,因为初级员工从未被雇用?这是一个非常有趣的问题。我们如何随着时间推移补充年轻人?这是我们一直在讨论的事情。”

巨大变化与未知数

Cubeia也在摆脱开发者构建某样东西然后交给QA的传统流程。

Grenstad说,在旧模式中,产品负责人决定构建什么,开发者决定如何构建,QA进行测试,运营最终处理发布。

正如上个月所讨论的,QA已成为流程的一部分,而不是最后阶段。产品工程师从规划阶段就考虑哪些可以自动化、哪些需要人工测试,而QA专家现在则加强自动化并识别覆盖缺口。

一项工作的责任越来越多地从识别问题延伸到构建、发布和衡量结果。

这一转型并未消除Cubeia的所有担忧。不可避免地,一些程序员怀念他们原来的角色。

“我们仍然有一些热爱编码部分的人——用代码解决问题、编写漂亮的代码。他们正在艰难应对这种变化。对一些人来说,他们真正热爱的工作中重要的一部分现在已经消失了。”

此外还存在围绕对AI供应商依赖的战略问题。

Cubeia目前严重依赖Claude,Grenstad质疑如果AI供应商提高价格或质量发生变化会发生什么。不过就目前而言,Grenstad认为这种不确定性是Cubeia可以学会管理的事情。

“我们相信,随着我们逐步解决,这些问号都会被解开。我们会看到问题,学会如何管理它们,并适应。”

分享这段旅程

当Cubeia开始他们的AI之旅时,目标很简单。

“当我们开始这段旅程时,我唯一的愿景是:‘让我们在八月份不再写代码,’”Grenstad说。

Cubeia着手消除编码作为软件开发瓶颈的问题,但在此过程中,公司发现编码只是一个更大系统中的瓶颈之一。随着瓶颈的转移,对组织的要求也随之转移:转向领域知识、产品思维、质量、优先级排序以及理解客户需求。

因此,技术本身在这个故事中已变得不那么重要。

Cubeia未来如何利用这项技术已成为焦点。