jili tutorial

Cubeia’s Road to AI-Assisted Code (Part Three): It’s No Longer About the Code

By jili tutorial · September 15, 2026

Cubeia’s Road to AI-Assisted Code (Part Three): It’s No Longer About the Code

Introduction: From Experiment to Organizational Transformation

When Swedish software company Cubeia first began exploring AI-assisted development, the goal was straightforward: replace human-written code with AI-generated code. That was six months ago. Today, the company has moved far beyond that initial experiment. Cubeia has entered what it calls the third phase of its AI journey—a phase where the technology itself is no longer the story. Instead, the focus has shifted to how the entire organization operates when coding is no longer the primary constraint.

“We’re doing this 100%,” says COO Stefan Grenstad, referring to Cubeia’s fully AI-driven development process. But the real question now isn’t about whether AI can write code. It’s about what Cubeia does with the additional capacity that AI has unlocked—and what that means for developers, quality assurance, team structure, customer relationships, and the future of work itself.

This article explores Cubeia’s journey through its three phases, the lessons learned, the bottlenecks that remain, and the strategic questions that lie ahead. It’s a case study in how one company is navigating the transition from AI as a tool to AI as a fundamental part of how work gets done—and the ripple effects that transition creates.

Phase One: Open Adoption

Letting Developers Experiment Freely

Cubeia’s first phase was deliberately unstructured. Developers were encouraged to use AI tools whenever and however they wanted. There were no mandates, no standardized processes, no company-wide guidelines. The goal was simple: let people explore what AI could do in their daily work.

This approach had several advantages. It generated enthusiasm and buy-in from developers who quickly discovered the power of AI for tasks like code generation, refactoring, debugging, and documentation. It also surfaced a wide range of use cases and potential pitfalls organically, without the need for top-down directives.

However, the open approach also had limitations. There was no consistency in how AI was used across teams. Some developers were heavy users; others barely touched it. There was no shared infrastructure for AI tools, no common prompt libraries, and no established patterns for integrating AI output into the development pipeline. Quality control was ad hoc, and results varied widely.

The Limitations of Chaos

While the experimental phase was valuable for exploration, it wasn’t scalable. Inconsistent usage made it difficult to measure impact. More importantly, Cubeia couldn’t guarantee the reliability of AI-generated code when every developer was doing something different. The company needed structure to move forward.

Phase Two: Building Structure

Standardizing the AI-Driven Pipeline

Phase two marked a significant shift. Cubeia moved from open experimentation to a structured, company-wide approach. Everyone now uses the same AI agents, works through the same AI-driven pipeline, and follows the same processes for integrating AI-generated code.

This standardization addressed the key challenges that emerged in phase one:

Grenstad notes that this phase required solving significant technical and organizational problems. How should agents work together? What should the human review process look like? How do you maintain quality when AI is generating a growing share of the codebase?

The Results: A 62% Increase in Output

The structured approach produced dramatic results. During the hybrid period in Q1 (when some work was still done traditionally), Cubeia solved 259 issues. Once the company moved to the fully AI-driven process, that figure rose to 421—a 62% increase. Larger projects increased from 17 to 58 during the same period.

“So the answer is yes: moving to AI-driven development has increased our output tremendously,” Grenstad says.

But increased output raises a more fundamental question: What do you do with all that extra capacity?

Phase Three: Beyond Coding

The Shift from Implementation to Value

The most important change in phase three is a philosophical one. Cubeia is no longer primarily focused on how to write code faster. Instead, the company is asking what it should do with the time and resources freed up by AI.

“Because we’re not spending as much time coding, we’re spending more time on the business: talking about value and understanding the domain,” Grenstad explains.

This represents a fundamental shift in the role of the development team. Rather than simply building what was requested, teams are now expected to understand why something is being built and what value it should create. This requires deeper engagement with business goals, customer needs, and domain expertise.

Measuring Outcomes, Not Outputs

Paul Crisp, Cubeia’s head of marketing, illustrates this shift with a concrete example. If the objective is a 10% increase in traffic, the team must establish a baseline, implement the change, measure the results, and verify whether the objective was met.

“If it only goes up by 1%, maybe we need another iteration because we haven’t fulfilled the objective,” Crisp says.

This outcome-oriented approach is a significant departure from traditional software development, where success was often measured by the number of features shipped or stories completed. At Cubeia, the measure of success is whether the business objective was achieved—and that requires a different set of skills and mindset.

Customer-Led Innovation: Saying “Yes” to AI Integration

When Customers Ask for More

The next evolution of Cubeia’s AI journey wasn’t planned internally—it was driven by customers. The company began asking, “What does this mean for the customer? What can the customer actually do with this?” But answers came faster than expected when customers approached Cubeia directly.

One customer built its own casino landing page and wanted to use Cubeia’s APIs to integrate it with the platform. Another wanted to leverage Cubeia’s player account management system to build bespoke functionality, including personalized bonuses.

