When your technology project matters most, choose experience.

From one talk to the next, the same message kept coming up: with artificial intelligence, organizations need to see early results within weeks, a few months at most. We're no longer talking about years to calculate the ROI of AI initiatives.

The software development model is undergoing a profound shift. Teams are getting smaller, agents are producing code autonomously, and the human role is evolving: people define the objectives guide the work and verify the outcome.

It's a transformation we're experiencing at Spiria. And we keep asking ourselves: how can we move fast without losing control?

ALL IN confirmed that we're heading in the right direction.

When Is It Good Enough?

With AI, getting a working prototype has never been faster. We can now be agile to the extreme.

But "it works" doesn't mean "it's ready." When agents generate in a single day what once took weeks, it becomes easy to mistake a prototype for a complete, ready-to-use software.

So, what needs to be confirmed and what needs to be true before we can say a solution is solid enough?

To answer that, we have to think about what comes after the prototype.

The first challenge is often a hidden long-term cost: maintenance, support and reliability.

If the foundations aren't solid enough, these costs won't be our only concern. We also risk delivering lower-quality software. And low-quality software often brings an array of potential security vulnerabilities.  

So, we need to adjust our processes to maintain this speed while drawing on the strength of the team. The right expertise has to come in at the right time, before deployment. Architecture, security, quality, and user experience need to enter the loop before the prototype becomes the foundation of a product. Because "good enough" software must be well coded, but above all, it must solve your users' needs.

We don't have the perfect recipe, but for us, the finish line doesn't change. It's how we get there that's changing completely.

Governance as an Accelerator

Governance is often associated with slowness and cumbersome processes. With agentic AI, it can instead become an accelerator: the key to moving faster. At ALL IN, one speaker summed it up this way: it's not governance that slows AI down, it's the lack of it. Without a framework, the speed gained upfront is lost to rework, uncertainty and, above all, a loss of trust.

And even if we're moving faster, we need to be moving in the right direction. A phrase from another talk, "systems over prompting," captures where we need to focus our efforts. Performance doesn't come from the quality of a single prompt. It comes from the system the agent works within: clear conventions, tests and well-defined validation steps. Governance is that framework. It's what allows agents to move fast without drifting off course.

Accountability Remains Human

An agent can produce code, but it can't be held accountable for it. In a software project, trust ultimately rests with the professionals who build the product. In operations, we know this well: when several people are responsible for something, no one really is. That's why every agent must have a named owner: one person, not a team. And because every piece of software we deliver is custom-built, someone on each project must also validate what the agent produces and be able to answer for it to the client. Deliver, operate, defend.

This principle goes beyond code and also applies to our role as managers. Don't be tempted to hand off to AI the hard things we should be doing human to human, like replacing a delicate discussion with a well-crafted email. One speaker even described it as a kind of leadership atrophy. There are tasks, conversations and moments that should remain human. AI can help us prepare for them. But it should never have a difficult conversation on our behalf.

Moving Forward with Confidence

Speed is new to the equation. Accountability remains as important as before. The organizations that get real value from agentic AI will be those that can accelerate while staying in control of what they build, deliver and operate.

Want a hand using AI with confidence in your software projects? Let's talk.

Software, a critical capability in defence

Defence is often pictured through its physical equipment, yet a decisive part of the sector now rests on software, systems integration, data and the experience of the people using it in the field. That shifts where the risk sits, since a system's value depends directly on the quality of its software design and on its ability to be deployed and used in real conditions.

This also explains the growing place of expertise from other sectors in this field. In defence, dual-use usually refers to a civilian technology repurposed for military use, and the same logic applies to know-how, since interface design, software architecture, cybersecurity and complex systems integration are all directly applicable capabilities, provided they are delivered to defence's level of demand.

Software skills from the commercial sector have their place in defence

In defence, a software's quality can matter as much as its features, particularly its reliability and ease of use in the field. The skills that make this possible, such as UX/UI design, mobile development and security management, were often developed in the commercial sector before finding their use in defence.

The NORTAC Orion application, built for Nortac Defence, is a concrete example, since it turns a smartphone into a tracking, encrypted-messaging and emergency-alert system that works even offline. The project brought together requirements typical of defence, namely communications security, offline reliability and near-real-time performance, met with mobile expertise from the commercial sector.

In this market, relationships and knowledge of the ecosystem matter as much as technical expertise, since they shape access to opportunities and shorten often lengthy cycles. It is a space built over time, through industry gatherings and relationships with prime contractors, where Spiria has been active for several years, notably through CADSI.

‍

What delivering in defence really demands

Beyond technical skill, this market adds a layer of requirements a company has to fully absorb, because protecting sensitive information reshapes how software is designed, hosted and delivered. On the cybersecurity side, a mature software company already applies most of the expected standards, such as SOC 2 or the CPCSC that is gradually working its way into defence contracts.

The most often underestimated factor sits on the physical security side, since access to premises, permitted devices, the work environment and even the network can all be controlled. These requirements take time and investment, and a credible partner anticipates them rather than having to build that capability under pressure once a mandate has been awarded.

‍

Certifications, explained simply

Certification requirements are another source of complexity, because people often assume there is a single, universal accreditation that would open every door. The reality is more nuanced, since requirements depend on the mandate and the information involved, and three main mechanisms coexist in Canada. The point is twofold, to understand what a mandate may require, then to verify what a partner actually holds.

