Insights and Technology
Our story, vision and perspectives on technology, design and business solutions.
Featured Articles
On a sunny summer Thursday, Spiria held its first hackathon entirely dedicated to agentic development. In concrete terms, the goal was to build a solution using agentic development (also known as agentic AI), a technology capable of designing AI systems that can execute end-to-end tasks autonomously (analyzing, deciding, acting, and iterating) without constant human intervention.
Everyone at Spiria participated. Whether their expertise was in software development, finance, or UX/UI design, the event brought together our entire team across Canada. Whether from one of our offices or remotely, each person chose to build one of 11 proposed tools, all designed to address real needs tied to Spiria's operations.
Participants paired up with a tool such as Codex, Claude Code, or GitHub Copilot, and had the support of a team of internal coaches, people who had already developed an expertise in agentic AI.
This experience confirmed one thing: agentic development is already transforming the way software is designed and built.
Why do this?
Believe it or not, being the CEO of a software development company in the age of AI, especially with the rise of agentic AI, shakes things up. But being passionate about programming and having built a career from it is, for many other passionate people like me, even more confronting.
I still do a lot of development for fun and for internal projects at Spiria, but I obviously don't know every software technology out there. As agentic AI became more sophisticated, I knew I had to try it myself, using technologies I'm less familiar with.
I first tested Codex to build an internal tool for my colleagues in the Culture and Talent department, and within a few hours, in a technology I don't master at all, I created a working prototype. I immediately understood that it was time for me to change the way I code. I can no longer limit myself to only doing what brought me so much intellectual pleasure; it's now up to me to find other sources of stimulation.
The reality is that the last four decades have been filled with revolutions that simplified my life as a developer. Here, agentic AI is changing my day-to-day completely. I knew the whole team needed to experience it for themselves in order to understand it, and to learn it.
Beyond code generation
AI tools have long been seen as assistants, capable of writing a few lines of code, completing a function, or recalling the syntax of a programming language.
Today's agents go much further.
They can analyze a codebase, modify multiple files, run tests, spot errors, suggest an architecture, generate documentation, and take part in complete development cycles.
This doesn't mean human expertise becomes less important. On the contrary, its role changes and becomes even more decisive.
An agent can produce code quickly. On its own, however, it doesn't understand an organization's priorities, industry-specific constraints, operational risks, security requirements, or the long-term consequences of a technology decision.
This is precisely where the expertise of an experienced team proves its worth.
Our clients aren't simply chasing novelty
Most of our clients don't ask us to use a technology simply because it's new or trendy.
Above all, they want their solution to work.
- They want it to be secure.
- They want it to be maintainable.
- They want to be able to evolve it.
- They want to avoid depending on a fragile prototype, a single vendor, or a technology choice that will quickly become a liability.
Agentic development doesn't change these fundamental expectations. Instead, it increases our ability to meet them faster.
Used correctly, agents can reduce time spent on repetitive tasks, speed up the production of first versions, make it easier to explore multiple technical approaches, and improve certain validation processes.
They also allow our teams to spend more time on the aspects that require the most judgment: understanding the problem, defining the right architecture, protecting data, managing trade-offs, ensuring quality, and preparing for the future.
Speed isn't enough
It would be easy to reduce agentic development to a promise of productivity.
Producing faster is useful, but it isn't enough.
Software that's delivered quickly but is hard to maintain, poorly secured, or poorly suited to real needs remains a bad investment.
The value of agentic development therefore depends on how it's governed.
Agents' responsibilities need to be clearly defined, the tools and data they can access need to be controlled, their decisions need to be validated, rigorous development standards need to be maintained, and their use needs to be integrated into existing quality assurance and cybersecurity practices.
It's also important not to confuse generation speed with delivery speed.
Code is only part of the work. There's still a need to understand requirements, manage dependencies, test critical scenarios, prepare deployment, document decisions, and ensure the solution's continuity.
Agentic development becomes truly compelling when it's integrated into this entire value chain.
A new way of mobilizing our expertise
Every technological advance has allowed us to focus on more complex problems.
High-level languages, software libraries, development frameworks, cloud services, and automation tools have gradually eliminated a great deal of manual work.
Agentic development is part of this continuity, but its impact could be even greater.
As agents take on a larger share of technical production, value will shift toward the ability to guide them well, evaluate their output, and integrate their work into coherent systems.
There will always be a need to define the right requirements, choose the right paradigms, establish the right constraints, and ensure the different components work together.
There will always be a need to understand users, operations, risks, and business objectives.
That's where Spiria's expertise lies.
What Spiria brings to agentic development?
Our role isn't simply to plug an AI tool into a project and hope it produces a satisfactory result.
We help our clients determine where agentic AI can genuinely create value.
We can use it to speed up prototype design, modernize an existing application, automate certain tasks, support development teams, improve testing, or explore different solutions more quickly.
But we do it with the same rigor we apply to all our projects.
This means paying particular attention to architecture, security, privacy, code quality, maintainability, observability, and the long-term viability of solutions.
It also means choosing the right level of autonomy.
In some contexts, an agent can carry out tasks very autonomously. In others, it must propose actions that are then reviewed and approved by a person.
Turning experimentation into lasting value
Our hackathon allowed us to experiment quickly, test our assumptions, and better understand the real capabilities of today's tools.
It also reminded us that an impressive demo is only the starting point.
The real work is turning that capability into reliable, secure, and durable solutions.
That's exactly what our clients expect from us.
Agentic development is opening the door to new ways of building software. It can help us move faster, explore more, and spend more energy on the decisions that truly matter.
But its value doesn't rest on technology alone.
It rests on the expertise of the people who know how to use it, how to govern it, and how to integrate it into a long-term vision.
This is how Spiria intends to approach agentic development: with curiosity, with pragmatism, and with the determination to build solutions that work today and will keep working tomorrow.
And you... How is you company approaching agentic AI?
There was a time when joining the software industry felt less like arriving and more like being admitted into a new school.
After years of academic learning, becoming a software developer did not mean you finally "knew." It meant you had earned the right to begin learning differently. You entered as a junior. You listened. You respected the people who had already spent years debugging production systems, designing fragile integrations, recovering from bad abstractions, and learning which elegant ideas survived contact with users.
Experience was not measured only by years employed at a company. It was measured by depth of understanding, judgment under uncertainty, and the ability to pass knowledge on. Younger developers sought mentors with the intensity that modern social media influencers seek followers. The craft had a kind of sacredness to it, because the work demanded humility.
To apply for a software developer role implied that you understood both the art and science of the profession. You were expected to know, or at least be actively learning, the foundations: TCP/IP, load balancing, database indexing, trees, graphs, hash tables, sorting and searching algorithms, Big O notation, garbage collection, threading, concurrency, memory management, design patterns, SOLID principles, testing strategies, refactoring techniques, and the difficult judgment of when not to use the clever thing you just learned.
Those were also the days when autocomplete was the closest thing to a copilot. When a complex problem appeared, peers often went for coffee and talked it through before losing hours in the wrong direction.
Now the ground is shifting. AI has not made the fundamentals irrelevant. It has made them easier to bypass.
A developer can now ask an AI tool to explain a TCP protocol, generate a database migration, suggest indices, write tests, refactor a class, summarize unfamiliar code, or scaffold an entire feature. Often, the tool will produce something useful. Sometimes it will produce something confidently wrong. That distinction is central to the future of software development.
The question we ask ourselves as practice leads is no longer, "Can AI write code?" It clearly can. The question we now ask ourselves is "Who is qualified to know whether the code is correct, maintainable, secure, observable, and aligned with business?"
AI Is Already in the Workflow
This is not a distant future. It is already happening.
Let’s look at the data.
The 2025 Stack Overflow Developer Survey found that 51% of professional developers use AI tools daily, and 52% say AI tools or agents have had a positive effect on their productivity. Among developers using AI agents at work, about 70% say agents have reduced time spent on specific development tasks, and 69% say agents have increased productivity.
At the same time, trust remains a serious concern. The same survey found that 87% of respondents are concerned about the accuracy of information provided by AI agents, and 81% have concerns about security and privacy. Adoption is rising, productivity is real, and confidence is incomplete.
Controlled research shows the same tension. The widely cited Peng et al. study of GitHub Copilot found that developers using the tool completed an HTTP-server task 55.8% faster than those without it. McKinsey's research also found that generative AI can make developers significantly faster on code generation, refactoring, and documentation, while emphasizing that quality depends on developers understanding what good code looks like and iterating with the tool.
But the picture is not uniformly positive. A 2025 randomized controlled trial by METR studied 16 experienced developers working on large, mature open-source codebases they had contributed to for years. The result surprised many people: developers were 19% slower with AI assistance than without, even though they believed they were roughly 20% faster.The researchers attributed the gap to context-switching, prompt iteration, and the cognitive cost of reviewing plausible-looking output.
The 2024 DORA Accelerate State of DevOps report adds another caution. Across respondents who reported relying on AI for at least part of their work, AI adoption was associated with an estimated 1.5% decrease in delivery throughput and a 7.2% decrease in delivery stability. DORA's hypothesis is that AI may help developers produce larger changelists, and larger changes have long correlated with slower, more brittle delivery.
In other words, AI can accelerate the work, but the gains are uneven and do not automatically translate into better systems. The acceleration has to be earned through judgment.
The Developer as Orchestrator
The software developer role is being reshaped.
The developer is becoming more of an orchestrator, reviewer, architect, and supervisor of intelligent systems. As agentic tools become more capable, more implementation work can be delegated. The human role moves upward: defining the problem, decomposing the work, choosing the architecture, constraining the agent, validating assumptions, reviewing outputs, and ensuring that the final system behaves correctly.
This does not mean developers can afford to know less. They need to know more broadly.
A developer working with AI needs enough architectural understanding to recognize when a generated design will not scale, when a service boundary is wrong, when a database query will collapse under real traffic, or when a security assumption is naive. They need enough testing discipline to know whether generated tests prove behavior or merely increase coverage numbers. They need enough product understanding to notice when the implementation technically satisfies the prompt but fails the user.
The best developers in an AI-assisted environment will not be the ones who simply generate the most code. They will be the ones who ask better questions, constrain the system more effectively, review more critically, and connect technical decisions to business outcomes.
Even the orchestrator role may be transitional. Today, reviewing AI output is what keeps the human meaningfully in the loop. But when an agent can generate hundreds or thousands of files in a single sitting, our capacity to objectively review code does not scale with it. The natural response may be to delegate some review to another agent, moving the human up another rung. Software may eventually become what car engines became for most drivers: a black box you trust and use.
The Fundamentals Still Matter
There is a useful analogy in cell phones. Many of us no longer memorize phone numbers. The technology made that unnecessary in everyday life. But there are still moments when memory, understanding, or preparedness matter.
AI may do something similar to software fundamentals. Some knowledge will move from active recall to assisted retrieval. A developer may not remember every detail of a sorting algorithm or concurrency primitive because the tool can explain it on demand. But if the developer cannot evaluate the explanation, they are no longer assisted. They are dependent.
That dependency is risky, and the risk has measurable shape.
AI can hallucinate APIs. It can produce inefficient queries. It can invent configuration options. It can generate tests that assert the implementation rather than the behavior. It can solve the local problem while violating a larger architectural constraint. It can confidently recommend patterns that are obsolete, insecure, or inappropriate for the system in front of it.
A 2025 analysis of 576,000 code samples generated by 16 popular large language models found that 19.7% of package dependencies were "hallucinated," meaning they referred to libraries that do not exist. Open-source models hallucinated at nearly 22%; commercial models, at roughly 5%. This has produced a new supply-chain attack class researchers call slopsquatting, where malicious actors register hallucinated package names so AI-suggested installs become attack vectors. Independent assessments of AI-generated code more broadly find that 29-45% of samples contain security vulnerabilities depending on language and task type.
This is why fundamentals still matter. Beyond memorized trivia, the mental model still needs to supervise the machine.
A developer does not need to hand-write every binary search to be competent. However they should understand why indexing matters and when to use indices. They should understand latency, failure modes, transactions, concurrency, memory, coupling, cohesion, test boundaries, observability, and trade-offs. The details may be assisted. The judgment cannot be outsourced as easily.
At least not yet.
Software May Become Cheaper to Produce, But Not Smaller in Ambition
Manufacturing cars has become heavily automated. The International Federation of Robotics reported that more than one million robots were working in the automotive industry worldwide, with countries such as South Korea, Germany, the United States, and Japan showing very high robot density in automotive production. Automation has helped manufacturers improve consistency, productivity, and throughput.
But cars did not simply become cheaper, simpler objects. They accumulated new expectations: advanced safety systems, navigation, sensors, entertainment systems, software controls, fuel efficiency improvements, driver-assistance features, and now electric drivetrains. The U.S. Bureau of Labor Statistics accounts for these changes when measuring new vehicle prices, adjusting for improvements in safety, fuel economy, mechanical systems, comfort, convenience, navigation, communication systems, backup cameras, sensors, and other functional upgrades.
There is a name for this dynamic in economics: the Jevons paradox. When a resource becomes more efficient to use, total consumption can rise rather than fall because the lower cost unlocks new categories of demand that previously failed the cost-benefit test. It was first observed in 19th-century coal use as steam engines became more efficient, and it has reappeared in electricity, computing, and bandwidth ever since.
The lesson is not that automation makes everything cheap forever. The lesson is that automation changes what becomes economically possible. As production becomes more efficient, expectations rise. Products absorb more features. Markets demand more customization. Companies discover new ways to compete.
AI may reduce the cost of producing certain kinds of software, especially boilerplate, prototypes, migrations, test scaffolding, documentation, internal tools, and routine feature work. But lower cost will not necessarily mean less work. It may mean more software, more experiments, more personalization, more integrations, more automation, and more pressure to deliver faster.
If the cost of building decreases, the appetite for building may increase.
The Human Bottleneck Moves
Historically, one bottleneck in software development was implementation capacity. How many developers do we have? How much code can they write? How many tickets can they complete?
AI changes that equation. In some contexts, a smaller team with strong AI-assisted workflows may produce what previously required a larger team. It would be naive to pretend this will not affect staffing. Some teams may downsize. Some roles may consolidate. Some entry-level work may be automated or transformed.
The early data points are striking. Salesforce reported that it hired no new software engineers in fiscal year 2026, with CEO Marc Benioff attributing the shift to AI coding agents and citing roughly a 30% engineering productivity gain. Across the broader U.S. tech sector, more than 142,000 workers were cut in the first five months of 2026, with AI cited as a top reason in firms tracked by Challenger, Gray & Christmas, and entry-level developer employment falling significantly from its late-2022 peak.
It is worth being honest about where displaced developers may actually go. When automotive robots replaced welders, the displaced workers did not all become robot supervisors and weld inspectors. The arithmetic rarely works that way. Some moved sideways and took welder jobs at companies that had not yet automated. Others left the trade entirely. Software is unlikely to be different. The orchestrator and supervisor roles are real and growing, but they are not a one-for-one replacement for the headcount they consume.
Some developers will move into adjacent technical work: integration, architecture for clients who can no longer afford their own teams, security review, data, and platform engineering. Others will move into roles that lean harder on human capability than technical depth: client conversations, requirements shaping, product judgment, and relationship work. Remaining technical will still matter, but not always in the algorithmic sense it used to.
The lifecycle around the work may compress too. The traditional services arc of lead, discovery, design, build, deploy, and application management depends on the build and deploy phases being expensive. When those phases collapse in cost, the lifecycle compresses with them. It is not hard to imagine a near-term version where the output of a well-run discovery becomes the deployed system itself.
But another bottleneck becomes more visible: decision quality.
What should we build? Why? For whom? What risks are acceptable? What should be automated, and what should remain human-reviewed? Which generated code is good enough? Which system behaviors matter most? Which tests actually protect the business? Which failures are tolerable, and which are existential?
These are not merely coding questions. They are product, architecture, risk, and organizational questions.
This means developers will need to understand the business more deeply. They will need to think like QA, product managers, architects, operators, and security reviewers. They will need to validate outcomes, not just implementations. They will need to know when an AI-generated solution is technically impressive but strategically wrong.
The future developer may spend less time producing every line manually and more time ensuring the system as a whole is coherent.
The Risk of De-Skilling
There is a real concern that AI could produce a generation of developers who can assemble software but do not understand it. That concern should not be dismissed as nostalgia.
If juniors never struggle through debugging, never learn how HTTP works, never reason about data structures, never see production failures, and never receive mentorship from experienced engineers, then the industry may gain short-term velocity while weakening its long-term talent pipeline. The hiring data already suggests this rung of the ladder is under pressure: the entry-level positions where this learning used to happen are among the ones contracting fastest.
The old apprenticeship model was imperfect, but it served a purpose. It gave developers a path from imitation to understanding, from syntax to design, from fixing bugs to anticipating them.
AI can help with learning, but only if used deliberately. It can explain unfamiliar code, generate examples, compare approaches, and provide immediate feedback. But it can also allow a developer to skip the discomfort where real understanding is formed.
Organizations will need to be intentional. They cannot simply hand AI tools to junior developers and expect mastery to emerge automatically. Mentorship still matters. Code review still matters. Pairing still matters. Architecture discussions still matter. So does the old habit of stepping away from the keyboard to think before generating more code.
What May Be True Today May Be False Soon
Any confident prediction about AI should come with an expiration date.
It helps to remember that this is not the first such shift, only the steepest. The work a developer did in the 1980s looks nothing like the work in the 1990s, which looked nothing like the 2000s, and even 2020 already feels distant. Bit-packing because memory was scarce, hand-rolled assembly inside C because higher-level code was too slow, and chasing cache misses to keep applications responsive all became less central as we moved to interpreted languages, containers, virtual machines, managed runtimes, and cloud platforms.
Each generation of developers had to let go of something the previous generation defined themselves by. We should expect the same of ourselves, probably on a faster clock.
That progression has a pattern: each generation of tools raised the level of abstraction, changed the role, and increased output. The arrival of compilers and high-level languages is credited with at least a fivefold improvement in productivity over assembly programming. Virtual machines and managed runtimes erased entire categories of memory and portability work. Containers and orchestration systems made deployment a configuration problem. Cloud platforms turned hardware provisioning, scaling, and global distribution into API calls. Infrastructure-as-code turned operations into a code-review problem.
At every step, the developer produced more, knew slightly less about the layer beneath, and was held responsible for slightly more of the layer above.
The same progression has quietly reshaped entire job titles. Twenty years ago a serious software organization might have needed dedicated systems integrators, database administrators (DBA), and network operations analysts. Much of that work has been absorbed into DevOps, cloud platforms, and managed services. Database administrators have not disappeared, but demand has shifted toward cloud and application-side work, while routine administration that once justified a full team is now often a managed-database setting. Sysadmin and network operations work have followed similar paths. These roles were not abolished. Their demand thinned, their boundaries blurred, and the work moved.
If that pattern holds, the honest answer to "what happens to developers?" may be the same answer that applied to DBAs and integrators: the role does not vanish, but it narrows, shifts, and re-forms around whatever the next layer of abstraction leaves unautomated. The uncomfortable part is that developers are, in a real sense, building their own next abstraction.
The tools are changing too quickly for certainty. What seems risky today may be routine in six months. What seems impressive today may feel primitive in a year. The boundaries between autocomplete, assistant, agent, reviewer, tester, and autonomous implementer are already blurring.
So the safest position is not to declare that AI will replace developers or that it never will. Both claims are too simple.
A more balanced view is this: AI is changing the economic and practical shape of software development. It will automate parts of the work. It will amplify capable developers. It will expose weak engineering practices. It will create new risks. It will reduce the cost of some deliverables and increase expectations for what teams can produce. It will make fundamentals feel less visible, while making judgment more important.
The craft is not disappearing, but its rituals are changing. The developer of the future may not be judged by how much code they can personally type. They may be judged by how well they can direct intelligent tools, evaluate their output, preserve system integrity, understand the business, protect users, and keep learning as the ground moves.
That future may feel less sacred than the past. Or perhaps the sacredness simply moves: from memorizing every command, pattern, or algorithm to caring enough to know when the machine is wrong.
What do you think about the futur of our craft?
All Articles
Artificial intelligence (AI) promises a lot, but it's true potential often remains untapped.
Why? Well, not because technology lacks maturity, but because we forget that real-world use by people remains the real driving force behind any digital transformation.
And yes, no one understands humans better than humans.
This is where the “human-first” approach comes in, a simple philosophy that places people at the heart of technological changes, and thus designing tools and systems that genuinely work for the individuals who use them.
The goal isn’t to strengthen the technology itself. It’s to strengthen our understanding of the work your teams do before adding a layer of artificial intelligence on top of it. You can have the most advanced systems in the world, but if your teams aren’t ready, nothing will move forward.
At Spiria, we see it every day. Successful organizations don’t just modernize their infrastructure. They modernize how their teams interact with their tools, their data, and their workflows. They lay the groundwork for AI to become useful, understandable, and sustainable.
This article explores how human-centred software modernization naturally prepares organizations to welcome AI that integrates itself smoothly, supports people, and enhances their work for long-term AI success.
Modernizing for AI starts with modernizing for humans
Modernizing first, then wondering how to drive AI adoption internally.
How many organizations have made this mistake?
The desire to integrate AI is natural. It represents progress, innovation, and efficiency. But in reality, it often struggles to fit into environments that were never designed to support how teams actually interact with them.
The result? These systems that seem modern on paper remain underused. The teams using them are frustrated, and bypass these new tools to return to old habits. It’s a disappointing ROI that leads leadership to question AI itself.
In our previous article, “Why Legacy Systems Break Under AI Pressure”, we explored the technical obstacles of fragmented data, rigid architectures, and technical debt. But these technical obstacles are only part of the problem. The other part, the one we overlook far too often, lies in human and organizational silos.
That’s why a people-centered approach is essential. Modernization must be guided, not only by technical requirements, but by the people who depend on these systems every day. It’s about clarifying, simplifying, and streamlining the experience, so tools become coherent, easy to use, and aligned with day-to-day work.
AI only creates value when it enters an environment teams already understand. Modernizing for AI therefore means modernizing for humans first.
The three foundations of human-readiness: clarity, trust, collaboration
Before diving any further, let's remember one key thing, “human-first” is the approach, while “human-ready” is the outcome. In other words, an organization reaches this state when modernization is intentionally designed for people and put into practice.
These pillars are the foundation for this:
1. Clarity
Clarity translates to making systems readable, workflows understandable, and tools intuitive.
It is about operational transparency, not technical transparency. What data does AI use? Why does it recommend one action over another? What are its limits?
Teams need to understand what a system does, how it does it, and why it does it.
Clarity reduces uncertainty and opens the door to natural, confident use of AI.
It helps users know when to trust the algorithm and when their own judgment should take the lead.
2. Trust
Trust is the invisible core of any technological adoption.
It grows gradually, but it starts with evidence.
Building trust in AI requires reliable systems, consistent results, and tangible improvements in day-to-day work. People need to see that AI simplifies their work rather than complicates it, and that it respects operational realities instead of ignoring them.
Ongoing training is crucial. Not only at the beginning of a project, but over time, giving teams the space to explore, ask questions, and build technological intuition.
When trust settles in, AI becomes genuinely useful.
3. Collaboration
Collaboration is what brings everything else to life.
AI projects rarely fail because of algorithms. They failed because people weren’t involved early enough.
Preparing teams to collaborate with AI means understanding their real pain points, their critical decisions, and their operational constraints. This knowledge is what allows AI to find its appropriate role in the workflow.
AI can optimize a process, but only humans can understand nuance, context, and intent. This complementarity is where its true value lies.
From AI-ready to human-ready: two concepts often confused
Many organizations aim to become “AI-ready" with upgraded infrastructure, centralized data, and new intelligent tools. But none of these matter if people aren’t ready to use them.
Being “human-ready” is different. It is the outcome of a “human-first” approach. It means having simple systems, clarified processes, and tools that match real-world usage. It means creating an environment where teams understand the technology, trust it, and can apply it with discernment. And this people preparation must come first.
Too many organizations treat modernization as an isolated IT initiative. They invest millions in new infrastructures without ever questioning user experience. But what is the point of a high-performance system if no one wants to use it?
Organizations that succeed with AI don’t just deploy new tools. They prepare their teams to integrate them into daily practices, even before the first deployment.
They adjust processes early. They clarify roles and responsibilities before AI arrives. They build trust during the design phase, and do not wait for the first setbacks.
They invest in sustainable organizational transformation, where humans remain at the centre of decision-making from day one.
What if the key to AI success was simply people?
“Human-first” modernization isn’t a trend.
It’s a working philosophy based on a simple truth: long-term performance is built on strong human foundations, not solely on advanced algorithms.
Modernizing means creating systems that are clearer, more reliable, and more people-centered, systems capable of evolving at the pace of the people and organizations they support.
At Spiria, this belief guides our approach to modernization and AI integration projects. We enable organizations to build custom solutions that empower people, so AI can truly deliver on its promises.
Because the foundation of AI success lies in an approach that makes artificial intelligence useful, sustainable, and deeply human.
What if the best way to succeed with AI was simply to put people back at the heart of modernization?
How many companies start their modernization project thinking: "I know exactly what I want, why pay for an analysis?"
If you've heard this in your organization (or if you've said it yourself), you're not alone. But it's a bit like telling an architect: "I need a house, just start digging tomorrow morning."
Obviously, we'd never build our dream home without detailed plans, soil studies, or permits. Yet that's exactly what we do with our business software systems, which are worth thousands of dollars. Funny logic, isn't it?
So, how do you move forward with clarity rather than blindly to ensure good strategic preparation? Two points make all the difference: defining your business objectives and understanding your end users.
Defining Your Business Objectives
"We already know what we want" Are you sure?
Often, what we think we want is only part of the answer, and this certainly can be costly...
Here are some common truths often underestimated in most modernization projects:
What's hiding under the hood of your systems
Your applications don't live in isolation. They exchange data through Applications Programming Interfaces (APIs) that no longer run smoothly, share databases that are sometimes disorganized, and rely on small fixes made by your teams that no one currently documents.
In this context, choosing to modify an element of your software without first mapping these interdependencies is like playing Jenga with your infrastructure. A thorough audit of your systems will reveal these hidden links and help anticipate ripple effects.
The real hidden costs of migration
The price of new technology is never just the license. Team training, data migration, integration testing, the ramp-up period... All these indirect costs can often represent a large portion of the total project budget. By identifying them from the start, we transform unpleasant surprises into controlled budget lines.
The real impact on your business processes
Changing systems often means changing how people work. Your teams have developed countless workarounds to bypass bugs, speed up processes, and create shortcuts to compensate for current limitations. Over time, these habits become invisible... until they stop working. Taking the time to understand the human impact makes all the difference in ensuring a successful transition.
When AI reveals everything we preferred to ignore
Added to all these challenges is artificial intelligence (AI), which can, in some cases, complicate the equation. Wanting to "just add AI" to a system that's poorly prepared will amplify all your existing issues. AI requires clean, structured, governed data, otherwise it will instantly reveal inconsistencies, duplicates, and obsolete formats. Without solid foundations, AI becomes a problem magnifier rather than a driver of efficiency.
How do you see more clearly?
The key? A structured approach that leads to project success.
Start by taking time to analyze your entire ecosystem: collaborative workshops with all stakeholders, not just IT. Then, map real data flows, audit hidden technical constraints, and most importantly, define real business objectives with measurable success indicators.
The result? You move from "we think that..." to "we know that...", with a roadmap that anticipates obstacles instead of discovering them along the way.
At Spiria, our teams of business analysts, developers, and designers don't just deliver a plan, they join you as technical partners to map your entire ecosystem, reveal invisible dependencies, and build a roadmap aligned with your business objectives.
Understanding Your End Users (UX/UI)
"Our teams will adapt" Is it that simple?
Big trap. Focusing everything on technology and budget while forgetting those who will actually be using the solution: your users. Their realities are quite different, as are their expectations.
A project that neglects this dimension runs a major risk: delivering a system that's robust on paper but unused in practice. And obviously, a tool that isn't adopted is a wasted investment.
The 4 pillars of user adoption:
1. Moving beyond assumptions
Too many projects start from what leaders think their teams do, rather than what they actually do. Big difference. Real behaviours, real frustrations, and real usage contexts only emerge through direct observation and in-depth interviews.
2. Designing the architecture the way your team thinks
Your users aren't looking to admire your interface, they want to accomplish their tasks efficiently. Organizing features according to their real objectives will transform navigation into a smooth journey. Indeed, what sets good information architecture apart is that it becomes invisible to the user, meaning that they find what they are looking for without having any effort.
3. Prototyping: Testing before building
Having real people test interactive prototypes reveals necessary adjustments before they become very expensive to correct. Whether it's a misplaced button, a process that's too long, or confusing terminology, the prototype will help avoid weeks of redevelopment.
4. AI serving the user, not the other way around
Even the most sophisticated artificial intelligence fails its mission if it doesn't match users' real habits and constraints. An approach centered on their workflow will ensure that AI amplifies efficiency rather than creating new frustrations.
How do you ensure adoption?
The key? By immersing yourself in field reality from the start, not at the end.
Understanding why your users take certain shortcuts, identifying their real challenges, observing the context in which they work (quiet office, noisy open-area office, constant travel). This detailed understanding guides each design choice toward real adoption rather than assumptions.
The result? A solution with better adoption rates that protects your investment rather than wasting it.
At Spiria, during our in-depth analysis phase (Discovery Phase), our UX/UI design teams dive into your field reality, conduct interviews with your various departments, observe real journeys, and transform pain points into measurable design criterias.
The Foundation of Lasting Success
Modernizing on fragile foundations is like building a house directly on the ground, without a concrete slab. It holds... until the first storm.
Companies that invest in serious preparation deliver faster and see their teams naturally adopt new tools.
In 2025, AI accelerates this logic. It amplifies what exists: solid foundations become a powerful lever, fragile foundations create complications. This reality makes preparation even more important.
Yes, preparing well requires more time and initial investment. But you need to consider the total cost: companies that prepare rigorously avoid data flow redesigns, successive corrections, and months of post-launch adjustments. The upfront investment pays off quickly when you don't have to rebuild everything six months later.
While your competitors are correcting their planification mistakes, you're already optimizing them. This head start is measured in quarters, and market shares. Preparation is what turns uncertainty into clarification. It’s the moment when strategic decisions take shape, risks become manageable, and every dollar invested supports long-term success.
Today, Artificial Intelligence (AI) dominates every strategic and business growth conversation. So far, this is probably old news to you.
But once we move past theory, the reality is quite different. While budgets allocated to AI projects are exploding, many organizations encounter a major obstacle they hadn’t fully anticipated: their legacy systems are slowing down their digital transformation.
Does this reflect the reality of your company?
Here, the real obstacle isn’t even AI’s complexity. It’s the growing gaps in your systems. They were never designed for today’s standards and lack three crucial elements: clean and reliable data, flexible integration capabilities, and computing power.
Recognizing these limitations makes it clear why application modernization has shifted from a technical decision to strategic one.
1. Clean Data: AI’s Fuel
Would your data be ready to feed AI today? If your immediate thought was anything close to “yes, absolutely” ... well, this tab would (probably) be closed already.
AI’s efficiency relies entirely on its access to clean, structured, and consistently formatted data. To generate reliable analyses, machine learning algorithms require absolute accuracy in their data sources. Even slight data quality issues can quickly degrade the performance of the entire intelligent system.
However, for legacy systems, the information stored is messy and inconsistent. It is kept in incompatible formats, and lacks the governance required to ensure long-term data integrity. The result? Your data lives in silos, often in contradictory formats, which is exactly the opposite of what AI needs.
These analytical deficiencies create a massive roadblock for organizations looking to leverage their data as a true strategic asset.
Sounds familiar? Well, it clearly indicates that your existing infrastructure is limiting your ability to stay competitive.
The consequences are immediate: while you struggle with inconsistent information, competitors are already harnessing predictive analytics and intelligent automation. This gap in data maturity rapidly translates into a competitive disadvantage.
Data architecture modernization eliminates these quality issues by providing automated governance systems, real-time validation pipelines, and consistent structuring that transform your information into resources immediately usable by AI.
2. Flexible Integrations: The Unified Ecosystem
How much time do you spend on custom integrations? If you have to think about it, it’s already too much.
AI requires a complete, unified view of data. Legacy systems create the opposite environment where each custom connection adds complexity and new points of failure.
Most organizations run multiple infrastructures that were never designed to communicate efficiently together, creating significant integration hurdles.
Let’s take a concrete example: customer’s information often lives separately across marketing, sales, and support systems. Each speaks its own language. Before data can even be fed to AI, it must be transformed, cleaned, and harmonized. This complexity restricts AI initiatives to limited and isolated use cases.
The solution? An API-first architecture.
Modern application architectures address these challenges with a design focused on Application Programming Interfaces (APIs). Instead of forcing complex integrations between incompatible systems, APIs provide standardized connectivity. This enables smooth data sharing and consistent AI integration across the entire technology ecosystem.
3. Elastic Resources: Infrastructure That Adapts
How many times have your systems buckled under unexpected spikes in activity? If the answer isn’t “never”, imagine what will happen when AI workloads are added to the mix.
This question often reveals the most critical limitation of legacy infrastructures: their lack of scalability. AI applications require massive resources in addition to flexible capacity to manage variable workloads.
Legacy systems quickly hit reach their limits. They were built for predictable, static loads, making them fundamentally unsuited for the dynamic computing demands of AI.
What happens when an organization tries to graft AI onto them? It’s common to see system crashes, degraded performance, and operational instability. Even worse, years of accumulated technical debt. This is the result of all the shortcuts, temporary fixes, and workarounds that gradually make the systems harder and more expensive to maintain. These are all symptoms of a fundamental mismatch in architecture.
This burden prevents organizations from investing in innovation and modernization, creating a vicious cycle where legacy systems slowly become obsolete. Without the required scalability, businesses miss out on essential advancements in machine learning and intelligent automation.
The adoption of modern solutions solves these scalability challenges by enabling dynamic resource allocation, true agility through microservices, and compatibility with today’s AI technologies.
Preparing Your Organization for an AI-Driven Future
Ready to turn your constraints into advantages?
Your legacy systems don’t doom your AI ambition, but they demand a purposeful transformation. Those who recognize this and invest in Application Modernization will be positioned at the forefront of their industries, leveraging data-driven decision-making as a true competitive edge.
The key is approaching transformation strategically, letting AI requirements shape architectural decisions and implementation priorities. This means investing in frameworks that ensure data quality, API-first design, cloud-based scalable infrastructures, and modern development practices that enable continuous innovation.
The cost of modernization is significant, but the cost of staying stuck on legacy systems that steadily grow obsolete while competitors capitalize on AI advantages is often far greater. The calculation is simple: staying on existing systems is more expensive than modernizing.
Beyond AI, modernization delivers broader strategic benefits. Modern infrastructures allow businesses to respond faster to market opportunities, adopt new technologies quickly, and maintain a strong competitive position as requirements evolve.
Today’s investment becomes tomorrow’s competitive advantages, sustaining your organization’s market leadership in the long run.
