AI-Assisted Development at Cubeia: What Changed When Code Stopped Being the Bottleneck
Cubeia now resolves 62% more development issues per period than it did before moving fully to AI-assisted development, and the harder change wasn’t the code, it was everything built around it.
That’s the short version. The longer version, which our COO Stefan Grenstad has been candid about in the third part of our AI-development series, is that once coding stops being the constraint, a lot of other assumptions about how a software team works stop holding up too.
Here’s what actually changed, what the numbers show, and what we’re still figuring out.
What “going all-in” on AI-assisted development actually means
Cubeia’s shift happened in three stages, not one big switch:
Phase 1 — unrestricted adoption. Developers were free to use AI tools however worked for them, with no fixed process.
Phase 2 — structure. As usage matured, we moved to a more consistent process built around unified agents, so AI-assisted development stopped being an individual habit and became a team-wide way of working.
Phase 3 — organizational change. This is where we are now: treating AI-assisted development as an organizational question, not a tooling one. As Grenstad puts it, “We’re doing this 100%” – the point isn’t dabbling, it’s committing and then working out what that commitment actually requires from the business around it.
The numbers: issue throughput and project volume
The answer: AI-assisted development measurably increased Cubeia’s output. During the hybrid period (part-manual, part-AI-assisted), the team resolved 259 issues. After the transition, that rose to 421 issues in the same period, a 62% increase. Over the same window, the number of larger projects in progress went from 17 to 58.
The evidence: those figures come directly from Cubeia’s internal tracking across the transition period, reported in our AI-development series.
The context: more throughput doesn’t automatically mean better output, and we’ve been careful not to treat the numbers as the whole story. What they do show is that the constraint has moved, from “how fast can we write code” to something further upstream.
How the team is actually structured now
The bigger change has been organizational, not technical:
- Two team shapes, one purpose. A five-person rapid-response team handles incoming customer requests, while an eight-person team runs longer-term projects. Coding speed made both viable at once.
- Selective code review. Critical systems still get detailed, line-by-line review. Lower-risk changes get a lighter, faster pass. Not every line gets, or needs, the same scrutiny.
- Movement between teams. Developers move between rapid-response and long-term project work based on interest, not just headcount need. Something that’s easier to support once individual coding throughput isn’t the bottleneck.
- Less code, more domain knowledge. The skill that matters most has shifted from writing code quickly to understanding the business problem well enough to direct AI toward the right solution.
What we’re rethinking: hiring and the junior developer path
This is the part of the story without a tidy answer yet. When entry-level coding tasks are increasingly handled by AI, the traditional path – junior developer writes code, learns the codebase, grows into more senior work – gets harder to define.
Cubeia’s recruitment focus has shifted accordingly: toward people who understand the business and the domain deeply, rather than purely toward traditional junior coding roles. We don’t think this problem is solved industry-wide, and we’re not claiming Cubeia has solved it either. It’s an open question we’re actively working through, not a settled policy.
The trade-offs we’re watching
Two honest risks worth naming:
Concentration risk. Cubeia’s AI-assisted development pipeline currently relies heavily on Claude. That’s a deliberate choice, but it also means pricing changes or quality shifts from a single provider have an outsized effect on how the team works, something we’re monitoring rather than ignoring.
The org-design question is bigger than the tooling question. The headline lesson from this phase of Cubeia’s journey: adopting AI-assisted development tools is the easy part. The harder, ongoing work is deciding how a company should be structured, who it should hire, and how it interacts with customers once coding is no longer the primary bottleneck.
FAQ
What does “AI-assisted development” mean at Cubeia?
It means AI tools are the default way code gets written across the team, built around a structured, agent-based process, not an optional add-on individual developers can choose to skip.
Did AI adoption actually increase Cubeia’s development output?
Yes. Issue resolution rose 62% (from 259 to 421 issues in a comparable period) and the number of larger active projects rose from 17 to 58.
Are junior developers still part of Cubeia’s hiring plans?
The traditional junior-developer path is genuinely in flux industry-wide, and Cubeia is no exception. Our hiring focus has shifted toward domain and business expertise; we’re still working out what that means for early-career hiring long-term.
What risks come with relying heavily on one AI provider?
Mainly pricing and quality volatility. Cubeia’s pipeline currently depends heavily on Claude, and we’re deliberately monitoring that concentration rather than treating it as a solved problem.
Read more
This post is part three of Cubeia’s AI-development series. Read the full original coverage on iGaming Business: “Cubeia: Road to AI-assisted code, it’s not about the code”.
Read part one and two here: Cubeias road to AI assisted code – part 1
Cubeias Road to AI assisted code – part 2.