Insights & Technology for Complex Business Challenges

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?

As enterprise technology investments have grown by an average of 8% per year since 2022 (McKinsey, 2025), one reality remains: not every digital transformation project delivers a return on investment (ROI). A Boston Consulting Group study reveals that 70% of digital transformation projects fail to meet their objectives, often with serious consequences. That same study, however, underscores just how valuable these investments can be when done right.

So where do things go wrong?

Rarely at the product, artificial intelligence (AI), or software development level itself. The success of a digital transformation is determined well before the first line of code. It's mainly based on the strategic planning of the project.

Our thesis? A custom software development project is, above all, a business project. So yes — strategic planning is critical.

To reduce risk and ensure your next digital transformation project becomes a growth driver, take a moment to debunk 5 myths that could potentially derail your next IT project.

‍

1. "Success depends mostly on making the right technology choices"

Technology choices do matter. But the greatest risk in a project is rarely technical. It's organizational. Unclear objectives, misalignment, and low team buy-in cause more failures than the choice of language or infrastructure ever could. Technology is the tool used to address a business challenge, not the answer in itself. Confusing the two means building a solution that works technically but solves nothing concrete.

The reality: A software project is, first and foremost, a business project. Enterprise software isn't successful because it works on a technical level. It's successful because it simplifies work, creates tangible value for your business, and is actually adopted by your users.

‍

2. "We can start coding and adjust later… analysis is just a waste of time"

What's deceptive about application development is that changes can always be made. But every change comes at a cost… And the later in the process it occurs, the higher that cost tends to be. Jumping into development without a defined foundation is a straight path to scope creep and cost overruns. Yes, projects evolve, but every structural change midcourse has significant downstream impacts on budget and timeline. The analysis allows you to anticipate critical constraints, identify real user needs, and validate key assumptions.

The reality: Identifying core requirements and critical dependencies during the analysis (also called the Discovery phase) reduces project risk. Starting development without this ground work is like building a house without blueprints. You can always knock down a wall, but it costs a lot more than erasing a line on a plan.

‍

3. "Artificial intelligence will make planning obsolete"

The risk, here, doesn't lie in your software architecture. It comes from your decisions, from the very first version to a final product. Artificial intelligence can generate features at record speed, but it cannot define your business strategy. The more production capacity increases, the more precisely your roadmap needs to be defined

The reality: AI cannot anticipate the critical dependencies between your various systems, nor ensure that the tool will actually address the real pain points of your teams on in your factories, on the field or in your office.

‍

4. "We'd rather payfor off-the-shelf software. It's cheaper than custom"

If an off-the-shelf solution perfectly meets your needs, it's probably the smarter choice… And we'll be the first to say so. But when the solution touches the core of your operations, what sets you apart from your competitors, your secret sauce — the math changes entirely. A well-built custom software solution, approached as a business project, becomes an investment. Especially if it centralizes your processes, replaces several existing tools, and saves you time and money in the long run. In many industries, there are also hybrid approaches to software that combine existing solutions with custom development via APIs, targeting only what creates unique value for you.

The reality: It's not a question of custom versus off-the-shelf. It's a question of alignment with your business objectives. Ask yourself whether the solution addresses a challenge that sets you apart, whether it integrates into your environment, and whether it saves costs, time, or enables something your competitors can't do. That will give you your answer.

‍

5. "Delivery marks the end of the project"

Software is a living asset. And its deployment is not a finish line. It's the moment when users take ownership of the solution, when new learning begins and new ideas emerge. This is especially true knowing we rarely aim for the perfect solution right out of the gate: you ship a first version addressing core needs. Like a house, once built, it needs ongoing maintenance and improvements to preserve its usefulness and value. Underestimating adoption, support, and evolution costs in the initial business case can be a major mistake.

The reality: Plan for an annual software maintenance and enhancement budget based on the level of risk you're willing to carry. Once the solution is in place, it needs to be maintained to preserve its value and relevance.

‍

These 5 myths share a common thread: they shift attention toward where risk is lowest, and away from where it's highest. You invest in technology, pick the right tools, kick off development… All to discover along the way that objectives were vague, that users were never consulted, or that the solution is solving the wrong problem.

Worth repeating: 70% of digital transformation projects fail to meet their objectives (BCG, 2020). Not because the technology fell short. Because strategic planning wasn't taken seriously.

A software project is, above all, a business project. And even your sharpest colleagues and managers could fall for these misconceptions.

Why not share this article with them so your next project lands in the 30% that succeed?