Cubeia, a Swedish software firm, is undergoing a significant transformation as it advances to the third stage of AI-assisted development. The company has shifted from a flexible AI adoption approach for developers to a more structured AI-driven development process. This transition raises an essential question about how the organization can adapt when coding is no longer the primary limitation.
Stefan Grenstad, Cubeia's COO, emphasizes the company’s commitment to this AI-driven approach, stating, "We’re doing this 100%." With the enhanced capabilities brought by AI, the focus is now on optimizing how the organization uses this newfound capacity. Just six months prior, Cubeia primarily focused on replacing human-written code with AI-generated alternatives, but the scope has since broadened.
The company is now examining its overall development pipeline, the roles of developers and quality assurance (QA), the organization of teams, and its evolving relationship with customers.
In the first phase of this AI journey, Cubeia maintained an open approach, allowing developers to utilize AI tools at their discretion. The second phase introduced structure, aligning the team's use of AI-driven agents and ensuring that everyone worked through a unified pipeline. This shift demanded Cubeia address various challenges including quality, reliability, and employee acclimatization to the new workflows. Grenstad reports that the company has significantly improved its problem-solving capabilities during this transition.
During an initial hybrid phase in Q1, Cubeia resolved 259 issues. Following the adoption of the AI-driven process, this number surged to 421, a notable 62% increase. The size of larger projects also grew, from 17 to 58. "So the answer is yes: moving to AI-driven development has increased our output tremendously," Grenstad notes.
However, the more pressing question is how to utilize this increased output effectively. Grenstad reflects, "Because we’re not spending as much time coding, we’re spending more time on the business: talking about value and understanding the domain."
This approach requires teams to go beyond simply fulfilling requests; they must grasp the underlying reasons for their work and the value it aims to deliver. Paul Crisp, head of marketing at Cubeia, highlights the importance of measuring project objectives, providing an example: "If the objective is 10% more traffic, 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."
As Cubeia moves forward, it is increasingly influenced by customer demands. Grenstad notes the organization's shift in inquiry, asking clients what they wish to accomplish with AI. He recounts instances where customers expressed interest in using Cubeia’s data streams and platform functionalities to enhance their own offerings. One customer constructed a casino landing page utilizing Cubeia’s APIs, while another aimed to leverage Cubeia's player account management system for personalized bonuses.
This approach signifies less emphasis on providing another AI tool and more on ensuring Cubeia’s platform integrates seamlessly with existing customer AI infrastructures. The company is currently piloting initiatives based on these customer use cases.
The adjustments within Cubeia include a new organizational structure tailored to address customer demands. The company is testing a rapid-response team that focuses on smaller requests alongside a dedicated group for larger projects and strategic objectives. Currently, teams consist of five to eight members, although Grenstad envisions these groups could become even smaller in the future.
"In my dream, it would be two- or three-person teams," he shares. Developers now have the flexibility to shift between rapid-response and larger undertakings based on their interests and skills.
Despite the increase in capacity through AI, Cubeia has not completely eradicated bottlenecks, especially concerning task review. As AI agents generate multiple parallel workstreams, the challenge lies in managing individual workloads effectively. "The bottleneck becomes the person reviewing everything," Grenstad explains. While manual code review remains for critical components, the reliance on full manual checks has diminished.
This evolution in development practices also influences Cubeia's staffing strategy. With the necessity for traditional front-end Java developers lessening, Grenstad prioritizes candidates with domain knowledge over conventional technical qualifications.
Who will fill these roles is becoming an intriguing question, especially as traditional development pathways shift. Grenstad reassesses how to attract younger talent as the typical progression from junior to senior developer is no longer straightforward.
The organization is also moving away from a conventional development model where coding is followed by QA tests. Grenstad outlines a collaborative approach where QA is integrated throughout the development cycle, allowing product engineers to incorporate automated testing considerations early on. This paradigm shift extends responsibility from problem identification to encompassing the building process, quality assurance, and evaluating outcomes.
Cubeia’s transformation carries its share of challenges, including the adjustment of coders who previously thrived on writing code. Some employees find the reduced emphasis on coding difficult to accept as it alters a significant part of their work.
Concerns about reliance on AI service providers remain, with Grenstad pointing out potential issues that could arise if these providers alter pricing or service quality. Regardless, he views these uncertainties as learning opportunities for Cubeia as they adapt and evolve.
Reflecting on the initial phase of the AI journey, Grenstad recalls a straightforward vision: "When we started this journey, my only vision was: ‘Let’s not be writing code in August.’" The company aimed to eliminate code as a bottleneck in software development but soon realized that this change highlighted broader systemic constraints. Consequently, demands have shifted towards enhancing domain knowledge, improving product visioning, ensuring quality, and comprehending customer needs, making the technology itself a less central focus than how it is applied going forward.