“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?’” Grenstad recalls.

The Platform as an AI-Ready Infrastructure

The implication is significant. Cubeia’s role is no longer just to provide software solutions—it’s to make its platform and data accessible to AI infrastructure that customers are building themselves. This is a shift from being a software provider to being a data and platform enabler for AI-driven customer innovation.

Cubeia is now running a pilot based on the landing-page use case. Grenstad says this wasn’t on the horizon just six months ago, but he now 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,” he says.

Rethinking Team Structure

Rapid Response vs. Long-Term Projects

The increase in capacity is also changing how Cubeia organizes its development team. The company is experimenting with a two-team structure:

Currently, these teams have five and eight people respectively. But Grenstad believes they could eventually become much smaller—perhaps two or three people per team.

Flexibility and Movement Between Teams

Developers can move between the rapid-response and long-term project teams based on their interests and where they can contribute most effectively. This flexibility is a deliberate design choice, recognizing that different people thrive in different types of work—and that the skills needed for fast response are not always the same as those needed for deep, long-term development.

The New Bottleneck: Human Review

Too Much Output, Not Enough Oversight

With AI agents producing multiple streams of work in parallel, Cubeia is confronting a new challenge: managing the volume of output generated. The bottleneck is no longer writing code—it’s reviewing and validating what AI produces.

“The bottleneck becomes the person reviewing everything,” Grenstad explains.

However, this doesn’t mean every line of code gets the same level of scrutiny. Cubeia has adopted a risk-based approach:

This tiered approach allows Cubeia to maintain quality where it matters most while realizing the efficiency gains of AI-driven development.

Changing Hiring Priorities

Domain Knowledge Over Technical Specialization

The shift to AI-driven development is also changing what Cubeia values in new hires. Grenstad describes a team working on the player journey: it needs people who understand casinos, iGaming, and what a strong player experience looks like.

“I would not necessarily prioritise senior Java or front-end specialists in the same way as before,” he says.

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,” Grenstad says.

The Dilemma of the Junior Developer Path

This raises an uncomfortable question for the industry: If Cubeia no longer needs traditional junior Java developers in the same way, what happens to the pathway from junior programmer to senior engineer?

“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,” Grenstad says.

The issue is not just about hiring. It’s about succession planning and the future of the software development profession. If AI handles more of the coding work, what does the next generation of engineers learn? And how do they gain the deep technical expertise needed to oversee AI systems and address complex architectural problems?

The Evolving Role of Quality Assurance

From Gatekeeper to Embedded Partner

Cubeia is also moving away from the traditional model in which developers build something and then hand it off to QA for testing. In the old model, the product owner decided what to build, developers decided how to build it, QA tested it, and operations handled the release.

That has changed dramatically. As discussed in the previous part of this series, QA has become part of the development process rather than a final gate:

This is a more integrated, collaborative approach that recognizes the blurred boundaries between development and quality.

The Human Cost of Transformation

Missing the Craft of Coding

Not everyone at Cubeia is thriving in the new environment. Grenstad is candid about the challenges:

“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.”

This is a real human cost of AI-driven development. The craft of coding—the joy of solving a complex problem, the satisfaction of elegant design—is being displaced by a different kind of work. For some, that’s an exciting opportunity. For others, it’s a loss.

Organizations undergoing this transition need to acknowledge this reality and find ways to support people through the change. Not everyone will adapt seamlessly.

Strategic Concerns: Dependence on AI Providers

The Risk of Vendor Lock-In

Cubeia is currently heavily reliant on Claude (the AI model family developed by Anthropic). Grenstad acknowledges this dependency and raises important strategic questions:

These are concerns without easy answers. For now, 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.”

The Journey Forward

From “Let’s Not Write Code in August” to Something Bigger

When Cubeia began this journey, the vision was modest: “Let’s not be writing code in August,” Grenstad recalls.

That vision has been exceeded. Cubeia set out to remove coding as the primary constraint on software development. In doing so, it discovered that coding was only one constraint in a much larger system.

As the bottleneck moves, so do the demands on the organization:

The Technology Recedes; The Organization Advances

The technology itself has become less important to the story. What Cubeia does with the technology moving forward has become the focal point.

This is the ultimate lesson of Cubeia’s journey: AI doesn’t just change how software is built. It changes what software teams are for. And that, in turn, changes everything about how the organization works.

The questions Cubeia is now grappling with—How should teams be structured? What skills should we hire for? How do we review AI output? What do we do with our customers when they bring AI solutions to us?—are questions that every software-driven company will eventually need to answer.

Cubeia is working through them now. The answers may not be complete, but the direction is clear: AI-driven development isn’t just about faster coding. It’s about fundamentally rethinking what it means to be a software company in an age when software is increasingly written by machines.

The road ahead is uncertain, but Grenstad remains optimistic: “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.”