• Controlled Goods Program (CGP): it governs examining, possessing or transferring controlled goods and technologies, and becomes necessary when a mandate involves such goods or tender documents that contain them.
  

• Security clearances (Contract Security Program): they grant access to protected or classified information, assets or sites, depending on the level the contract requires, from Reliability Status up to Top Secret.
  

• CPCSC (Canadian Program for Cyber Security Certification): it attests that cybersecurity controls match the contract's risk, and it is gradually appearing in defence tenders, with a level 1 in force since 2026.

Above all, keep in mind that these mechanisms are distinct and that a single mandate may call for one, several or none. A good partner helps you open the right doors at the right time, those that match the type of mandate in view, rather than piling up accreditations unrelated to your needs.

‍

What distinguishes a credible supplier in defence

If you are assessing a partner for a software project in a defence environment, a few concrete criteria quickly tell a credible supplier apart.

• Real experience in a critical or regulated context. Which comparable projects have been delivered, and with what results?

• Demonstrable cybersecurity maturity. Can the supplier provide a current attestation, for example SOC 2 Type 2, and its evidence of controls?
  

• The ability to add the right controls for the mandate. How does it adapt the CGP, security clearances and the CPCSC to the contract's risk?
  

• A command of physical security and field constraints. How does it protect sensitive information in its premises and work environments?
  

• A real presence in the defence ecosystem. Is it active and recognized among the sector's prime contractors and buyers?

These criteria hold as much for a defence project as for any other critical environment, which is also why expertise proven in one sector often transfers to another. One principle sums up entering this market well, namely that certifications can make you eligible, while relationships make you visible.

‍

In summary

Entering a defence project is prepared with method rather than with a race for accreditations. Requirements vary by mandate, cybersecurity and physical security alike are verified through concrete evidence, and knowledge of the ecosystem weighs as much as certifications. The essence comes down to a simple idea: assess a supplier on its real experience and its ability to prove its controls and add the right ones at the right time, rather than on the number of its accreditations.

If you are preparing a software project in a demanding environment and looking for a partner able to deliver at that level, let's talk.

The Same Script, Told Again and Again

By the end of the first day of ALL IN, I noticed that speakers had started to repeat each other. Whatever the panel, the message was some version of "AI is urgent, it will change everything, and we need to retain our sovereignty."

At first, I thought the problem was me. I'm a software developer at heart, so maybe my appetite was just to hear about code and see it in action. The more I listened, though, the clearer it became that I wasn't missing technical depth so much as lived experience. Almost nobody explained how AI had changed their own organization. Every news outlet already tells us AI is the next big thing, so a room full of practitioners should be able to tell us something the headlines can't. Where did you start? What did you try? What worked, what failed, and what would you do differently if you started over tomorrow? I heard almost none of that.

Instead, a large share of the programme went to investment, governance and data sovereignty. Those topics matter, and some of those conversations were excellent, but they stay high up. They tell you where the money is going, and very little about what happens when a team sits down and tries to use the technology.

‍

Sovereignty is not residency

Some panellists did say things every executive should hear, and it was good to hear this one said out loud: data sovereignty is not the same as data residency.

Many people still mix up the two. A provider tells you your data sits in a Canadian data centre, and that feels like control, but where your data is stored doesn't decide who can reach it or what happens to it. Canadian lawyers and infrastructure providers have warned that data held by a foreign-owned provider can still fall under that provider's home-country laws. The best-known example is the U.S. CLOUD Act, which can apply even when the servers are in Canada.

AI adds another layer that is easy to miss. Real sovereignty also means controlling how the AI services you use treat your data. A service that trains on your information as you use it doesn't forget that information when you vacate the premises because it keeps footprints of it in its DNA. Vendor lock-in used to be about contracts and migration costs, and now it's also about what you have already handed over without realizing it. That makes every AI vendor decision a riskier one than it looks.

That distinction is exactly why the investments announced around ALL IN matter. Two days before ALL IN, Bell announced a $50-billion expansion of its AI data-centre project in Saskatchewan, the largest private capital investment in Canadian history. At the event itself, Canada and Germany committed new funding to LawZero, a lab building trustworthy AI, and held the first meeting of their Sovereign Technology Alliance.

‍

An Invitation to Experiment

I would have loved to hear more trial and error from the stage. I understand why it's rare. AI isn't a fixed target, and what you say today may look naive in six months, so sharing an experiment that didn't work takes courage.

The industry won't wait for anyone to catch up, though. Enormous sums are flowing into infrastructure, and impatient shareholders are waiting for their returns. If the target keeps moving, our processes must move with it, which means faster thinking and more experimentation. Waiting for AI to be perfect before getting on the train means never getting on at all. The internet has never been perfect either but somehow, we have managed to work with it.

So start now, with what you have, and share what you learn, failures included. That's what I was hoping to hear from the stage.

‍

We no longer have an AI problem. We have a talent problem.

The idea I heard most, and the one I agree with most, is that technology is no longer the bottleneck. People are. What we have to work out is how to build the skills, habits and judgment our organizations need to use these tools well. Canada and Germany both named talent as a priority, and that priority now has to reach every team, not just the research labs.

As a developer, I left ALL IN wanting more. As someone who manages a team of developers, I left a little reassured because nobody in that building has found the magic formula that makes everyone ten times faster. A company is more than its developers. Make developers ten times faster while everyone around them stays the same, or slows down trying to keep up, and you haven't solved anything. You've just moved the bottleneck downstream.