We Don't Sell AI. We Solve Business Problems.

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 your 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?

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?