Agentic AI has advanced from the promises-and-pilots phase of 2025 to reality and rollouts in 2026. In the process, agentic AI is transforming virtually every aspect of customer relationship management (CRM), the platform that manages sales, marketing, and customer service.

“Last year, everybody was dipping their toes into the water,” says Keith Kirkpatrick, research director at The Futurum Group. This year, agentic AI has built momentum from the boardroom down, with companies recognizing that having an AI strategy is imperative. “They feel like if they don’t embrace it now, their competitors will.”

Harry Datwani, a principal at Deloitte Digital, adds that enterprise CRM customers have transitioned from “proof of concept” to “scale and execution.”

“Across sales, service, marketing, even in the commerce space, enterprises are really using AI and agentic,” he says.

“CRM in 2026 is undergoing a structural shift, not just an incremental evolution,” says Forrester analyst Kate Leggett, noting that AI is becoming a core part of CRM infrastructure, not just a feature or an add-on. According to Forrester data, around 70% of companies are already using AI in their CRM systems, she says.

Here are the hot AI-driven trends in CRM this year.

CRM becomes an action hero

CRM platforms have traditionally served as passive, static systems of record. Now, agentic AI is transforming CRM into a powerful, real-time solution that can act autonomously.

“Organizations that rethink CRM as a real-time, AI-powered system of action — and embrace agentic AI to handle complex, unpredictable work — are better positioned to deliver exceptional customer experiences,” says IDC analyst Neil Ward-Dutton. “This approach not only enhances satisfaction and loyalty but also drives operational efficiency and business agility.”

Forrester’s Leggett says that AI-powered CRM platforms have advanced from simple data capture to real-time decision-making and execution. Standard capabilities include next-best action recommendations, call summaries, automated updates, generated emails, knowledge creation, predictive forecasting, and deal scoring.

She adds that AI agents can now execute workflows, such as routing cases, sending follow-ups, and updating records (with human oversight). They can also handle end-to-end service and sales tasks autonomously, including case resolutions and sales development activities.

Agentic drives workforce changes

AI use in CRM systems is also impacting workforce strategies.

“We used to hire for deep expertise,” says Constellation Research analyst Liz Miller. “AI has commoditized expertise because I can take all that data from my CRM and train my AI models to go deep, to know everything about any product I’ve ever sold, from what has worked, what hasn’t, every price, every sale.”

Now, instead of hiring candidates with deep expertise, organizations are looking for candidates who can go wide. “I can train a model to have deep expertise. What I can’t train for is experience, because experience is what happens when a person has gone broad across a lot of different scenarios and faced complexity across that broad scenario,” says Miller.

For example, AI systems can automate many aspects of marketing, Miller notes, but there’s no substitute for creativity: people who can interrogate the data and come up with innovative marketing campaigns that connect with customers.

Terence Chesire, group vice president of ServiceNow CRM and industry workflows, says that organizations are using agentic AI to free up team members from repetitive, lower-value activities. Those employees have now moved to higher-level roles “where they’re working on transformational deals rather than just building a spreadsheet.”

“That’s what we’re seeing as super-exciting as organizations not just free up people, but the speed and effort reduction and the friction reduction in what they can do,” he adds.

Data layer takes center stage

AI’s promise to deliver actionable customer and marketing intelligence has placed even greater emphasis on the importance on sound data management practices for CRM.

“The light bulb has flashed on very brightly for our clients,” says Deloitte’s Datwani. “Everyone is talking about AI agents, but your ability to really extract value is inextricably linked to the quality of your data and the ability to make that data accessible. What we’re finding is that despite large investments over time our clients still have fragmented data. And so, they are data rich and insight poor.”

The good news, says Datwani, is that AI agents themselves can help clean up and organize data. And vendors such as Snowflake and Databricks, along with the traditional CRM powerhouses, are offering powerful data analytics solutions. “Everyone is battling for that data layer,” Datwani says.

Forrester’s Leggett adds that CRM platforms are converging with customer data platforms (CDPs), real-time event streams, and external data sources to create connected customer data networks. These real-time, connected data models can help organizations deliver hyper-personalization at scale.

Agentic ushers in pricing complexity

The shift from license- or subscription-based pricing to an outcome or consumption pricing model has the potential to help CIOs tie their CRM costs to specific business metrics, such as the number of customer service calls resolved per hour. But it has also introduced a new level of complexity when it comes to budgeting for CRM costs.

For example, Chesire says ServiceNow’s CRM pricing plan starts with a baseline subscription model, and on top of that, customers get a certain number of AI tokens per user and can buy additional tokens as AI usage ramps up.

Meanwhile, Salesforce has rolled out pay-per-resolution pricing with its recently unveiled AI Help Agent and last month acquired usage-based billing specialist m3ter. Oracle is also piloting outcome-based AI pricing.

All these approaches undercut the predictability of the subscription model, which will complicate CIOs’ cost calculus, Deloitte’s Datwani says. “Now, as you start to think about consumption and tokens, costs might look different. As folks are opening up the architecture with things like headless CRM, what will the cost model look like for API calls or MCP server calls? So, there’s many more variables,” he adds.

The rise of multi-agent orchestration

To act autonomously, agents need to access multiple data sets and software platforms seamlessly. As a result, the proliferation of agents, some embedded within specific vendor platforms and some created in-house, is going to require an orchestration layer, Futurum’s Kirkpatrick says.

He points out that organizations need to monitor and manage agents, enforcing the same type of policy-based access control that exists for people. Organizations also need to set limits on what domains a specific agent can get into, what types of data they can access, what lines can’t they cross.

Kirkpatrick predicts that a new class of orchestration tools will emerge, although it’s not clear whether that orchestration layer will be provided by the leading CRM vendors, hyperscalers, or third parties.

Datwani agrees. “The orchestration layer is an interesting area, where the traditional vendors are in on it, the hyperscalers are also offering it, and there are third parties. It’s my belief that there’s not going to be a clear winner.”

The interface becomes conversational

Enterprise users who have traditionally had to manually wrangle with CRM systems are likely to find the ability to employ voice commands using a natural language interface to be a game changer. For starters, a salesperson can say, “I have a meeting today with Customer X. Help me prepare.” The agent will collect relevant data, ingest it, and provide a summary with recommendations.

ServiceNow’s Chesire says voice-enabled CRM systems have an “almost magical” ability to record, transcribe, and understand the content of a call between a salesperson and a customer or potential customer. The system can then “build a quote” based on that conversation.

On the customer service side of the equation, AI-driven voice technology enables customers to speak to an AI agent, describe the problem using natural language, and get a response. The agent has the capability to, for example, solve a credit card dispute, order a replacement product, send out a service rep, or do whatever is needed to resolve the issue, says Chesire.

Beyond that, agentic technology is capable of understanding the underlying business process flaws that led to the product snafu, and make recommendations for ways to fix whatever led to the issue in the first place, he adds.

Agentic drives business process transformation

With the emergence of outcome-based pricing, organizations are taking a fresh look at how they measure the benefits of CRM systems. That conversation is leading to an even more important analysis of underlying business processes. Or, as Constellation’s Miller says, “The old adage of applying new technology to old processes only gets you more expensive old processes.”

“When we survey customers, we hear time and time again that the reason why they want to apply AI into their organizations is to foster exponential opportunity and exponential growth,” she says. “How do we get there with CRM has started to become the new conversation.”

According to Miller, AI systems breach the walls of siloed data and can take a fresh look at legacy workflows. They also don’t get sucked into turf wars between marketing and sales teams. As a result, they often recommend new actions that can lead to better processes. “I think it’s starting to happen. You’re starting to see applications where AI is beginning to accelerate decision-making and decision velocity,” she says.

“The next phase of maturity is going to be, how do we start to spread AI across our platforms so that we are seeing that holistic end-to-end relationship that we have always wanted to optimize. How do we thread that across platforms and across solutions. We’re starting to see organizations on the leading edge really start to pull those strategies together,” says Miller.

If you ask us in an official setting, our official position is that software engineering norms still apply. Rigorous CI/CD pipelines, elegant architectural patterns, and an unyielding commitment to maintainable code remain the standard. We will use weighty words like “determinism,” “scalability,” “idempotency,” and “domain-driven design.”

But behind closed doors, late at night, bathed in the glow of a dark-mode IDE, a different and more sordid reality is exposed. Hunched over the console with a manic gleam in the eye, the programmer has become power-drunk on LLMs. Like mad wizards casting spells, we summon the awesome powers of models and agents to satisfy our every programming whim—and commit acts of software engineering that would make Fred Brooks blush.

Let’s just be honest about what is actually happening.

Esoteric knowledge is superfluous

Forget OOP and FP. Forget the CAP theorem, the holy crusade of DRY, and the design patterns. Honestly, you can even forget what frameworks, runtimes, and deployment platforms you are using. The AI will figure out what is best to use and understand what is already in place. We have more mental bandwidth for working on our side project (a novel about AI taking over the world). 

Of course, I exaggerate. A little.

The docs are dead to us

We still say RTFM, but the truth is, we haven’t really read a page of vendor documentation since 2023. Stack Overflow, once our Internet Mecca, is a husk. When a package throws a weird exception, we don’t trace the execution path or read the release notes. We highlight the red text, copy the entire 200-line stack trace, dump it into the chat, and wait for the machine to spoon-feed us the solution.

Better yet, we just have the agentic IDE spot the error, divine a solution, and ask us if it’s OK. We might glance at the problem-solution description, if we have gone around the circle on the problem for a few cycles. Maybe. If we don’t have the agent set up for auto-confirm.

We used to buy heavy tomes like “Rust In Action” that were more like masonry blocks than literature. Now? We just ask an AI to transliterate our JavaScript logic into Rust. We are no longer engineers methodically learning a system. We are glorified copy-paste orchestrators hoping that the stochastic parrot behind the prompt guesses the syntax correctly.

We ignore how the back end is wired

We act like we meticulously designed the data flows, carefully crafted the relational constraints, and mindfully mapped the API relationships. The reality is rather more disturbing: We asked the AI to scaffold a modern deployment, hooked it up to a back-end database, and just sort of… ran it.

It created security rules we don’t fully understand. They do seem to work, however, which is nice. 

It generated a schema that we skimmed for about four seconds. It looks reasonable.

It wrote infrastructure-as-code scripts that provisioned cloud resources we are hoping don’t blow a hole in the budget. Presumably, whoever is in charge of that will manage it by stuffing the metrics into another chatbot.

We nodded, committed the code, and went to lunch. If management asked us to manually deploy the stack from scratch, configure the environment variables, and wire the API routes without our chat window, we would give them a vacant stare.

We understand that management is also using AI to manage the project.

Our tests are uncomfortably incestuous

Test-driven development (TDD) used to be a beautiful dream, ever just beyond reach. It made us feel glorious and despondent at turns. It would burden us with sprawling dependencies if implemented too religiously. (See The Grug Brained Developer in this regard.)

But now we can attain 95% test coverage almost effortlessly. Why not just add them in while we are auto-generating everything else?

We can now wax at length to anyone who will listen about our astounding test coverage and our automated quality assurance. Unit tests, integration tests, smoke tests, you name it. What we conveniently leave out is that the AI wrote the complex application logic, and then we asked the exact same AI to write the test suite to validate the code it just dreamed up.

It is a hermetically sealed loop of algorithmic self-congratulation. The mocks, the edge case, and the assertions are an echo chamber of the model’s original assumptions. The machine is grading its own homework, giving itself an A+.

And we are happy to accept this because, beautifully, when the code has to change, the AI will effortlessly hallucinate new tests to adapt to the churn.

We pass off the AI’s architecture as strategy

AI can produce astonishing design documents. Truly breathtaking. They are cogent, they’re beautifully formatted, and they seamlessly bridge the gap between high-level business goals and granular technical specs. They even include those auto-generated sequence diagrams that wow management.

When we present these spotless architectural proposals in the Tuesday sprint planning meeting, we lean back, take a long sip of coffee, and humbly wave away the team’s praise.

What we don’t mention is that we spent exactly four seconds generating it.

Are these AI-generated documents just as liable as human ones to hide severe, mortal flaws in scope and alignment? Absolutely. They might contain a foundational logic bomb that will eventually doom the entire project. But the markdown is so crisp, and the bullet points are so persuasive, that the eye just glides right over it. We will never truly know the depth of the disaster until it is far too late. But hey, we’ll burn that bridge when production catches fire. Until then, we are strategic visionaries.

We’re addicted to vibe coding (but only in secret)

We loudly mock the term on social media. We roll our eyes in Slack channels when the kids on TikTok talk about vibe coding their new startups. We fiercely cling to our identities as hardened, serious developers who understand memory management, garbage collection, and bitwise operators. We are professionals, damn it.

But late at night, when the managers are asleep and no one is looking? We absolutely love it. We love just throwing a chaotic, half-baked thought at the canvas, pouring a drink, and watching the AI magically build a functioning user interface based entirely on our long-deferred whims. I may finally build that working Ultima V clone. The thrill of typing “Create an app that tracks my cryptocurrency portfolio but makes it look like the interface from Neuromancer” and having it appear 30 seconds later is heady stuff.

The more deeply rooted in the hard, old-school realities of programming, the more profound is the joy the developer finds in the possibility of AI coding. 

We beat the problem into submission with prompts

Like Adam Sandler in “Uncut Gems,” we are convinced the next round will fix everything. This is us with prompts. When things are going really off the rails, instead of putting our boots on and wading into the brambles of complexity, we resort to tonal adjustments. These range from the condescending:

This problem is not fixed. Look at it closely. The error is right here.

To the desperate:

We have been working on this same problem for hours now!

To the pathetic:

Can’t you find a different approach to try?!

The astonishing part? It often works.

But there is no poetry left at the bottom of the rabbit hole; it is verbal warfare. When the context window collapses, when the regressions start cascading, and when the AI stubbornly refuses to follow the most basic rules of temporal logic, the mask of professionalism drops away and something far more atavistic makes its appearance. We stop asking nicely, stop trying to understand the why, delete the pleasantries, and capslock our intent.

What we have here is a failure to communicate!

We feed the same failing stack trace back into the prompt over and over and over again, aggressively hammering the constraints, explicitly forbidding certain libraries, and pasting in release notes just to confirm that the AI lacks the latest APIs. We force the model down a narrower and narrower path until the code finally stops throwing errors. We don’t actually debug anymore, trace variables, or step through functions. We just apply relentless, iterative pressure until the machine surrenders. We beat it into submission. And then, we push to production.

In fact, there is a real skill here—a sheer “will to completion” that remains in the act of building software. We invest just as much time, energy, and heart wrestling the bot as we ever did emitting syntax.

A blacker box

The only profession more given over to using AI like a cursed Level 13 artifact than programming is writing. Writing of course is far more open to public scrutiny than code.

And while my tongue has been firmly in my cheek here, my faith in coders as good guys makes me more curious to see what we create than troubled by the dangers. 

It was once the case that only other programmers could understand what programmers were doing, what they were producing. Now not even that is true. Only the machine knows what the machine is doing. We just keep it tethered to our aims. Hopefully.

As AI use ratchets up, demand for data center capacity is higher than it’s ever been. But New York State is telling the industry: Not so fast.

New York Governor Kathy Hochul this week signed an Executive Order described as the “nation’s first moratorium” on new hyperscale data centers, massive factories that typically comprise thousands of servers devouring tens or hundreds of megawatts of power.

During this up to one year pause, the state will halt issuance of environmental permits for data centers as it develops a regulatory framework to protect ratepayers, the energy grid, the environment, and local communities.

Like other states, New York is seeing “unprecedented” demand for data center development that would ultimately require “massive amounts” of energy and water, Hochul noted. And community backlash seems to be accelerating at the same pace.

This is “a symptom of a bigger, nationwide issue,” said Matt Kimball, VP and principal analyst for data center technologies at Moor Insights & Strategy. “Compute demand is far outpacing the grid,” prompting state and local leaders to pause and figure out how to manage things more effectively.

Creating a blueprint for local development, community support

New York already requires data centers to pay more for energy, or to supply their own, to keep costs affordable for residents. Hochul also plans to pursue legislation that would repeal sales tax exemptions for massive data centers already existing in the state.

During the moratorium, New York will develop a “Generic Environmental Impact Statement” (GEIS) to assess the potential environmental impacts of data center construction and operation, including their water and energy demands and impact on air quality. Once it’s lifted, new data center projects will only be allowed to proceed if they strictly observe state, zoning, and other local approvals.

On a shorter 60-day timeline, the state will issue a Community Investment Framework (CIF) to provide guidance to local governments negotiating large-scale data center deals, and to ensure operators are investing in and partnering with host communities and workforces. This will set standardized expectations for projects and establish baseline thresholds for data center operators’ investment into local communities.

Notably, New York is proposing a contribution of $1 million per megawatt (MW) of anticipated utility demand per project. Thus, 50 megawatts of use would require data center operators to reinvest $50 million into their host community; 400 megawatts would require $400 million.

The framework will include ‘Good Neighbor Commitments’ around landscaping, design, and mitigation of noise and light pollution; labor commitments to give organized labor “a seat at the table” to determine wage standards, local hiring, and workforce development; and a community investment fund to support the host community’s “long-term economic vitality and quality of life.”

Data center operators, for instance, could provide direct financial support to host communities, or invest in public infrastructure, housing improvements, workforce development and training programs, or in broadband expansion.

“Having a published playbook for how to make this work across a state versus having to negotiate this on a county-by-county basis should be a win for everybody,” Moor’s Kimball noted.

Separately, New York is also considering establishing a fund that would require data centers to invest in the state’s aging grid infrastructure and support new clean energy procurement.

What enterprises and other states should be watching

Realistically, a data center buildout takes anywhere from 3 to 5 years from the point of site selection to turning on the switch for the first time, Kimball pointed out. The one-year moratorium doesn’t do too much for that.

What matters more is what New York does during that pause, he noted, for example, establishing a regulatory framework to re-price the cost of hyperscale deployment, determining costs for grid upgrades or “bring your own power” expectations, developing requirements for more formalized operator contributions to the local community, or considering the repeal of tax exemptions.

“And really, this subsidizing angle is the biggest,” said Kimball. States across the country have been subsidizing buildouts to get data center business for years. “This could signal the beginning of the end of those subsidies for many states.”

For enterprise IT leaders, the headline is the signal that power and permitting are now “first-order variables” for infrastructure strategies, right alongside cost and latency requirements, said Kimball.

So, if an enterprise’s cloud or co-location strategy or roadmap assumes hyperlocal capacity, that assumption now carries some risk. CIOs and IT leaders should therefore work with providers to gain more clarity on regional capacity.

The moratorium could result in some “border-hopping,” with enterprises hosting local servers in adjacent states like Pennsylvania, Connecticut, or New Jersey, but that’s not likely to be widespread, Kimball noted.

The realistic regional impact will be “more of a slow squeeze rather than a shock,” he said. This could result in tighter colocation availability and firmer pricing in the New York Metropolitan area over the next few years. Cloud providers may also steer new AI capacity to regions like Georgia, Ohio, Texas, and Utah, where power and permitting are more predictable.

An inflection point, but more trickle-down than direct impact

Indeed, noted Jeremy Roberts, senior director for research and content at Info-Tech Research Group, the moratorium is an “inflection point” and a “way to placate an increasingly angry public,”.

People don’t like the fact that, beyond the initial build, data centers don’t create many jobs, they take up a lot of space, they use a significant amount of power and resources, and they can be “noisy and smelly.”

However, the impact of the moratorium is likely going to be “macro” for everyday enterprises, as New York is specifically targeting hyperscale data centers.

“If you were planning on building a data center in New York and your name is not [Microsoft CEO] Satya Nadella, it’s probably not going to affect you,” said Roberts.

But the consequences of the move will certainly trickle down, for instance, with AI device or hardware purchases supplanting software acquisition. Roberts pointed to IBM’s history-making stock plunge this week, which the company attributed to enterprise buyers diverting IT budgets away from software and mainframes to stockpile AI hardware like servers and memory chips to get ahead of anticipated supply issues and price increases.

If enterprises plan to invest in anything that uses storage or CPUs, they will be paying more in the future, Roberts said. “It’s a symptom of a problem you’re going to feel.”

That said, constraints usually inspire innovation; if a hyperscaler can’t build a 50MW data center, it will likely find ways to string together smaller data centers or adapt in other ways. This could “percolate” across the industry, Roberts said. “People are endlessly creative.”

As AI use ratchets up, demand for data center capacity is higher than it’s ever been. But New York State is telling the industry: Not so fast.

New York Governor Kathy Hochul this week signed an Executive Order described as the “nation’s first moratorium” on new hyperscale data centers, massive factories that typically comprise thousands of servers devouring tens or hundreds of megawatts of power.

During this up to one year pause, the state will halt issuance of environmental permits for data centers as it develops a regulatory framework to protect ratepayers, the energy grid, the environment, and local communities.

Like other states, New York is seeing “unprecedented” demand for data center development that would ultimately require “massive amounts” of energy and water, Hochul noted. And community backlash seems to be accelerating at the same pace.

This is “a symptom of a bigger, nationwide issue,” said Matt Kimball, VP and principal analyst for data center technologies at Moor Insights & Strategy. “Compute demand is far outpacing the grid,” prompting state and local leaders to pause and figure out how to manage things more effectively.

Creating a blueprint for local development, community support

New York already requires data centers to pay more for energy, or to supply their own, to keep costs affordable for residents. Hochul also plans to pursue legislation that would repeal sales tax exemptions for massive data centers already existing in the state.

During the moratorium, New York will develop a “Generic Environmental Impact Statement” (GEIS) to assess the potential environmental impacts of data center construction and operation, including their water and energy demands and impact on air quality. Once it’s lifted, new data center projects will only be allowed to proceed if they strictly observe state, zoning, and other local approvals.

On a shorter 60-day timeline, the state will issue a Community Investment Framework (CIF) to provide guidance to local governments negotiating large-scale data center deals, and to ensure operators are investing in and partnering with host communities and workforces. This will set standardized expectations for projects and establish baseline thresholds for data center operators’ investment into local communities.

Notably, New York is proposing a contribution of $1 million per megawatt (MW) of anticipated utility demand per project. Thus, 50 megawatts of use would require data center operators to reinvest $50 million into their host community; 400 megawatts would require $400 million.

The framework will include ‘Good Neighbor Commitments’ around landscaping, design, and mitigation of noise and light pollution; labor commitments to give organized labor “a seat at the table” to determine wage standards, local hiring, and workforce development; and a community investment fund to support the host community’s “long-term economic vitality and quality of life.”

Data center operators, for instance, could provide direct financial support to host communities, or invest in public infrastructure, housing improvements, workforce development and training programs, or in broadband expansion.

“Having a published playbook for how to make this work across a state versus having to negotiate this on a county-by-county basis should be a win for everybody,” Moor’s Kimball noted.

Separately, New York is also considering establishing a fund that would require data centers to invest in the state’s aging grid infrastructure and support new clean energy procurement.

What enterprises and other states should be watching

Realistically, a data center buildout takes anywhere from 3 to 5 years from the point of site selection to turning on the switch for the first time, Kimball pointed out. The one-year moratorium doesn’t do too much for that.

What matters more is what New York does during that pause, he noted, for example, establishing a regulatory framework to re-price the cost of hyperscale deployment, determining costs for grid upgrades or “bring your own power” expectations, developing requirements for more formalized operator contributions to the local community, or considering the repeal of tax exemptions.

“And really, this subsidizing angle is the biggest,” said Kimball. States across the country have been subsidizing buildouts to get data center business for years. “This could signal the beginning of the end of those subsidies for many states.”

For enterprise IT leaders, the headline is the signal that power and permitting are now “first-order variables” for infrastructure strategies, right alongside cost and latency requirements, said Kimball.

So, if an enterprise’s cloud or co-location strategy or roadmap assumes hyperlocal capacity, that assumption now carries some risk. CIOs and IT leaders should therefore work with providers to gain more clarity on regional capacity.

The moratorium could result in some “border-hopping,” with enterprises hosting local servers in adjacent states like Pennsylvania, Connecticut, or New Jersey, but that’s not likely to be widespread, Kimball noted.

The realistic regional impact will be “more of a slow squeeze rather than a shock,” he said. This could result in tighter colocation availability and firmer pricing in the New York Metropolitan area over the next few years. Cloud providers may also steer new AI capacity to regions like Georgia, Ohio, Texas, and Utah, where power and permitting are more predictable.

An inflection point, but more trickle-down than direct impact

Indeed, noted Jeremy Roberts, senior director for research and content at Info-Tech Research Group, the moratorium is an “inflection point” and a “way to placate an increasingly angry public,”.

People don’t like the fact that, beyond the initial build, data centers don’t create many jobs, they take up a lot of space, they use a significant amount of power and resources, and they can be “noisy and smelly.”

However, the impact of the moratorium is likely going to be “macro” for everyday enterprises, as New York is specifically targeting hyperscale data centers.

“If you were planning on building a data center in New York and your name is not [Microsoft CEO] Satya Nadella, it’s probably not going to affect you,” said Roberts.

But the consequences of the move will certainly trickle down, for instance, with AI device or hardware purchases supplanting software acquisition. Roberts pointed to IBM’s history-making stock plunge this week, which the company attributed to enterprise buyers diverting IT budgets away from software and mainframes to stockpile AI hardware like servers and memory chips to get ahead of anticipated supply issues and price increases.

If enterprises plan to invest in anything that uses storage or CPUs, they will be paying more in the future, Roberts said. “It’s a symptom of a problem you’re going to feel.”

That said, constraints usually inspire innovation; if a hyperscaler can’t build a 50MW data center, it will likely find ways to string together smaller data centers or adapt in other ways. This could “percolate” across the industry, Roberts said. “People are endlessly creative.”

This article originally appeared on NetworkWorld.

For a decade, Kubernetes was the right answer. It organized containers, scaled services horizontally and gave platform teams a shared vocabulary for running software in production. It abstracted away enough of the underlying complexity that engineers could stop thinking about servers and start thinking about services. Most cloud-native infrastructure today is built on top of it, directly or in spirit, and EKS made that model the default for the majority of enterprise teams running workloads on AWS.

The workload that defined that era was the stateless HTTP request, fast in, fast out, disposable. A user action triggers a request, the request hits a service, the service returns a response and the container is done. Kubernetes was optimized for that pattern down to the scheduler internals: Bin-pack containers onto nodes, autoscale on CPU and memory, evict and reschedule when something goes wrong. The whole system is tuned around the assumption that individual units of work are short, stateless and interchangeable.

That assumption no longer holds for the workloads that matter most right now.

The agent workload is structurally different

Agents are long-running, stateful processes. They reason across time, call external tools, spawn subprocesses, write and execute code, and make decisions that depend on what happened five steps earlier in the same task. A single-agent workflow might run for minutes or hours, touching a dozen external systems and generating intermediate outputs that subsequent steps depend on. The compute layer for that kind of work needs to do things the old model was never asked to do. That is the new pattern: Execution infrastructure designed around agent semantics rather than request semantics.

The Kubernetes community itself has acknowledged this mismatch. In March 2026, Kubernetes SIG Apps published an introduction to Agent Sandbox, a new CRD-based abstraction designed specifically for singleton, stateful agent workloads. The framing is direct: The ecosystem is moving from short-lived, isolated tasks to deploying multiple, coordinated AI agents that run continuously, and mapping those workloads to traditional Kubernetes primitives requires an entirely new abstraction. The fact that the Kubernetes maintainers built a dedicated primitive for this, rather than recommending teams compose one from existing resources, is itself the clearest signal that agent execution does not fit the old model.

What agent execution actually requires

Concretely, it requires four things. First, isolated execution environments that provision in milliseconds, not minutes, so each agent task gets its own sandbox for code execution and tool calls without blocking the reasoning loop. The difference between a two-second environment and a two-minute environment is not a performance optimization; it determines whether the architecture is viable at all. Second, durable state management across the full task lifecycle, so an agent can pause, hand off or resume without re-initializing from scratch and burning tokens to reconstruct context it already built. Third, coordination primitives for multi-agent work: The ability to spawn subagents, pass structured outputs between them and track task dependencies across a graph of concurrent processes. Production agent systems are rarely single agents; they are pipelines of specialized agents with handoffs that need to be reliable and inspectable. Fourth, credentials and secrets management that travel with the execution context, so agents can authenticate to external services securely without exposing credentials in the task definition, logs or the environment variables of a shared container.

The mismatch shows up fast in production

Kubernetes and EKS expose the mismatch quickly in practice. Pod eviction terminates an agent mid-task with no clean recovery path. Autoscaling reads CPU utilization as the load signal, but an agent holding a long inference connection looks idle to the scheduler even when it is doing the most consequential work in the pipeline. Provisioning a new environment takes 45 seconds to two minutes on a well-tuned cluster; agent workloads need that in under two seconds or the reasoning loop stalls and the user experience degrades visibly. These are not edge cases or misconfigurations. They are the normal operating conditions for production agent workloads running on infrastructure that was not designed for them.

The utilization data makes the broader cost picture even starker. The 2026 State of Kubernetes Optimization Report from CAST AI, drawn from analysis of over 23,000 production clusters across AWS, Azure and GCP, found average CPU utilization at 8 percent, down from 10 percent the year prior. Memory utilization fell from 23 to 20 percent. CPU overprovisioning jumped from 40 to 69 percent year over year. These numbers reflect clusters running traditional workloads, and the pattern is worsening, not improving, as environments scale. Agent workloads compound this problem further. An agent holding an open inference connection or waiting on a tool call registers as idle to a scheduler that reads CPU and memory as the only meaningful load signals. The infrastructure responds to the wrong metric, overprovisioning capacity for demand it cannot measure, while the actual bottleneck, environment provisioning latency and state continuity, goes unaddressed.

Security is not the same problem it was before

Agent workloads change the threat model at the infrastructure level. A compromised stateless service exposes a narrow surface defined by its API contracts. A compromised agent exposes every system it can reach, every credential it holds and every action it is authorized to take on behalf of the user. Agents generate and execute their own code, make non-deterministic tool-call decisions and accumulate context across long-running sessions. Standard container namespacing does not contain that kind of risk. Kernel-level isolation, default-deny network egress, scoped credentials per session and agent-aware observability are not optional hardening steps. They are baseline requirements for running agents in production.

What teams that ship agents have already figured out

Some of the clearest evidence for this shift comes not from infrastructure vendors but from product engineering teams running agents at scale on their own code. In late 2025, Ramp’s engineering team published a detailed account of building Inspect, their internal background coding agent. Each Inspect session runs in a sandboxed VM with a full-stack development environment and deep integrations across their observability, CI, and deployment tooling. The architecture requirements map almost exactly to the four primitives above. Filesystem snapshots keep sessions starting in seconds rather than minutes. Sessions are isolated and stateful. The agent can run tests, review telemetry, query feature flags and visually verify frontend changes in a real browser. And the whole system supports unlimited concurrency, so engineers can spin up ten parallel sessions exploring different approaches to the same problem without contention.

The results speak for themselves. Within months of launch, roughly 30 percent of all pull requests merged to Ramp’s frontend and backend repositories were written by Inspect. That level of adoption was not mandated. It happened because the execution environment was fast enough, capable enough and well-integrated enough that the agent was strictly better than a local workflow for a meaningful share of tasks. The key insight from the Ramp case is not about the model. It is about the execution layer. As their team put it, session speed should only be limited by model-provider time-to-first-token; everything else, like cloning and installing, needs to be done before the session starts. That is a statement about infrastructure, not intelligence.

The ecosystem is catching up, but defaults are sticky

None of that is a criticism of the tools. Kubernetes solved exactly the problem it was designed for, and it solved it well. The issue is that infrastructure defaults are sticky. Teams inherit them, build on top of them and optimize within their constraints long after the underlying workload has changed. The Kubernetes community’s own response, the Agent Sandbox project under SIG Apps, validates the thesis that a new abstraction is necessary. The new primitives the community is building include warm pools for near-zero cold starts, lifecycle management for suspending and resuming idle agents without losing state, and pluggable kernel isolation for secure execution of untrusted code. These are not incremental improvements to existing resources. They are net-new abstractions that acknowledge the old model does not stretch to fit.

But adoption of purpose-built agent infrastructure remains early. Enterprises building agent pipelines today are largely running a request-oriented orchestration model against an execution-oriented workload, and the mismatch shows up in task failure rates, runaway costs and debugging cycles that have no good tooling because the observability layer was also designed for stateless services.

The structural advantage is available now

The infrastructure to close that gap exists now. The prerequisite is recognizing that agent execution is a first-class compute pattern with its own primitives and its own requirements, not a variant of the stateless service model that defined the last decade. Teams that make that shift early will have a meaningful structural advantage. The ones that do not will spend the next two years wondering why their agent systems are unreliable at a scale that should be tractable.

This article is published as part of the Foundry Expert Contributor Network.
Want to join?

Visual Studio Code 1.128, the most recent edition of Microsoft’s code editor, adds support for multi-chat agent sessions using Anthropic Claude agents.

Introduced July 8, VS Code 1.28 can be downloaded for Windows, Linux, or Mac from code.visualstudio.com.

With VS Code 1.28, multi-chat agent sessions now support using Anthropic Claude agents. With multiple chats, a session can contain related chats, allowing users to compare approaches, branch from an earlier turn, and run work in parallel. Users can add chats, fork a chat from an existing turn, switch between peer chats, and send turns concurrently. Each chat keeps its own history, title, and model selection, and restores with the parent session after restart, Microsoft said.

VS Code 1.28 also makes Copilot Vision generally available. With Copilot Vision, VS Code users can attach images and PDFs by pasting them into chat, dragging and dropping them, or using the context menu. Images also may be read by the agent via a tool call, Microsoft said.

Also in VS Code 1.28:

• Quick chats allow users to ask a question in the Agents window without opening a workspace first.
• VS Code can contribute OS-level keyboard shortcuts that take effect even if VS Code is not in focus. Users can add systemWide to a keybinding definition in keybindings.json to make it OS-level.
• Developers can configure a location for browser tabs to open via a new setting, workbench.browser.newTabPlacement. The setting provides three options: to open browser tabs in the active editor group, in a dedicated group to the side, or in a dedicated auxiliary window.
• VS Code can contribute OS-level keyboard shortcuts. These shortcuts take effect even if VS Code is not in focus.
• Administrators can configure where GitHub Copilot sends OpenTelemetry (OTel) data, allowing organizations to enforce telemetry flows to an approved collector without each developer setting OTEL_* environment variables. The managed configuration applies to both the Copilot Chat extension and the agent host process.

These days, application developers can take their pick from a vast menu of architectural solutions. We can choose from the well-understood to the experimental, and from blended solutions in between. Several powerful middle-ground technologies that emerged during the cloud revolution have really come of age. Here we’ll take a look at putting together three of the most impressive: GitHub, Vercel, and Firestore.

Each of these is an important tool in its own right that can be used to attack specific problems. In combination, they not only meet the needs of several important application scenarios, but they have a superpower—the ability to dramatically shorten the distance between development and deployment.

There is nothing quite as gratifying as putting your hands on just the right mix of tools for a given need.

A ‘no-ops’ stack built for speed

If your primary goal is sheer development velocity, you would be hard-pressed to top this architecture. This “no-ops” stack collapses the distance between your local IDE and a globally distributed production environment. You are essentially trading the overhead of managing VMs and load balancers for the sheer speed of committing code and watching it deploy automatically.

While each component is highly flexible, adopting them requires a specific, event-driven mindset. There are a few finicky bits to manage, mostly around routing environment variables securely and designing around stateless back-end functions. But the constraints are obvious and well-documented.

Before we look more closely, let’s quickly identify the kinds of apps that are a perfect fit here, along with those that are workable and those that really merit a different approach.

• The sweet spot (deploy and go): AI-mediated applications, asynchronous game back ends, and real-time collaborative B2B dashboards. This architecture perfectly absorbs the unpredictable latency of LLM APIs and instantly syncs state across multiple clients without requiring you to build custom WebSocket infrastructure.
• The middle ground (workable, with trade-offs): Headless e-commerce, moderate IoT telemetry, and apps requiring scheduled batch processing. You will encounter friction if your catalog relies on deeply relational SQL constraints, or if your background reporting jobs take longer than a few minutes and hit serverless execution limits.
• The danger zone (look elsewhere): High-frequency trading, fast-paced action multiplayer games, heavy data ETL pipelines, and core financial ledgers. Serverless architectures cannot natively hold open the persistent WebSockets required for twitch-reflex data, and heavy compute tasks will abruptly time out.

We should mention that these categories are not mutually exclusive. Many enterprise applications, such as a full-scale e-commerce platform, straddle these lines. You might use Vercel and Firestore to build a lightning-fast, reactive storefront that handles ephemeral user state like shopping carts, while simultaneously “stitching in” a managed SQL database like Supabase or PlanetScale. This hybrid approach allows you to maintain the relational integrity required for back-office inventory and financial ledgers and pair it with the front-end velocity this stack provides.

GitHub: the bedrock

I don’t need to introduce you to GitHub. It is a central element of the development landscape. I still remember CVS and SVN with a certain nostalgia, but the enhancements of Git speak for themselves. When combined with the orchestration powers of GitHub, it is no wonder that virtually the whole industry has adopted this type of platform.

Git plus GitHub gives you an enormous amount of power already, in terms of how you can organize and automate your projects. But there is a next-level experience in combining GitHub and Vercel. For JavaScript-based projects, you can take simple GitHub pushes and turn them into instantly deployed clients and serverless functions. It is one of the cleanest and least fiddly ways to move from raw code on your local machine to a globally deployed, full-stack architecture.

Vercel: the nexus

Vercel is more than just a deployment host. It is a control plane that ties this high-velocity, no-ops architecture together. Alongside GitHub and Firestore, Vercel’s deeper strength is its ability to act as an orchestration layer between your reactive front end and external stateful services.

Vercel has a great amount of facility in fine-tuning what branches go to what environment and helpful features like instant rollback. You can just log into Vercel’s dashboard for your project and see the history of deployments and any errors and logs. It’s a simple menu choice to roll back to a historical version or compare one version against another.

When you “stitch in” third-party services (such as a managed SQL database like Supabase or a payment processor like Stripe), Vercel’s serverless functions become the lightweight interface, and Vercel’s the adapters handle the communication. You offload the integration logic (the service layer) to Vercel’s global Edge Network, keeping your UI and back end clean, responsive, and decoupled. 

In short, Vercel allows you to get the speed of the “no-ops” development life cycle without sacrificing the complex transactional integrity required for some applications like enterprise inventory systems.

Firestore: the datastore

Firestore is an extremely lightweight, NoSQL, cloud datastore. It has a great deal of add-on power, but its core value proposition is that it accepts virtually any data you stuff into it and it provides event-driven subscriptions to data changes.

These two capabilities together make Firestore about as straightforward a solution to a managed back end as you can imagine. You subscribe to collections or even fields and then you simply stick “unstructured” data (read: JSON with variable fields) in and the client waits for the changes it is interested in.

This is so streamlined that one can just point the browser (or native mobile app) directly at Firestore and listen for events. Which immediately raises the question of identity, for auth and for data visibility, but hold on—Firestore’s third superpower is that it has an authentication module that actually works. What I mean is, it is actually pretty simple and yet confidently secures your app.

Sometimes auth solutions seem either too simple (and yet opaque) or too mired in the nitty gritty. Firestore auth will let you do some basic configuration and start using a reasonable auth almost immediately. 

Not to belabor the point, but having a realistic and attainable auth solution elevates your stack to a production grade—one that can handle many real-world applications. Firestore auth plays nicely with other important APIs, like Stripe. Typically, auth is a major feature that feels like off-roading in a Honda Civic, but Firestore’s approach to auth, added to this particular stack, feels like a normal speed bump. It’s just another component you plug in, rather than a tentacled alien you weave into the your code.

The limits of the velocity stack

This architecture combines components that are optimized for flexibility. That same character also introduces distinct limitations. Understanding these is essential before committing production workloads.

The serverless life cycle

Serverless functions are spun up to handle requests. They close out soon afterward and lose any state. For that reason, they cannot natively hold open persistent WebSockets. If your system requires continuous, sub-millisecond, bidirectional streams—like a real-time multiplayer action game or a high-frequency trading dashboard—pure serverless will fight you all the way. You are forced to introduce a third-party managed WebSocket service to route messages back to your stateless endpoints via HTTP webhooks.

The execution time ceiling

Vercel (like all serverless platforms) enforces strict timeouts on operations. While enterprise tiers might grant you up to 15 minutes, standard functions often time out after 10 to 60 seconds. Long-running tasks like video transcoding, database scripts, or orchestrating multi-step AI agent workflows, which might take 20 minutes to resolve, will run up against these limits. Heavy-lifting tasks must be offloaded to a dedicated, long-running service like Google Cloud Run, or broken into smaller, asynchronous chunks via message queues.

The cold start reality

While the industry has made massive strides in minimizing initialization times—particularly with lightweight edge networks—traditional Node.js-based serverless functions still experience cold starts. If a function has not been invoked recently, or if traffic spikes require a new instance to spin up concurrently, the first request will take a noticeable latency hit as the container provisions and the code loads.

API instead of RAM

In a traditional server environment, you can store transient data in global RAM, allowing subsequent requests to access shared context instantly. In the serverless model, every request might hit a fresh container. Therefore, all shared context must be externalized. Although Firestore serves brilliantly as the state manager, relying on a database for high-frequency, sub-millisecond, ephemeral caching introduces network latency and per-operation costs. That said, using a shared RAM state on a server is non-trivial also, unless you are using a single app server and VM (because high-availability or fail-over requirements will lessen the RAM win on a traditional server).

Tuning for velocity and control

Every architectural decision is a trade-off. There are no cost-free choices. By adopting the GitHub, Vercel, and Firestore stack, you are explicitly maximizing feature velocity over fine-grained control.

You lose the ability to tweak the underlying operating system, hold open persistent sockets, or run hour-long back-end scripts. In exchange, you gain an architecture that scales from zero to global distribution instantly, requires virtually no devops maintenance, and perfectly absorbs the asynchronous, event-driven realities of modern application development.

For the right application—whether it is a fast-moving prototype or an enterprise AI copilot—this stack doesn’t just save time; it fundamentally changes how quickly a small team (or a single person) can impact the market. You stop worrying about build chains, load balancers, and server patches, and you focus on the central mission: shipping features.

Everything in Python is an object, or so the saying goes. If you want to create your own custom objects, with their own properties and methods, you use Python’s class object to do it. But creating classes in Python sometimes means writing loads of repetitive, boilerplate code; for example, to set up the class instance from the parameters passed to it or to create common functions like comparison operators.

Dataclasses, introduced in Python 3.7 (and backported to Python 3.6), provide a handy, less-verbose way to create classes. Many of the common things you do in a class, like instantiating properties from the arguments passed to the class, can be reduced to a few basic instructions by using dataclasses.

The backstage power of Python dataclasses

Consider this example of a conventional class in Python:

class Book:
    '''Object for tracking physical books in a collection.'''
    def __init__(self, name: str, weight: float, shelf_id:int = 0):
        self.name = name
        self.weight = weight # in grams, for calculating shipping
        self.shelf_id = shelf_id
    def __repr__(self):
        return(f"Book(name={self.name!r},
            weight={self.weight!r}, shelf_id={self.shelf_id!r})")

The biggest headache here is that you must copy each of the arguments passed to __init__ to the object’s properties. This isn’t so bad if you’re only dealing with Book, but what if you have additional classes—say, a Bookshelf, Library, Warehouse, and so on? Plus, typing all that code by hand increases your chances of making a mistake.

Here’s the same class implemented as a Python dataclass:

from dataclasses import dataclass

@dataclass
class Book:
    '''Object for tracking physical books in a collection.'''
    name: str
    weight: float 
    shelf_id: int = 0

When you specify properties, called fields, in a dataclass, the @dataclass decorator automatically generates all the code needed to initialize them. It also preserves the type information for each property, so if you use a linting too that checks type information, it will ensure that you’re supplying the right kinds of variables to the class constructor.

Another thing @dataclass does behind the scenes is to automatically create code for common dunder methods in the class. In the conventional class above, we had to create our own __repr__. In the dataclass, the @dataclass decorator generates the __repr__ for you. While you still can override the generated code, you don’t need to manually write code for the most common cases.

Once a dataclass is created, it is functionally identical to a regular class. There is no performance penalty for using a dataclass. There’s only a small performance penalty for declaring the class as a dataclass, and that’s a one-time cost when the dataclass object is created.

Advanced Python dataclass initialization

The dataclass decorator can take initialization options of its own. Most of the time, you won’t need to supply them, but they can come in handy for certain edge cases. Here are some of the most useful ones (they’re all True/False):

• frozen: Generates class instances that are read-only. Once data has been assigned, it can’t be modified. This is useful if instances of the dataclass are intended to be hashable, which allows them (among other things) to be used as dictionary keys. If you set frozen, the generated dataclass will also automatically have a __hash__ method created for it. (You also can use unsafe_hash=true to generate a __hash__ method for the dataclass, regardless of whether the dataclass is read-only or not, but that call invokes unsafe behavior.)
• slots: Allows instances of dataclasses to use less memory by only allowing fields explicitly defined in the class. The memory savings really only manifest at scale — e.g., when generating upwards of thousands of instances of a given object. If you’re only generating a couple of dataclass instances at a time, it probably isn’t worth it.
• kw_only: This setting makes all fields for the class keyword-only, so they must be defined using keyword arguments rather than positional arguments. This is a useful way to provide a dataclass instance’s arguments by way of a dictionary.

Customizing Python dataclass fields

How dataclasses work by default should be okay for the majority of use cases. Sometimes, though, you need to fine-tune how the fields in your dataclass are initialized. The following code sample demonstrates how to use the field function for fine-tuning:

from dataclasses import dataclass, field
from typing import List

@dataclass
class Book:
    '''Object for tracking physical books in a collection.'''
    name: str     
    condition: str = field(compare=False)    
    weight: float = field(default=0.0, repr=False)
    shelf_id: int = 0
    chapters: List[str] = field(default_factory=list)

When you set a default value to an instance of field, it changes how the field is set up depending on what parameters you provide. These are the most commonly-used options for field (though there are others):

• default: Sets the default value for the field. You should use default if you a) use field to change any other parameters for the field, and b) want to set a default value on the field on top of that. In the above example, we used default to set weight to 0.0.
• default_factory: Provides the name of a function, which takes no parameters, that returns some object to serve as the default value for the field. In the example, we wanted chapters to be an empty list.
• repr: By default (True), controls if the field in question shows up in the automatically generated __repr__ for the dataclass. In this case, we didn’t want the book’s weight shown in the __repr__, so we used repr=False to omit it.
• compare: By default (True), includes the field in the comparison methods automatically generated for the dataclass. Here, we didn’t want condition to be used as part of the comparison for two books, so we set compare=False.

Note that we adjusted the order of the fields so the non-default fields appeared first.

Controlling Python dataclass initialization

At this point, you might be wondering, “How do I get control over the init process to make more fine-grained changes if the __init__ method of a dataclass is generated automatically?” In these cases, you can use the __post_init__ method or or InitVar type.

__post_init__

If you include the __post_init__ method in your dataclass definition, you can provide instructions for modifying fields or other instance data:

from dataclasses import dataclass, field
from typing import List

@dataclass
class Book:
    '''Object for tracking physical books in a collection.'''
    name: str    
    weight: float = field(default=0.0, repr=False)
    shelf_id: Optional[int] = field(init=False)
    chapters: List[str] = field(default_factory=list)
    condition: str = field(default="Good", compare=False)

    def __post_init__(self):
        if self.condition == "Discarded":
            self.shelf_id = None
        else:
            self.shelf_id = 0

In this example, we’ve created a __post_init__ method to set shelf_id to None if the book’s condition is initialized as "Discarded". Note how we use field to initialize shelf_id, and pass init as False to field. This means shelf_id won’t be initialized in __init__, but it is registered as a field with the dataclass overall, with type information.

InitVar

Another way to customize Python dataclass setup is to use the InitVar type. This lets you specify a field that will be passed to __init__ and then to __post_init__, but won’t be stored in the class instance.

By using InitVar, you can take in parameters when setting up the dataclass that are only used during initialization. Here’s an example:

from dataclasses import dataclass, field, InitVar
from typing import List

@dataclass
class Book:
    '''Object for tracking physical books in a collection.'''
    name: str     
    condition: InitVar[str] = "Good"
    weight: float = field(default=0.0, repr=False)
    shelf_id: int = field(init=False)
    chapters: List[str] = field(default_factory=list)

    def __post_init__(self, condition):
        if condition == "Unacceptable":
            self.shelf_id = None
        else:
            self.shelf_id = 0

Setting a field’s type to InitVar (with its subtype being the actual field type) signals to @dataclass to not make that field into a dataclass field, but to pass the data along to __post_init__ as an argument.

In this version of our Book class, we’re not storing condition as a field in the class instance. We’re only using condition during the initialization phase. If we find that condition was set to "Unacceptable", we set shelf_id to None—but we don’t store condition itself in the class instance.

When to use Python dataclasses, and when not to

One common scenario for using dataclasses is to replace the namedtuple. Dataclasses offer the same behaviors and more, and they can be made immutable (as namedtuples are) by simply using @dataclass(frozen=True) as the decorator.

Another possible use case is replacing nested dictionaries (which can be clumsy) with nested instances of dataclasses. If you have a dataclass Library, with a list property of shelves, you could use a dataclass ReadingRoom to populate that list, then add methods to make it easy to access nested items (e.g., a book on a shelf in a particular room).

It’s also important to note, though, that not every Python class needs to be a dataclass. If you’re creating a class mainly to group together a bunch of static methods, rather than as a container for data, you don’t need to make it a dataclass. For instance, a common pattern with parsers is to have a class that takes in an abstract syntax tree, walks the tree, and dispatches calls to different methods in the class based on the node type. Because the parser class has very little data of its own, a dataclass isn’t useful here.

Over its more than 15 years in the wild, Google’s Go programming language has evolved from a curiosity for alpha geeks to the battle-tested programming language behind some of the world’s most important cloud-native software projects.

If you’ve ever wondered why Go is the language of choice for projects like Docker and Kubernetes, this article is for you. We’ll discuss Go’s defining characteristics and how it differs from other programming languages. You will also learn what kinds of projects Go is best suited for, including the state of Go development for AI-powered tools. We’ll conclude with an overview of Go’s feature set, some limitations of the language, and where it may be going from here.

Also see: Golang tutorial: Get started with the Go language.

Go is small and simple

Go, or Golang as it’s often called, was created by Google employees—chiefly longtime Unix guru and Google distinguished engineer Rob Pike—but it’s not strictly speaking a “Google project.” Rather, Go is a community-developed open source project, spearheaded by leadership with strong opinions about how Go should be used and the direction the language should take.

Go is meant to be easy to learn and straightforward to use, with syntax that is simple to read and understand. Go does not have a large feature set, especially when compared to languages like C++. Go’s syntax is reminiscent of C, making it relatively easy for longtime C developers to learn. That said, many features of Go, especially its concurrency and functional programming features, harken back to languages like Erlang.

As a C-like language for building and maintaining cross-platform enterprise applications of all sorts, Go has much in common with Java. And as a means for enabling rapid development of code that might run anywhere, you could draw a parallel between Go and Python, though the differences outweigh the similarities.

The Go documentation describes Go as “a fast, statically typed, compiled language that feels like a dynamically typed, interpreted language.” Even a large Go program will compile in a matter of seconds. Plus, Go avoids much of the overhead of C-style include files and libraries.

Advantages of the Go language

Go is a versatile, convenient, fast, portable, interoperable, and widely supported modern language. These characteristics have helped to make it a top choice for large-scale development projects. Let’s look more closely at each of these positive qualities of Go.

Go is versatile and convenient

Go has been compared to interpreted languages like Python in its ability to satisfy many common programming needs. Some of this functionality is built into the language itself, such as goroutines for concurrency and thread-like behavior, while additional capabilities are available in Go standard library packages, like the http package. Like Python, Go provides automatic memory management capabilities including garbage collection.

Unlike interpreted languages, however, Go code compiles to a fast-running native binary. And unlike C or C++, Go compiles extremely fast—fast enough to make working with Go feel more like working with an interpreted language than a compiled one. Further, the Go build system is less complex than those of other compiled languages. It takes few steps and little bookkeeping to build and run a Go project.

Go is faster than many other languages

Go binaries run more slowly than their C counterparts, but the difference in speed is negligible for most applications. Go performance is as good as C for the vast majority of work, and generally much faster than other languages known for speed of development—including JavaScript, Python, and Ruby.

Go is portable and interoperable

Executables created with the Go toolchain can stand alone, with no default external dependencies. The Go toolchain is available for a wide variety of operating systems and hardware platforms, and can be used to compile binaries across platforms. What’s more, Go delivers all of the above without sacrificing access to the underlying system. Go programs can talk to external C libraries or make native system calls. In Docker, for instance, Go interacts with low-level Linux functions, cgroups, and namespaces to work container magic.

Go is widely supported

The Go toolchain is freely available as a Linux, macOS, or Windows binary, or as a Docker container. Go is included by default in many popular Linux distributions, such as Red Hat Enterprise Linux and Fedora, making it somewhat easier to deploy Go source to those platforms. Support for Go is also strong across many third-party development environments, from Microsoft’s Visual Studio Code to ActiveState’s Komodo IDE.

Also see: 8 reasons developers love Go—and 8 reasons they don’t.

Optimal use cases for the Go language

No language is suited to every job, but some languages are suited to more jobs than others. Go shines brightest in cloud-native development projects, distributed network services, and for developing utilities and stand-alone tools. Let’s consider the qualities that make Go especially well-suited to each of these project types.

Cloud-native development

Go’s concurrency and networking features, and its high degree of portability, make it well-suited for building cloud-native apps. In fact, Go was used to build several cornerstones of cloud-native computing including Docker, Kubernetes, and Istio.

Distributed network services

Network applications live and die by concurrency, and Go’s native concurrency features—goroutines and channels, mainly—are well suited for such work. Consequently, many Go projects are for networking, distributed functions, and cloud services. These include APIs, web servers, Kubernetes-ready frameworks for microservices, and much more.

Utilities and standalone tools

Go programs compile to binaries with minimal external dependencies. That makes them ideally suited to creating utilities and other tools, because they launch quickly and can be readily packaged up for redistribution. One example is an access server called Teleport, which can be deployed on servers quickly by compiling it from source or downloading a prebuilt binary.

Limitations of the Go language

Now let’s consider some of the limitations of Go. For one, it omits many language features developers may desire. It also packs everything into its binaries, so Go programs can be large. Furthermore, Go’s garbage collection mechanism delivers automatic memory management at the cost of absolute performance. The language also lacks a standard toolkit for building GUIs, and it is unsuited to systems programming.

Let’s look at each of these issues in detail.

Go omits many desirable language features

Go’s opinionated set of features draws both praise and criticism. Go is designed to err on the side of being small and easy to understand, with certain features deliberately omitted. The result is that some features that are commonplace in other languages simply aren’t available in Go. This is purposeful, but it’s still a drawback for some types of projects.

One thing Go omits that you will find in other languages is macros, commonly defined as the ability to generate program code at compile time. C, C++, and (the rising star) Rust all have macro systems. Go does not have macros, or at least not of the same variety as those languages. What Go does have is a tool command, go generate, which looks for magic comments in Go source and executes them. This can be used to generate Go source code, or even run other commands, but its main use is to programmatically generate code, usually as a precursor to the build process. (Technical blogger Eli Bendersky explains the ‘go generate’ command in detail.)

Another longstanding complaint with Go was, until recently, the lack of generic functions, which allow a function to accept many different types of variables. Go’s development team held out against adding generics to the language for many years because they wanted a syntax and set of behaviors that complemented the rest of Go. But as of Go 1.18, released in early 2022, the language includes a syntax for generics. Because go generate and its code-generation abilities emerged as one possible way to partially address the lack of generics, this functionality is no longer as commonly used in Go.

The fact is that Go adds major language features rarely, and only after much consideration. This works to preserve broad compatibility across versions, but it comes at the cost of slower innovation.

Also see: What you need to know about Go, Rust, and Zig.

Go’s binaries are large

Another potential downside to Go is the size of the generated binaries. Go binaries are statically compiled by default, meaning that everything needed at runtime is included in the binary image. This approach simplifies the build and deployment process, but at the cost of a simple “Hello, world!” weighing in at around 1.5MB on 64-bit Windows. The Go team has been working to reduce the size of those binaries with each successive release. It is also possible to shrink Go binaries with compression or by removing Go’s debug information. This last option may work better for standalone distributed apps than for cloud or network services, where having debug information is useful if a service fails in place.

Go’s garbage collection is resource hungry

Yet another touted feature of Go, automatic memory management, can be seen as a drawback, as garbage collection requires a certain amount of processing overhead. By design, Go doesn’t provide manual memory management, and garbage collection in Go has been criticized for not dealing well with the kinds of memory loads that appear in enterprise applications.

That said, each new version of Go seems to improve the memory management features. For example, Go 1.8 brought significantly shorter lag times for garbage collection, and Go 1.25 introduced a new, experimental garbage collector. While Go developers can use manual memory allocation in a C extension, or by way of a third-party manual memory management library, most prefer native solutions.

Go doesn’t have a standard GUI toolkit

Most Go applications are command-line tools or network services. That said, various projects are working to bring rich GUIs for Go applications. There are bindings for the GTK and GTK3 frameworks. Another project is intended to provide platform-native UIs across platforms, although it focuses on Go 1.24 forward only. But no clear winner or safe long-term bet has emerged in this space. Also, because Go is platform-independent by design, it is unlikely any project in this vein will become a part of the standard package set.

You shouldn’t use Go for systems programming

Finally, although Go can talk to native system functions, it was not designed for developing low-level system components such as kernels, device drivers, or embedded systems. After all, the Go runtime and the garbage collector for Go applications are dependent on the underlying operating system. (Developers interested in a cutting-edge language for that kind of work might look into using Rust.)

The future of the Go language

Go’s development is turning more toward the wants and needs of its developer base, with Go’s minders changing the language to better accommodate this audience rather than leading by stubborn example. A case in point is generics, which were finally added to the language after much deliberation about the best way to do so.

The 2024 Go Developer Survey found developers were overall satisfied with Go. Challenges that surfaced were generally due to the verbosity of error handling, missing or immature frameworks, and using Go’s type system—areas ripe for future development.

Like most languages, Go has gravitated to a core set of use cases over time, finding its niche in network services. In the future, Go is likely to continue expanding its hold there. Other use cases cited in the developer survey include creating APIs or RPC services (74% of respondents), followed by CLI applications (63%), web services (45%), libraries/frameworks (44%), automation (39%), and data processing (37%). While only 4% of respondents mentioned using Go to develop AI technologies, those who did reported that Go was a strong platform for running AI-powered workloads in production. For those wanting to develop ML/AI with Go, lack of tooling (23%) and the fact that Python is the default choice for such work (16%) topped the reasons why.

It remains to be seen how far Go’s speed and development simplicity will take it into other use cases, especially those dominated by other languages and their existing use cases. Rust covers safe and fast systems programming (a space Go is unlikely to enter); Python is still a common default for ML/AI, prototyping, automation, and glue code; and Java remains a stalwart for enterprise applications.

But Go’s future as a major programming language is already assured—certainly in the cloud, where the speed and simplicity of Go ease the development of scalable infrastructure that can be maintained over the long run.

Also see: Go language evolving for future hardware, AI workloads.

Spring is a reliable and popular framework for building web and enterprise Java applications. In this article, you’ll learn how to unit test each layer of a Spring MVC application, using built-in testing tools from JUnit 5 and Spring to mock each component’s dependencies. In addition to unit testing with MockMvc, Mockito, and Spring’s TestEntityManager, I’ll also briefly introduce slice testing using the @WebMvcTest and @DataJpaTest annotations, used to optimize unit tests on web controllers and databases.

Also see: How to test your Java applications with JUnit 5.

Overview of testing Spring MVC applications

Spring MVC applications are defined using three technology layers:

• Controllers accept web requests and return web responses.
• Services implement the application’s business logic.
• Repositories persist data to and from your back-end SQL or NoSQL database.

When we unit test Spring MVC applications, we test each layer separately from the others. We create mock implementations, typically using Mockito, for each layer’s dependencies, then we simulate the logic we want to test. For example, a controller may call a service to retrieve a list of objects. When testing the controller, we create a mock service that either returns the list of objects, returns an empty list, or throws an exception. This test ensures the controller behaves correctly.

We’ll use Spring MVC to build and test a simple web service that manages widgets. The structure of the web service is shown here:

This is a classic MVC pattern. We have a widget controller that handles RESTful requests and delegates its business functionality to a widget service, which uses a widget repository to persist widgets to and from an in-memory H2 database.

Get the source: Download the source code for this article.

Unit testing a Spring MVC controller with MockMvc

Setting up a Spring MVC controller test is a two-step process:

• Annotate your test class with @WebMvcTest.
• Autowire a MockMvc instance into your controller.

We could annotate all our test classes with @SpringBootTest, but we’ll use @WebMvcTest instead. The reason is that the @WebMvcTest annotation is used for slice testing. Whereas @SpringBootTest loads your entire Spring application context, @WebMvcTest loads only your web-related resources. Furthermore, if you specify a controller class in the annotation, it will only load the specific controller you want to test. Testing a single “slice” of your application reduces both the amount of compute resources required to set up the test and the time required to run a test.

For example, when we test a controller, we’ll mock just the services it uses, and we won’t need any repositories at all. If we don’t need them, then we needn’t waste time loading them. Slice tests were created to make tests perform better and run faster.

Here’s the source code for the Widget class we’ll be managing:

package com.infoworld.widgetservice.model;
import jakarta.persistence.Entity;
import jakarta.persistence.GeneratedValue;
import jakarta.persistence.GenerationType;
import jakarta.persistence.Id;

@Entity
public class Widget {
    @Id
    @GeneratedValue(strategy = GenerationType.AUTO)
    private Long id;
    private String name;
    private int version;

    public Widget() {
    }

    public Widget(String name) {
        this.name = name;
    }

    public Widget(String name, int version) {
        this.name = name;
        this.version = version;
    }

    public Widget(Long id, String name, int version) {
        this.id = id;
        this.name = name;
        this.version = version;
    }

    public Long getId() {
        return id;
    }

    public void setId(Long id) {
        this.id = id;
    }

    public String getName() {
        return name;
    }

    public void setName(String name) {
        this.name = name;
    }

    public int getVersion() {
        return version;
    }

    public void setVersion(int version) {
        this.version = version;
    }
}

A Widget is a JPA entity that manages three fields:

• id is the primary key of the table, annotated with @Id and @GeneratedValue, with an automatic generation strategy.
• name is the name of the widget.
• version is the version of the widget resource. We’ll use this value to populate our eTag value and check it in our PUT operation’s If-Match header value. This ensures the widget being updated is not stale.

Here’s the source code for the controller we’ll be testing (WidgetController.java):

package com.infoworld.widgetservice.web;

import java.net.URI;
import java.net.URISyntaxException;
import java.util.List;
import java.util.Optional;
import com.infoworld.widgetservice.model.Widget;
import com.infoworld.widgetservice.service.WidgetService;
import org.springframework.beans.factory.annotation.Autowired;
import org.springframework.http.HttpStatus;
import org.springframework.http.ResponseEntity;
import org.springframework.web.bind.annotation.DeleteMapping;
import org.springframework.web.bind.annotation.GetMapping;
import org.springframework.web.bind.annotation.PathVariable;
import org.springframework.web.bind.annotation.PostMapping;
import org.springframework.web.bind.annotation.PutMapping;
import org.springframework.web.bind.annotation.RequestBody;
import org.springframework.web.bind.annotation.RequestHeader;
import org.springframework.web.bind.annotation.RestController;

@RestController
public class WidgetController {
    @Autowired
    private WidgetService widgetService;
    @GetMapping("/widget/{id}")
    public ResponseEntity getWidget(@PathVariable Long id) {
        return widgetService.findById(id)
                .map(widget -> {
                    try {
                        return ResponseEntity
                                .ok()
                                .location(new URI("/widget/" + id))
                                .eTag(Integer.toString(
                                               widget.getVersion()))
                                .body(widget);
                    } catch (URISyntaxException e) {
                        return ResponseEntity
                          .status(HttpStatus.INTERNAL_SERVER_ERROR)
                          .build();
                    }
                })
                .orElse(ResponseEntity.notFound().build());
    }
    @GetMapping("/widgets")
    public List getWidgets() {
        return widgetService.findAll();
    }
    @PostMapping("/widgets")
    public ResponseEntity createWidget(@RequestBody Widget widget)
    {
        Widget newWidget = widgetService.create(widget);
        try {
           return ResponseEntity
                   .created(new URI("/widget/" + newWidget.getId()))
                   .eTag(Integer.toString(newWidget.getVersion()))
                   .body(newWidget);
        } catch (URISyntaxException e) {
            return ResponseEntity
                    .status(HttpStatus.INTERNAL_SERVER_ERROR)
                    .build();
        }
    }

    @PutMapping("/widget/{id}")
    public ResponseEntity updateWidget(@PathVariable Long id,
                                          @RequestBody Widget widget,
                         @RequestHeader("If-Match") Integer ifMatch) {
        Optional existingWidget = widgetService.findById(id);
        return existingWidget.map(w -> {
            if (w.getVersion() != ifMatch) {
                return ResponseEntity.status(HttpStatus.CONFLICT)
                                     .build();
            }

            w.setName(widget.getName());
            w.setVersion(w.getVersion() + 1);

            Widget updatedWidget = widgetService.save(w);
            try {
                return ResponseEntity.ok()
                        .location(new URI("/widget/" + 
                                      updatedWidget.getId()))
                        .eTag(Integer.toString(
                                      updatedWidget.getVersion()))
                        .body(updatedWidget);
            } catch (URISyntaxException e) {
                throw new RuntimeException(e);
            }
        }).orElse(ResponseEntity.notFound().build());
    }

    @DeleteMapping("widget/{id}")
    public ResponseEntity deleteWidget(@PathVariable Long id) {
        Optional existingWidget = widgetService.findById(id);
        return existingWidget.map(w -> {
           widgetService.deleteById(w.getId());
           return ResponseEntity.ok().build();
        }).orElse(ResponseEntity.notFound().build());
    }
}

The WidgetController handles GET, POST, PUT, and DELETE operations, following standard RESTful principles, so we’re going to write tests for each operation.

The following source code shows the structure of our test class (WidgetControllerTest.java):

package com.infoworld.widgetservice.web;

@WebMvcTest(WidgetController.class)
public class WidgetControllerTest {
    @Autowired
    private MockMvc mockMvc;

    @MockitoBean
    private WidgetService widgetService;
}

I omitted the imports for readability, but the important thing to note is that the class is annotated with the @WebMvcTest annotation, and that we pass in the WidgetController.class as the controller we’re testing. This tells Spring to only load the WidgetController and no other Spring resources. The @WebMvcTest annotation includes other annotations, but the important one for our tests is @AutoConfigureMockMvc, which will cause Spring to create a MockMvc instance and add it to the application context. That lets us autowire it into our test class using the @Autowired annotation.

Next, we use the @MockitoBean annotation to use Mockito to create a mock implementation of the WidgetService, after which Spring will autowire it into the WidgetController class. This lets us control the behavior of the WidgetService for the WidgetController test cases we’re writing. Note that starting in Spring Boot version 3.4, @MockitoBean replaced @MockBean. Everything you know about @MockBean translates to using @MockitoBean—with some improvements.

Unit testing GET /widgets

Let’s start with the easiest test case, a test for GET /widgets:

@Test
void testGetWidgets() throws Exception {
    List widgets = new ArrayList();
    widgets.add(new Widget(1L, "Widget 1", 1));
    widgets.add(new Widget(2L, "Widget 2", 1));
    widgets.add(new Widget(3L, "Widget 3", 1));

    when(widgetService.findAll()).thenReturn(widgets);

    mockMvc.perform(get("/widgets"))
            .andExpect(status().isOk())
            .andExpect(jsonPath("$.length()").value(3))
            .andExpect(jsonPath("$[0].id").value(1L))
            .andExpect(jsonPath("$[0].name").value("Widget 1"))
            .andExpect(jsonPath("$[0].version").value(1));
};

The testGetWidgets() method creates a list of three widgets and then configures the mock WidgetService to return the list when its findAll() method is called. The WidgetControllerTest class statically imports the org.mockito.Mockito.when() method that accepts a method call, which in this case is widgetService.findAll(), and returns a Mockito OngoingStubbing instance. This OngoingStubbing instance exposes methods like thenReturn(), thenThrow(), thenCallRealMethod(), thenAnswer(), and then().

Here, we use the thenReturn() method to tell Mockito to return the list of widgets when the WidgetService’s findAll() method is called. The @MockitoBean annotation causes the mock WidgetService to be autowired into the WidgetController. So, when the getWidgets() method is called in response to a GET /widgets, it calls the WidgetService’s findAll() method and returns our list of widgets as a web response.

Next, we use MockMvc’s perform() method to execute a web request. This diagram shows the various classes that interact with the perform() method:

The perform() method accepts a RequestBuilder. Spring defines several built-in RequestBuilders that we can statically import into our tests, including get(), post(), put(), and delete(). The perform() method returns a ResultActions instance that exposes methods such as andExpect(), andExpectAll(), andDo(), and andReturn(). Here, we invoke the andExpect() method, which accepts a ResultMatcher.

A ResultMatcher defines a match() method that throws an AssertionError if the assertion fails. Spring defines several ResultMatchers that we can statically import:

• status() allows us to check the HTTP status code of response.
• content() allows us to check the content headers of the response, such as Content-Type.
• header() allows us to check any of the HTTP header values.
• jsonPath() allows us to inspect the contents of a JSON document.

After MockMvc performs a GET to /widgets, we expect the HTTP status code to be 200 OK. We can then use the jsonPath matcher to check the body results, using the following JSON path expressions:

• $.length(): The $ references the root of the JSON document. If the response is a list, then we can call the length() method to get the number of elements in the list.
• $[0].id: JSON path expressions for a list use an array syntax starting at 0. This expression gets the ID of the first element in the list.
• $[0].name: This expression gets the name of the first element and compares it to “Widget 1”.
• $[0].version: This expression gets the version of the first element and compares it to 1.

Unit testing the GET /widget/{id} handler

Here’s the source code to test the GET /coffee/{id} widget:

@Test
void testGetWidgetById() throws Exception {
    Widget widget = new Widget(1L, "My Widget", 1);          
    when(widgetService.findById(1L))
           .thenReturn(Optional.of(widget));

    mockMvc.perform(get("/widget/{id}", 1))
            // Validate that we get a 200 OK Response Code
            .andExpect(status().isOk())

            // Validate Headers
            .andExpect(content()
                      .contentType(MediaType.APPLICATION_JSON))
            .andExpect(header().string(HttpHeaders.LOCATION,
                                       "/widget/1"))
            .andExpect(header().string(HttpHeaders.ETAG, "\"1\""))

            // Validate content
            .andExpect(jsonPath("$.id").value(1L))
            .andExpect(jsonPath("$.name").value("My Widget"))
            .andExpect(jsonPath("$.version").value(1));
 }

This test method is very similar to the testGetWidgets() method, but with some notable changes:

• The GET URI is defined using a URI template. You can specify any number of variables enclosed in braces in the URI template and then send a list of arguments that will replace those variables in the order they appear in the template.
• We check that the returned Content-Type is “application/json”, which is a constant in the MediaType class. We access the content using the content() method, which returns a ContentResultMatchers instance that provides various methods, including contentType(), which allows us to validate the content headers.
• We check for specific header values using the header() method. The header() method returns a HeadersResultMatchers instance, which can check for header String, long, and date values, as well as checking to see whether or not specific headers exist. In this case, we use constants defined in the HttpHeaders class to check the location and eTag header values.
• We check the body of the response using JSON path expressions. In this case, we do not have a list of objects, so we can access the individual fields in the JSON document directly. For example, $.id retrieves the id field value in the root of the document.

Unit testing a GET /widget/{id} Not Found code

Next, we test the GET /widget/{id}, passing it an invalid ID so that it returns a 404 Not Found response code:

@Test
void testGetWidgetByIdNotFound() throws Exception {
   when(widgetService.findById(1L)).thenReturn(Optional.empty());

   mockMvc.perform(get("/widget/{id}", 1))
            // Validate that we get a 404 Not Found Response Code
            .andExpect(status().isNotFound());
}

The testGetWidgetByIdNotFound() method configures the mock WidgetService to return Optional.empty() when its findById() is called with a value of 1. We then perform a GET request to /widget/1, then assert that the returned HTTP status code is 404 Not Found.

Unit testing POST /widgets

Here’s how to test a Widget creation:

@Test
void testCreateWidget() throws Exception {
    Widget widget = new Widget(1L, "Widget 1", 1);
    when(widgetService.create(any())).thenReturn(widget);

    mockMvc.perform(post("/widgets")
            .contentType(MediaType.APPLICATION_JSON)
            .content("{\"name\": \"Widget 1\"}"))

            // Validate that we get a 201 Created Response Code
            .andExpect(status().isCreated())

            // Validate Headers
            .andExpect(content().contentType(
                                      MediaType.APPLICATION_JSON))
            .andExpect(header().string(HttpHeaders.LOCATION, 
                                       "/widget/1"))
            .andExpect(header().string(HttpHeaders.ETAG, "\"1\""))

            // Validate content
            .andExpect(jsonPath("$.id").value(1L))
            .andExpect(jsonPath("$.name").value("Widget 1"))
            .andExpect(jsonPath("$.version").value(1));

The testCreateWidget() method first creates a Widget to return when the WidgetService’s create() method is called with any argument. The any() matcher matches any argument and, because the createWidget() handler will create a new Widget instance, we will not have access to that instance when the test runs. We then invoke MockMvc’s perform() method to the ”/widgets” URI, sending the content body of a new widget named “Widget 1”, using the content() method. We expect a 201 Created HTTP response code, an “application/json” content type, a location header of “/widget/1”, and an eTag value of the String “1”. The body of the response should match the Widget we returned from the create() method, namely an ID of 1, a name of “Widget 1”, and a version of 1.

Unit testing PUT /widget

This code runs three tests for the PUT operation:

@Test
public void testSuccessfulUpdate() throws Exception {
    // Create a mock Widget when the WidgetService's findById(1L) 
    // is called
    Widget mockWidget = new Widget(1L, "Widget 1", 5);
    when(widgetService.findById(1L))
                      .thenReturn(Optional.of(mockWidget));

    // Create a mock Coffee that is returned when the 
    // CoffeeController saves the Coffee to the database
    Widget savedWidget = new Widget(1L, "Updated Widget 1", 6);
    when(widgetService.save(any())).thenReturn(savedWidget);

    // Execute a PUT /widget/1 with a matching version: 5
    mockMvc.perform(put("/widget/{id}", 1L)
                    .contentType(MediaType.APPLICATION_JSON)
                    .header(HttpHeaders.IF_MATCH, 5)
                    .content("{\"id\": 1, " +
                             "\"name\": \"Updated Widget 1\"}"))

            // Validate that we get a 200 OK HTTP Response
           .andExpect(status().isOk())

            // Validate the headers
           .andExpect(content()
                        .contentType(MediaType.APPLICATION_JSON))
           .andExpect(header().string(HttpHeaders.LOCATION, 
                                      "/widget/1"))
           .andExpect(header().string(HttpHeaders.ETAG, "\"6\""))

           // Validate the contents of the response
           .andExpect(jsonPath("$.id").value(1L))
           .andExpect(jsonPath("$.name")
                               .value("Updated Widget 1"))
           .andExpect(jsonPath("$.version").value(6));
}

@Test
public void testUpdateConflict() throws Exception {
   // Create a mock coffee with a version set to 5
   Widget mockWidget = new Widget(1L, "Widget 1", 5);

    // Return the mock Coffee when the CoffeeService's 
    // findById(1L) is called
    when(widgetService.findById(1L))
                      .thenReturn(Optional.of(mockWidget));

    // Execute a PUT /widget/1 with a mismatched version number: 2
    mockMvc.perform(put("/widget/{id}", 1L)
                    .contentType(MediaType.APPLICATION_JSON)
                    .header(HttpHeaders.IF_MATCH, 2)
                    .content("{\"id\": 1, " + 
                             "\"name\":  \"Updated Widget 1\"}"))
             // Validate that we get a 409 Conflict HTTP Response
            .andExpect(status().isConflict());
}

@Test
public void testUpdateNotFound() throws Exception {
   // Return the mock Coffee when the CoffeeService's 
   // findById(1L) is called
   when(widgetService.findById(1L)).thenReturn(Optional.empty());

   // Execute a PUT /coffee/1 with a mismatched version number: 2
   mockMvc.perform(put("/widget/{id}", 1L)
                    .contentType(MediaType.APPLICATION_JSON)
                    .header(HttpHeaders.IF_MATCH, 2)
                    .content("{\"id\": 1, " + 
                             "\"name\":  \"Updated Coffee 1\"}"))

           // Validate that we get 404 Not Found
           .andExpect(status().isNotFound());
}

We have three variations:

• A successful update.
• A failed update because of a version conflict.
• A failed update because the widget was not found.

In RESTful web services, version management is handled by the entity tag, or eTag. When you retrieve an entity, it has an eTag value. When you want to update the entity, you pass that eTag value in the If-Match HTTP header. If the If-Match header does not match the current eTag, which is the Widget version in our implementation, then the PUT handler returns a 409 Conflict HTTP response code. If you get this error, it means that you need to retrieve the entity again and retry your operation. This way, if two different clients attempt to update the same entity simultaneously, only one will succeed.

In the testSuccessfulUpdate() method, we return a Widget with a version of 5 when the WidgetService’s findById() method is called. We then pass an If-Match header value of 5 and then validate that we get a 200 OK HTTP response code and the expected header and body values. In the testUpdateConflict() method, we do the same thing, but we set the If-Match header to 2, which does not match 5, so we validate that we get a 409 Conflict HTTP response code. And finally, in the testUpdateNotFound() method, we configure the WidgetService to return an Optional.empty() when its findById() method is called, so we execute the PUT operation and validate that we get a 404 Not Found HTTP response code.

Unit testing DELETE /widget

Finally, here is the source code for our two DELETE /widget tests:

@Test
void testDeleteSuccess() throws Exception {
    // Setup mocked product
    Widget mockWidget = new Widget(1L, "Widget 1", 5);

    // Setup the mocked service
    when(widgetService.findById(1L))
                      .thenReturn(Optional.of(mockWidget));
    doNothing().when(widgetService).deleteById(1L);

    // Execute our DELETE request
    mockMvc.perform(delete("/widget/{id}", 1L))
            .andExpect(status().isOk());
}

@Test
void testDeleteNotFound() throws Exception {
    // Setup the mocked service
    when(widgetService.findById(1L)).thenReturn(Optional.empty());

    // Execute our DELETE request
    mockMvc.perform(delete("/widget/{id}", 1L))
            .andExpect(status().isNotFound());
}

The DELETE handler first tries to find the widget by ID and then calls the WidgetService’s deleteById() method. The testDeleteSuccess() method configures the WidgetService to return a mock Widget when the findById() method is called and then configures it to do nothing when the deleteById() method is called. The deleteById() method returns void, so we do not need to mock a response, though we do want to allow the method to be called. We execute the DELETE operation and validate that we receive a 200 OK HTTP response code. The testDeleteNotFound() method configures the WidgetService to return Optional.empty() when its findById() method is called. We execute the DELETE operation and validate that we receive a 404 Not Found HTTP response code.

At this point, we have a comprehensive set of tests for all of our controller operations. Let’s continue down our stack and test our service.

Unit testing a Spring MVC service

Next, we’ll test a WidgetService class, shown here:

package com.infoworld.widgetservice.service;

import java.util.List;
import java.util.Optional;

import com.infoworld.widgetservice.model.Widget;
import com.infoworld.widgetservice.repository.WidgetRepository;

import org.springframework.beans.factory.annotation.Autowired;
import org.springframework.stereotype.Service;

@Service
public class WidgetService {
    @Autowired
    private WidgetRepository widgetRepository;

    public List findAll() {
        return widgetRepository.findAll();
    }

    public Optional findById(Long id) {
        return widgetRepository.findById(id);
    }

    public Widget create(Widget widget) {
        widget.setVersion(1);
        return widgetRepository.save(widget);
    }

    public Widget save(Widget widget) {
        return widgetRepository.save(widget);
    }

    public void deleteById(Long id) {
        widgetRepository.deleteById(id);
    }
}

The WidgetService is very simple. It autowires in a WidgetRepository and then delegates almost all its functionality to the WidgetRepository. The only business logic it implements is that it sets the Widget version to 1 in the create() method, when it is persisting a new Widget to the database.

While Spring supports slice testing for our controller and (as you’ll soon see) our repository, it doesn’t have a slice testing annotation for our service. We could use the @SpringBootTest annotation, but then Spring would load all the controllers, repositories, and any other Spring resources in our application into the Spring application context. We can avoid by using Mockito directly.

Here is the source code for the WidgetServiceTest class:

package com.infoworld.widgetservice.service;

import static org.junit.jupiter.api.Assertions.assertEquals;
import static org.junit.jupiter.api.Assertions.assertTrue;
import static org.mockito.Mockito.when;

import java.util.Optional;

import com.infoworld.widgetservice.model.Widget;
import com.infoworld.widgetservice.repository.WidgetRepository;

import org.junit.jupiter.api.Test;
import org.junit.jupiter.api.extension.ExtendWith;
import org.mockito.InjectMocks;
import org.mockito.Mock;
import org.mockito.junit.jupiter.MockitoExtension;

@ExtendWith(MockitoExtension.class)
public class WidgetServiceTest {
    @Mock
    private WidgetRepository repository;

    @InjectMocks
    private WidgetService service;

    @Test
    void testFindById() {
        Widget widget = new Widget(1L, "My Widget", 1);
        when(repository.findById(1L)).thenReturn(Optional.of(widget));

        Optional w = service.findById(1L);
        assertTrue(w.isPresent());
        assertEquals(1L, w.get().getId());
        assertEquals("My Widget", w.get().getName());
        assertEquals(1, w.get().getVersion());
    }
}

JUnit 5 supports extensions and Mockito has defined a test extension that we can access through the @ExtendWith annotation. This extension allows Mockito to read our class, find objects to mock, and inject mocks into other classes. The WidgetServiceTest tells Mockito to create a mock WidgetRepository, by annotating it with the @Mock annotation, and then to inject that mock into the WidgetService, using the @InjectMocks annotation. The result is that we have a WidgetService that we can test and it will have a mock WidgetRepository that we can configure for our test cases.

Also see: Advanced unit testing with JUnit 5, Mockito, and Hamcrest.

This is not a comprehensive test, but it should get you started. It has a single method, testFindById(), that demonstrates how to test a service method. It creates a mock Widget instance and then uses the Mockito when() method, just as we used in the controller test, to configure the WidgetRepository to return an Optional of that Widget when its findById() method is called. Then it invokes the WidgetService’s findById() method and validates that the mock Widget is returned.

Slice testing a Spring Data JPA repository

Next, we’ll slice test our JPA repository (WidgetRepository.java), shown here:

package com.infoworld.widgetservice.repository;

import java.util.List;
import com.infoworld.widgetservice.model.Widget;
import org.springframework.data.jpa.repository.JpaRepository;

public interface WidgetRepository extends JpaRepository {
    List findByName(String name);
}

The WidgetRepository is a Spring Data JPA repository, which means that we define the interface and Spring generates the implementation. It extends the JpaRepository interface, which accepts two arguments:

• The type of entity that it persists, namely a Widget.
• The type of primary key, which in this case is a Long.

It generates common CRUD method implementations for us to create, update, delete, and find widgets, and then we can define our own query methods using a specific naming convention. For example, we define a findByName() method that returns a List of Widgets. Because “name” is a field in our Widget entity, Spring will generate a query that finds all widgets with the specified name.

Here is our WidgetRepositoryTest class:

package com.infoworld.widgetservice.repository;

import static org.junit.jupiter.api.Assertions.assertEquals;
import static org.junit.jupiter.api.Assertions.assertNotNull;
import static org.junit.jupiter.api.Assertions.assertNull;

import java.util.ArrayList;
import java.util.Arrays;
import java.util.List;

import com.infoworld.widgetservice.model.Widget;

import org.junit.jupiter.api.AfterEach;
import org.junit.jupiter.api.BeforeEach;
import org.junit.jupiter.api.Test;
import org.springframework.beans.factory.annotation.Autowired;
import org.springframework.boot.test.autoconfigure.orm.jpa.DataJpaTest;
import org.springframework.boot.test.autoconfigure.orm.jpa.TestEntityManager;

@DataJpaTest
public class WidgetRepositoryTest {
    @Autowired
    private TestEntityManager entityManager;

    @Autowired
    private WidgetRepository widgetRepository;

    private final List widgetIds = new ArrayList();
    private final List testWidgets = Arrays.asList(
            new Widget("Widget 1", 1),
            new Widget("Widget 2", 1),
            new Widget("Widget 3", 1)
    );

    @BeforeEach
    void setup() {
        testWidgets.forEach(widget -> {
            entityManager.persist(widget);
            widgetIds.add((Long)entityManager.getId(widget));
        });
        entityManager.flush();
    }

    @AfterEach
    void teardown() {
        widgetIds.forEach(id -> {
            Widget widget = entityManager.find(Widget.class, id);
            if (widget != null) {
                entityManager.remove(widget);
            }
        });
        widgetIds.clear();
    }

    @Test
    void testFindAll() {
        List widgetList = widgetRepository.findAll();
        assertEquals(3, widgetList.size());
    }

    @Test
    void testFindById() {
        Widget widget = widgetRepository.findById(
                               widgetIds.getFirst()).orElse(null);

        assertNotNull(widget);
        assertEquals(widgetIds.getFirst(), widget.getId());
        assertEquals("Widget 1", widget.getName());
        assertEquals(1, widget.getVersion());
    }

    @Test
    void testFindByIdNotFound() {
        Widget widget = widgetRepository.findById(
            widgetIds.getFirst() + testWidgets.size()).orElse(null);
        assertNull(widget);
    }

    @Test
    void testCreateWidget() {
        Widget widget = new Widget("New Widget", 1);
        Widget insertedWidget = widgetRepository.save(widget);

        assertNotNull(insertedWidget);
        assertEquals("New Widget", insertedWidget.getName());
        assertEquals(1, insertedWidget.getVersion());
        widgetIds.add(insertedWidget.getId());
    }

    @Test
    void testFindByName() {
        List found = widgetRepository.findByName("Widget 2");
        assertEquals(1, found.size(), "Expected to find 1 Widget");

        Widget widget = found.getFirst();
        assertEquals("Widget 2", widget.getName());
        assertEquals(1, widget.getVersion());
    }
}

The WidgetRepositoryTest class is annotated with the @DataJpaTest annotation, which is a slice-testing annotation that loads repositories and entities into the Spring application context and creates a TestEntityManager that we can autowire into our test class. The TestEntityManager allows us to perform database operations outside of our repository so that we can set up and tear down our test scenarios.

In the WidgetRepositoryTest class, we autowire in both our WidgetRepository and TestEntityManager. Then, we define a setup() method that is annotated with JUnit’s @BeforeEach annotation, so it will be executed before each test case runs. Next, we define a teardown() method that is annotated with JUnit’s @AfterEach annotation, so it will be executed after each test completes. The class defines a testWidgets list that contains three test widgets and then the setup() method inserts those into the database using the TestEntityManager’s persist() method. After it inserts each widget, it saves the automatically generated ID so that we can reference it in our tests. Finally, after persisting the widgets, it flushes them to the database by calling the TestEntityManager’s flush() method. The teardown() method iterates over all Widget IDs, finds the Widget using the TestEntityManager’s find() method, and, if it is found, removes it from the database. Finally, it clears the widget ID list so that the setup() method can rebuild it for the next test. (Note that the TestEntityManager removes entities directly; it does not have a remove by ID method, so we first have to find each Widget and then remove them one-by-one.)

Even though most of the methods being tested are autogenerated and well tested, I wanted to demonstrate how to write several kinds of tests. The only method that we really need to test is the findByName() method because that is the only custom method we define. For example, if we were to define the method as findByNam() instead of findByName(), then the method would not work, so it is definitely worth testing.

Conclusion

Spring provides robust support for testing each layer of a Spring MVC application. In this article, we reviewed how to test controllers, using MockMvc; services, using the JUnit Mockito extension; and repositories, using the Spring TestEntityManager. We also reviewed slice testing as a strategy to reduce testing resource utilization and minimize the time required to execute tests. Slice testing is implemented in Spring using the @WebMvcTest and @DataJpaTest annotations. I hope these examples have given you everything you need to feel comfortable writing robust tests for your Spring MVC applications.

Django is a one-size-fits-all Python web framework that was inspired by Ruby on Rails and uses many of the same metaphors to make web development fast and easy. Fully loaded and flexible, Django has become one of Python’s most widely used web frameworks.

Now in version 6.0, Django includes virtually everything you need to build a web application of any size, and its popularity makes it easy to find examples and help for various scenarios. Plus, Django provides tools to allow your application to evolve and add features gracefully, and to migrate its data schema if there is one.

Django also has a reputation for being complex, with many components and a good deal of “under the hood” configuration required. In truth, you can use Django to get a simple Python application up and running in relatively short order, then expand its functionality as needed.

This article guides you through creating a basic application using Django 6.0. We’ll also touch on the most crucial features for web developers in the Django 6 release.

Installing Django

Assuming you have Python 3.12 or higher installed, the first step to installing Django is to create a virtual environment. Installing Django in the venv keeps Django and its associated libraries separate from your base Python installation, which is always a good practice.

Next, install Django in your chosen virtual environment via Python’s pip utility:

pip install django

This installs the core Django libraries and the django-admin command-line utility used to manage Django projects.

Creating a new Django project

Django instances are organized into two tiers: projects and apps.

• A project is an instance of Django with its own database configuration, settings, and apps. It’s best to think of a project as a place to store all the site-level configurations you’ll use.
• An app is a subdivision of a project, with its own route and rendering logic. Multiple apps can be placed in a single Django project.

To create a new Django project from scratch, activate the virtual environment where you have Django installed. Then enter the directory where you want to store the project and type:

django-admin startproject 

The is the name of both the project and the subdirectory where the project will be stored. Be sure to pick a name that isn’t likely to collide with a name used by Python or Django internally. A name like myproj works well.

The newly created directory should contain a manage.py file, which is used to control the app’s behavior from the command line, along with another subdirectory (also with the project name) that contains the following files:

• An __init__.py file, which is used by Python to designate a subdirectory as a code module.
• settings.py, which holds the settings used for the project. Many of the most common settings will be pre-populated for you.
• urls.py, which lists the routes or URLs available to your Django project, or that the project will return responses for.
• wsgi.py, which is used by WSGI-compatible web servers, such as Apache HTTP or Nginx, to serve your project’s apps.
• asgi.py, which is used by ASGI-compatible web servers to serve your project’s apps. ASGI is a relatively new standard for asynchronous servers and applications, and requires a server that supports it, like uvicorn. Django only recently added native support for asynchronous applications, which will also need to be hosted on an async-compatible server to be fully effective.

Next, test the project to ensure it’s functioning. From the command line in the directory containing your project’s manage.py file, enter:

python manage.py runserver

This should start a development web server available at http://127.0.0.1:8000/. Visit that link and you should see a simple welcome page that tells you the installation was successful.

Note that the development web server should not be used to serve a Django project to the public. It’s solely for local testing and is not designed to scale for public-facing applications.

Creating a Django application

Next, we’ll create an application inside of this project. Navigate to the same directory as manage.py and issue the following command:

python manage.py startapp myapp

This creates a subdirectory for an application named myapp that contains the following:

• A migrations directory: Contains code used to migrate the site between versions of its data schema. Django projects typically have a database, so the schema for the database—including changes to the schema—is managed as part of the project.
• admin.py: Contains objects used by Django’s built-in administration tools. If your app has an admin interface or privileged users, you will configure the related objects here.
• apps.py: Provides configuration information about the app to the project at large, by way of an AppConfig object.
• models.py: Contains objects that define data structures, used by your app to interface with databases.
• tests.py: Contains any tests created by you and used to ensure that your site’s functions and modules are working as intended.
• views.py: Contains functions that render and return responses.

To start working with the application, you need to first register it with the project. Edit myproj/settings.py as follows, adding a line to the top of the INSTALLED_APPS list:

INSTALLED_APPS = [
    "myapp.apps.MyappConfig",
    "django.contrib.admin",
    ...

If you look in myproj/myapp/apps.py, you’ll see a pre-generated object named MyappConfig, which we’ve referenced here.

Adding routes and views to your Django application

Django applications follow a basic pattern for processing requests:

• When an incoming request is received, Django parses the URL for a route to apply it to.
• Routes are defined in urls.py, with each route linked to a view, meaning a function that returns data to be sent back to the client. Views can be located anywhere in a Django project, but they’re best organized into their own modules.
• Views can contain the results of a template, which is code that formats requested data according to a certain design.

To get an idea of how all these pieces fit together, let’s modify the default route of our sample application to return a custom message.

Routes are defined in urls.py, in a list named urlpatterns. If you open the sample urls.py, you’ll see urlpatterns already predefined:

urlpatterns = [
    path('admin/', admin.site.urls),
]

The path function (a Django built-in) takes a route and a view function as arguments and generates a reference to a URL path. By default, Django creates an admin path that is used for site administration, but we need to create our own routes.

Add another entry, so that the whole file looks like this:

from django.contrib import admin
from django.urls import include, path

urlpatterns = [
    path('admin/', admin.site.urls),
    path('myapp/', include('myapp.urls'))
]

The include function tells Django to look for more route pattern information in the file myapp.urls. All routes found in that file will be attached to the top-level route myapp (e.g., http://127.0.0.1:8080/myapp).

Next, create a new urls.py in myapp and add the following:

from django.urls import path
from . import views

urlpatterns = [
    path('', views.index)
]

Django prepends a slash to the beginning of each URL, so to specify the root of the site (/), we just supply a blank string as the URL.

Now, edit the file myapp/views.py so it looks like this:

from django.http import HttpResponse

def index(request):
    return HttpResponse("Hello, world!")

django.http.HttpResponse is a Django built-in that generates an HTTP response from a supplied string. Note that request, which contains the information for an incoming HTTP request, must be passed as the first parameter to a view function.

Stop and restart the development server, and navigate to http://127.0.0.1:8000/myapp/. You should see “”Hello, world!” appear in the browser.

Adding routes with variables in Django

Django can accept routes that incorporate variables as part of their syntax. Let’s say you wanted to accept URLs that had the format year/. You could accomplish that by adding the following entry to urlpatterns:

path(‘year/’, views.year)

The view function views.year would then be invoked through routes like year/1996, year/2010, and so on, with the variable year passed as a parameter to views.year.

To try this out for yourself, add the above urlpatterns entry to myapp/urls.py, then add this function to myapp/views.py:

def year(request, year):
    return HttpResponse('Year: {}'.format(year))
    

If you navigate to /myapp/year/2010 on your site, you should see Year: 2010 displayed in response. Note that routes like /myapp/year/rutabaga will yield an error because the int: constraint on the variable year allows only an integer in that position. Many other formatting options are available for routes.

Django templates and template partials

You can use Django’s built-in template language to generate web pages from data.

Templates used by Django apps are stored in a directory that is central to the project: /templates//. For our myapp project, the directory would be myapp/templates/myapp/. This directory structure may seem awkward, but allowing Django to look for templates in multiple places avoids name collisions between templates with the same name across multiple apps.

In your myapp/templates/myapp/ directory, create a file named year.html with the following content:

Year: {{year}}

Any value within double curly braces in a template is treated as a variable. Everything else is treated literally.

Modify myapp/views.py to look like this:

from django.shortcuts import render
from django.http import HttpResponse

def index(request):
    return HttpResponse("Hello, world!")

def year(request, year):
    data = {'year':year}
    return render(request, 'myapp/year.html', data)

The render function—a Django “shortcut” (a combination of multiple built-ins for convenience)—takes the existing request object, looks for the template myapp/year.html in the list of available template locations, and passes the dictionary data to it as context for the template. The template uses the dictionary as a namespace for variables used in the template. In this case, the variable {{year}} in the template is replaced with the value for the key year in the dictionary data (that is, data["year"]).

The amount of processing you can do on data within Django templates is intentionally limited. Django’s philosophy is to enforce the separation of presentation and business logic whenever possible. Thus, you can loop through an iterable object, and you can perform if/then/else tests, but modifying the data within a template is discouraged.

For instance, you could encode a simple “if” test this way:

{% if year > 2000 %}
21st century year: {{year}}
{% else %}
Pre-21st century year: {{year}}
{% endif %}

The {% and %} markers delimit blocks of code that can be executed in Django’s template language.

If you want to use a more sophisticated template processing language, you can swap in something like Jinja2 or Mako. Django includes back-end integration for Jinja2, but you can use any template language that returns a string—for instance, by returning that string in an HttpResponse object, as in the case of our “Hello, world!” route.

In versions 6 and up, Django supports template partials, a way to create portions of a template that can be defined once and reused throughout a template. This lets you precompute a given value once over the course of a given template—such as a fancy display version of a user name—and re-use it without having to recompute it each time it’s displayed.

Doing more with Django

What you’ve seen here covers only the most basic elements of a Django application. Django includes a great many other components for use in web projects. Here’s a quick overview:

• Databases and data models: Django’s built-in ORM lets you define data structures and relationships between them, as well as migration paths between versions of those structures.
• Forms: Django provides a consistent way for views to supply input forms to a user, retrieve data, normalize the results, and provide consistent error reporting. Django 6 added support for Content Security Policy, a way to prevent submitted forms from being vulnerable to content injection or cross-site scripting (XSS) attacks.
• Security and utilities: Django includes many built-in functions for caching, logging, session handling, handling static files, and normalizing URLs. It also bundles tools for common security needs like using cryptographic certificates or guarding against cross-site forgery protection or clickjacking.
• Tasks: Django 6 added a native mechanisms for creating and managing long-running background tasks, without holding up a response to the user. Note that Django only provides ways to set up and keep track of tasks; it doesn’t include the actual execution mechanism. The only included back ends for tasks are for testing, so you will either need to add a third-party solution or write your own using Django’s back-end task code as a base.

Despite many worthy contenders, React remains the most popular front-end framework, and a key player in the JavaScript development landscape. React is the quintessential reactive engine, continually innovating alongside the rest of the industry. A flagship open source project at Facebook, React is now part of Meta Open Source. For developers new to JavaScript and web development, this tutorial will get you started with this vital technology.

React is not only a front-end framework, but is a component in full-stack frameworks like Next.js. Newer additions like React server-side rendering (SSR) and React server components (RSC) further blur the line between server and client.

Also see: Is the React compiler ready for primetime?

Why React?

React’s prominence makes it an obvious choice for developers just starting out with web development. It is often chosen for its ability to offer a smooth and encompassing developer experience (DX), which distinguishes it from frameworks like Vue, Angular, and Svelte. It could be said that React’s true “killer feature” is the perks that come with longstanding popularity: learning resources, community support, libraries, and developers are all plentiful in the React ecosystem.

Installing React

Real-world React requires running on the server with a build tool, which we will explore in the next section. But to get your feet wet, we can start out with an online playground. There are several high-quality playgrounds for React, including full-blown environments like StackBlitz or Codesandbox. For a quick taste, we will use PlayCode React.

When you first open it, PlayCode React gives you a basic layout like the one shown here:

The menu on the left is the file explorer, at the top is the code window, and at the bottom are the console (on the left) and the preview pane (on the right).

From this screenshot, you can see how the content of the code is displayed on the preview pane, but this basic layout doesn’t use any variables (or “state,” as it’s known in React). It does let you see some of the plumbing, like the React library import and the exported App function.

Modern React is functional. The App function has a return value that is the actual output for the component. The component’s return is specified by JSX, a templating language that lets you use HTML along with variables and JavaScript expressions. Right now, the app just has some simple markup.

The classic example you see next is a “Counter” that lets you increase and decrease a displayed value using buttons. We’ll do a slight “Spinal Tap” variation of this, where the counter only goes to 11 and displays a message:

You can take a look at the running example here, and the full code for the example is below:

import React, { useState } from 'react';

export function App() {
  // 1. The State
  const [volume, setVolume] = useState(0);

  return (
    

      
Spinal Tap Amp 🎸
     
      {/* 2. The "View" (Displaying the state) */}
      

        {volume}
      

      

        {/* 3. The Actions */
         setVolume(volume - 1)}>Down
       
         {
          if (volume 
          Up
        
      

      {/* 4. Conditional */}
      {volume === 11 &&
        
"Why don't you just make ten louder?"
      }
    
  );
}

If you play with the example, you’ll see that moving the buttons changes the value, and the display automatically reflects the change. This is the essential magic of a reactive engine like React. The state is a managed variable that React automatically updates and displays. State is declared like so:

const [volume, setVolume] = useState(0);

The syntax is a bit funky if you are coming from straight JavaScript, but most developers can adapt to it quickly. Basically, useState(0) says, with a default value 0, give me a variable, volume, and a function to set it, setVolume.

To display the value in the view, we use: {volume}.

To modify the value, we use button event handlers. For example, to increment, we’d do:

To modify the value, we use buttons event handlers.  For example, to increment:

onClick={() => setVolume(volume + 1)

Here we’ve directly modified the volume state, and React will update accordingly. If we wanted to, we could call a function (for example, if the logic were more involved).

Finally, when the value reaches 11, we display a message. This syntax is idiomatic React, and uses an embedded JavaScript equality check:

{volume === 11 &&
  
"Why don't you just make ten louder?"
}

The check says, if volume is 11, then display the

markup.

Using a build tool with React

Once upon a time, when NVIDIA was nothing but a graphics card, it was quite a bit of work assembling a good build chain for React. These days, the process is much simpler, and the once ubiquitous create-react-app option is no more. Vite is now the standard choice for launching a new app from the React terminal, so that’s the approach you’ll learn here.

With that said, there are a few alternatives worth mentioning. VS Code has extensions that will provide you with templates or scaffolding, but what’s becoming more common is using an AI coding assistant. A tool like Copilot, ChatGPT, or Gemini can take a prompt describing the basics of the application in question, including the instruction to use React, and produce a basic React layout for you. AI assistants are available in both command-line and VS Code extension flavors. Or, for an even more forward-looking option, you could use something like Firebase Studio.

But enough about alternatives—Vite is the standard for a reason. It is repeatable, capable, and fast. To launch a new Vite app, you just enter the following in your command line:

$ npm create vite@latest

The interactive tool will walk you through the process, starting with selecting React as your technology:

Use your own preferences for the other options (like using TypeScript versus JavaScript) and accept the option to install and launch the app immediately. Afterward, you’ll see a simple demo like this one:

The demo app has a counter component like the one we built earlier. If you Ctrl-c (or Cmd-c) to kill the Vite process running in the terminal, you can cd into the new directory. From there, you can see where the counter component is defined, in src/App.jsx (or App.tsx if you have selected TypeScript like I have).

It’s worth looking at that file to see how React appears on the server:

src/App.tsx
import { useState } from 'react'
import reactLogo from './assets/react.svg'
import viteLogo from '/vite.svg'
import './App.css'

function App() {
  const [count, setCount] = useState(0)

  return (
    
      

        
          
        
        
          
        
      
      
Vite + React
      

         setCount((count) => count + 1)}>
          count is {count}
        
        

          Edit src/App.tsx and save to test HMR
        
      
      

        Click on the Vite and React logos to learn more
      
    >
  )
}

export default App</code>

Notice we export the App as a module, which is used by the src/main.tsx file to display the component in the view. That file creates the bridge between the respective worlds of React and HTML:

import { StrictMode } from 'react'
import { createRoot } from 'react-dom/client'
import './index.css'
import App from './App.tsx'

createRoot(document.getElementById('root')!).render(
  
    
  ,
)

Don’t worry too much about the details of how React bootstraps itself with createRoot and the render call (which you won’t have to interact with on a regular basis). The important thing is how the App component is imported and then used with the JSX.

Note

Strict mode adds warning during dev mode to help you catch component bugs early.

There are a few rules to bear in mind when using JSX, the templating language of React:

• HTML elements are lowercase (
  , ), but components are uppercase (, ).
• You can’t just type “class” in JSX; instead, use className; e.g.,
  .
• To access the realm of JavaScript (and the application state) from within JSX, use curly braces: {2 + 2 != 5}.

React components and props

The main organizational concept in React is the component. Components are used to contain the functionality for a part of the view within a self-contained package. We’ve seen a component in action already with but it might be a little obscure, so let’s add another simple component to enhance the demonstration. This component also lets us explore another key part of React: Props.

To start, let’s create a display of the counter value influenced by the Rob Reiner movie This Is Spinal Tap. To start, we create a new file at src/VolumeDisplay.jsx:

// src/VolumeDisplay.jsx

export function VolumeDisplay({ level }) {
  return (
    

      {/* The Dial */}
      
= 11 ? '#d32f2f' : '#f0f0f0',
        color: level >= 11 ? 'white' : 'black',
        transition: 'all 0.2s ease'
      }}>
        {level}
      

      {/* The Message */}
      {level >= 11 && (
        

          "These go to eleven." 🤘
        
      )}
    
  );
}

This is a simple display but there are a couple of things worth noting about it.

One is that we accept a prop (a property) “from above” with VolumeDisplay({ level }). This tells whatever parent component uses this one that VolumeDisplay accepts a single property, called level. VolumeDisplay uses the property by displaying it (though it adds a bit of fancying up using conditional logic like we have already seen).

The way we define the CSS values, inside the double braces, {{ }}, and as a map of value is idiomatic React. (It isn’t essential at this point to grasp why it works that way, but basically, it is the JSX token { } with a JavaScript map of CSS values using JavaScript-friendly camel-cased names, like justifyContent.)

Now, to utilize this component, we can go to App.jsx, and make two changes:

import { useState } from 'react'
import reactLogo from './assets/react.svg'
import viteLogo from '/vite.svg'
import './App.css'
// 1. Import our new component
import { VolumeDisplay } from './VolumeDisplay'

function App() {
  const [count, setCount] = useState(0)

  return (
    
      

        
          
        
        
          
        
      
      
Vite + React
      

         setCount((count) => count + 1)}>
          count is {count}
        
        {/* 2. Pass the 'count' state into the 'level' prop */}
      
        

          Edit src/App.tsx and save to test HMR
        
      
      

        Click on the Vite and React logos to learn more
      
    >
  )
}

export default App</code>

Here, we’ve done two things: imported the new component and used it in the view.

Notice, also, that the line passes the existing count state variable into VolumeDisplay as a prop. React will do the work of ensuring that whenever count changes, the VolumeDisplay will also be updated, including any dependent logic such as the conditional statements.

Now, if we run the code like so:

$ npm run dev

We get what you see in the screenshot below:



Matthew Tyson

Conclusion

The world is now your oyster, at least within the realm of JavaScript web development. Not only is React wildly popular, its basic ideas are applicable to a host of other innovative frameworks, including Svelte and Solid. (To get some idea of the alternatives, just type npm create vite@latest and look at all the available technologies.) Now that you have a basic introduction, a good next step for learning would be to add an control that allows typing in the volume manually. Happy coding!

Angular is a cohesive, all-in-one reactive framework for web development. It is one of the larger reactive frameworks, focused on being a single architectural system that handles all your web development needs under one idiom. While Angular was long criticized for being heavyweight as compared to React, many of those issues were addressed in Angular 19. Modern Angular is built around the Signals API and minimal formality, while still delivering a one-stop-shop that includes dependency injection and integrated routing.

Angular is popular with the enterprise because of its stable, curated nature, but it is becoming more attractive to the wider developer community thanks to its more community engaged development philosophy. That, along with its recent technical evolution, make Angular one of the most interesting projects to watch right now.

Why choose Angular?

Choosing a JavaScript development framework sometimes feels like a philosophical debate, but it should be a practical decision. Angular is unique because it is strongly opinionated. It doesn’t just give you a view layer; it provides a complete toolkit for building web applications.

Like other reactive frameworks, Angular is built around its reactive engine, which lets you bind state (variables) to the view. But if that’s all you needed, one of the smaller, more focused frameworks would be more than enough. What Angular has that some of these other frameworks don’t is its ability to use data binding to automatically synchronize data from your user interface (UI) with your JavaScript objects. Angular also leverages dependency injection and inversion of control to help structure your application and make it easier to test. And it contains more advanced features like server-side rendering (SSR) and static-site generation (SSG) within itself, rather than requiring you to engage a meta-framework for either style of development.

While Angular might not be your top choice for every occasion, it’s an excellent option for larger projects that require features you won’t get with a more lightweight framework.

Also see: Catching up with Angular 19.

Getting started with Angular

With those concepts in mind, let’s set up Angular in your development environment. After that, we can run through developing a web application with Angular. To start, make sure you have Node and NPM installed. From the command line, enter:

$ node -v
$ npm -v

Next, you can use the Angular CLI to launch a new app:

$ ng new iw-ng

You can use the defaults in your responses to the interactive prompts shown here:

We now have a basic project layout in the new directory, which you can import into an IDE (such as VS Code) or edit directly.

Looking at the project layout, you might notice it is fairly lean, a break from Angular projects of the past. The most important parts are:

• src/main.ts: This is the main entry point. In older versions of Angular, this file had to bootstrap a module, which then bootstrapped a component. Now, it avoids any verbose syntax, calling bootstrapApplication with your root component directly.
• src/index.html: The main HTML page that hosts your application. This is the standard index.html that serves all root requests in a web page and contains the tag where your Angular component will render. It is the “body” that the “spirit” of your code animates.
• src/app/app.ts: The root component of your application. This single file defines the view logic and the component metadata. In the new “standalone” world, it manages its own imports, meaning you can see exactly what dependencies it uses right at the top of the file. (This is the root element that appears in src/index.html.)
• src/app/app.config.ts: This file is new in modern Angular and replaces the old AppModule providers array. It is where you configure global services, like the router or HTTP client.
• angular.json: The configuration file for the CLI itself. It tells the build tools how to process your code, though you will rarely need to touch this file manually anymore.

Here is the basic flow of how the engine renders these components:

1. The arrival (HTML): The browser receives index.html. The tag is there, but it’s empty.
2. The unpacking (JavaScript): The browser sees the tags at the bottom of the HTML and downloads the JavaScript bundles (your compiled code) from src/app/app.ts.
3. The assembly (Bootstrap): The browser runs that JavaScript. The code “wakes up,” finds the tag in the DOM, and dynamically inserts your title, buttons, and lists.

This flow will be different if you are using server-side rendering (SSR), but we’ll leave that option aside for now. Now that you’ve seen the basic architecture, let’s get into the code.

Developing your first web app in Angular

If you open src/app/app.ts (more info here) the component definition looks like this:

import { Component, signal } from '@angular/core';
import { RouterOutlet } from '@angular/router';

@Component({
  selector: 'app-root',
  imports: [RouterOutlet],
  templateUrl: './app.html',
  styleUrl: './app.css'
})
export class App {
  protected readonly title = signal('iw-ng');
}

Before we dissect the code, let’s run the app and see what it produces:

$ ng serve

You should see a page like this one at localhost:4200:

Returning to the src/app.ts component, notice that there are three main parts of the definition: the class, the metadata, and the view. Let’s unpack these separately.

The class (export class App)

Export class App is vanilla TypeScript that holds your component’s data and logic. In our example, title = signal(‘iw-ng’) defines a piece of reactive state. Unlike older versions of Angular where data was just a plain property, here we use a signal. Signals are wrappers around values that notify the template precisely when they change, enabling fine-grained performance.

The metadata (@Component)

The @Component decorator tells Angular it is dealing with a component, not just a generic class. There are several elements involved in the decorator’s communication with the engine:

• selector: 'app-root': Defines the custom HTML tag associated with any given component. Angular finds in your index.html and renders the component there.
• imports: In the new Angular era, dependencies are explicit. You list exactly what a component needs (like RouterOutlet or other components) here, rather than hiding them in a separate module file.
• templateUrl: Points to the external HTML file that defines the view.

The view (the template)

This is the visual part of the component, defined in app.html. It combines standard HTML with Angular’s template syntax. (JSX handles this part for React-based apps.)

We can modify src/app/app.html to see how these three elements work together. To start, delete the default content and add the following:

Hello, {{ title() }}

The double curly braces {{ }} are called interpolation. Notice the parentheses in title(). We are reading the “title” signal value by calling its function. If you were to update that signal programmatically (e.g., this.title.set('New Value')), the text on the screen would update instantly.

Angular’s built-in control flow

Old-school Angular required “structural directives” like *ngIf and *ngFor logic control. These were powerful but required importing CommonModule and learning a specific micro-syntax. Modern Angular uses a built-in control flow that looks like standard JavaScript (similar to other Reactive platforms).

To see the new control flow in action, let’s add a list to our component. Update src/app/app.ts as follows, leaving the rest of the file the same:

export class App {
  protected readonly title = signal('iw-ng');
  protected readonly frameworks = signal(['Angular', 'React', 'Vue', 'Svelte']);
  protected showList = signal(true);

  toggleList() {
    this.showList.update(v => !v);
  }
}

While we’re at it, let’s also update src/app/app.html to render this new list (don’t worry about for now; it just tells Angular where to render the framing template):

Toggle List

@if (showList()) {
  

    @for (tech of frameworks(); track tech) {
      
{{ tech }}
    }
  
} @else {
  
List is hidden
}

The app will now display a list that can be toggled for visibility:

This syntax is cleaner and easier to read than the old *ngFor loops:

• @if conditionally renders the block if the signal’s value is true.
• @for iterates over the array. The track keyword is required for performance (it tells Angular how to identify unique items in the list).
• (click) is an event binding. It lets us run code (the toggleList method) when the user interacts with the button.

Services: Managing business logic in Angular

Components focus on the view (i.e., what you see). For the business logic that backs the application functionality, we use services.

A service is just a class that can be “injected” into a component that needs it. This is Angular’s famous dependency injection system. It allows you to write logic once and reuse it anywhere. It’s a slightly different way of thinking about how an application is wired together, but it gives you real organizational benefits over time.

To generate a service, you can use the CLI:

$ ng generate service frameworks

This command creates a src/app/hero.ts file. In modern Angular, we define services using the @Injectable decorator. Currently, the src/app/hero.ts file just has this:

import { Injectable } from '@angular/core';

@Injectable({
  providedIn: 'root',
})
export class Frameworks {
  
}

Open the file and add a simple method to return our data:

import { Injectable } from '@angular/core';

@Injectable({
  providedIn: 'root', // Available everywhere in the app
})
export class Frameworks {
  getList() {
    return ['Angular', 'React', 'Vue', 'Svelte'];
  }
}

The providedIn: 'root' metadata is important, it tells Angular to create a single, shared instance of this service for the entire application (you might recognize this as an instance of the singleton pattern).

Using the service

In the past, we had to list dependencies in the constructor. Modern Angular offers a cleaner way: the inject() function. Subsequently, we can refactor our src/app/app.ts to get its data from the service instead of hardcoding it:

import { Component, inject, signal } from '@angular/core';
import { RouterOutlet } from '@angular/router';
import { Frameworks } from './frameworks'; // Import the service

@Component({
  selector: 'app-root',
  imports: [RouterOutlet],
  templateUrl: './app.html',
  styleUrl: './app.css'
})
export class App {
  private frameworksService = inject(Frameworks); // Dependency Injection
  
  protected readonly title = signal('iw-ng');
  
  // Initialize signal with data directly from the service
  protected readonly frameworks = signal(this.frameworksService.getList());
  protected showList = signal(true);

  toggleList() {
    this.showList.update(v => !v);
  }
}

Dependency injection is a powerful pattern. The component doesn’t need to know where the list came from (it could be coming from an API, a database, or a hard-coded array); it just asks the service for what it needs. This pattern adds a bit of extra work up front, but it delivers a more flexible, organized codebase as the app grows in size and complexity.

Routers and routes

Once your application grows beyond a single view, you need a way to navigate between different screens. In Angular, we use the built-in router for this purpose. In our example project, src/app/app.routes.ts is the dedicated home for the router config. Let’s follow the steps for creating a new route.

First, we define the route. When you open src/app/app.routes.ts, you will see an exported routes array. This array contains the available routes for your app. Each string name resolves to a component that handles rendering that route. In effect, this is the map of your application’s landscape.

In a real application, you’d often have “framing template” material in the root of the app (like the navbar) and then the routes fill in the body content. (Remember that by default, Angular is designed for single-page apps, where navigation does reload the screen, but swaps content.)

For now, let’s just get a sense of how the router works. First, create a new component so we have a destination to travel to. In your terminal, run:

$ ng generate component details

This will generate a simple details component in the src/app/details directory.

Now we can update src/app/app.routes.ts to include this new path. We will also add a “default” path that redirects empty requests to the home view, ensuring the user always lands somewhere:

import { Routes } from '@angular/router';
import { App } from './app'; // Matches src/app/app.ts
import { Details } from './details/details'; // Matches src/app/details/details.ts

export const routes: Routes = [
  { path: '', redirectTo: '/home', pathMatch: 'full' },
  { path: 'home', component: App },
  { path: 'details', component: Details },
];

Now if you visit localhost:4200/home, you’ll get the message from the details component: “Details works!”

Next, we’ll use the routerLink directive to move between views without refreshing the page. In src/app/app.html, we create a navigation bar that sits permanently at the top of the page (the “stationary” element), while the router swaps the content below it (the “impermanent” element):

And with that, the application has a navigation flow. The user clicks, the URL updates, and the content transforms, all without the jarring flicker of a browser reload.

Parametrized routes

The last thing we’ll look at is handling route parameters, where the route accepts variables in the path. To manage this kind of dynamic data, you define a route with a variable, marked by a colon. Open src/app/app.routes.ts and add a dynamic path:

export const routes: Routes = [
  // ... existing routes
  { path: 'details/:id', component: Details }, 
];

The :id is a placeholder. Whether the URL is /details/42 or /details/108, this router will receive it because it matches the path. Inside the details component, we have access to this parameter (using the ActivatedRoute service or the new withComponentInputBinding). We can use that value to retrieve the data we need (like using it to recover a detail item from a database).

Conclusion

We have seen the core elements of modern Angular: Setting up the environment, building reactive components with signals, organizing logic with services, and tying it all together with interactive routing.

Deploying these pieces together is the basic work in Angular. Once you get comfortable with it, you have an extremely powerful platform at your fingertips. And, when you are ready to go deeper, there is a whole lot more to explore in Angular, including:

• State management: Beyond signals, Angular has support for managing complex, application-wide state.
• Forms: Angular has a robust system for handling user input.
• Signals: We only scratched the surface of signals here. Signals offer a powerful, fine-grained way to manage state changes.
• Build: You can learn more about producing production builds.
• RxJS: Takes reactive programming to the next level.

Docker is a software platform for building applications based on containers—small and lightweight execution environments that make shared use of the operating system kernel but otherwise run in isolation from one another. While containers have been used in Linux and Unix systems for some time, Docker, an open source project launched in 2013, helped popularize the technology by making it easier than ever for developers to package their software to “build once and run anywhere.”

A brief history of Docker

Founded as DotCloud in 2008 by Solomon Hykes in Paris, what we now know as Docker started out as a platform as a service (PaaS) before pivoting in 2013 to focus on democratizing the underlying software containers its platform was running on.

Hykes first demoed Docker at PyCon in March 2013, explaining that Docker was created because developers kept asking for the underlying technology powering the DotCloud platform. “We did always think it would be cool to be able to say, ‘Yes, here is our low-level piece. Now you can do Linux containers with us and go do whatever you want, go build your platform.’ So that’s what we are doing.”

And so, Docker was born, with the open source project quickly picking up traction with developers and attracting the attention of high-profile technology providers like Microsoft, IBM, and Red Hat, as well as venture capitalists willing to pump millions of dollars into the innovative startup. The container revolution had begun.

What are containers?

As Hykes described it in his PyCon talk, containers are “self-contained units of software you can deliver from a server over there to a server over there, from your laptop to EC2 to a bare-metal giant server, and it will run in the same way because it is isolated at the process level and has its own file system.”

The components for doing this have long existed in operating systems like Linux. By simplifying their use and giving these bits a common interface, Docker quickly became close to a de facto industry standard for containers. Docker let developers deploy, replicate, move, and back up a workload in a single, streamlined way, using a set of reusable images to make workloads more portable and flexible than previously possible.

Also see: Why you should use Docker and OCI containers.

In the virtual machine (VM) world, something similar could be achieved by keeping applications separate while running on the same hardware. But each VM requires its own operating system, meaning VMs are typically large, slow to start up, difficult to move around, and cumbersome to maintain and upgrade.

Containers represent a defined shift from the VM era, in that they isolate execution environments while sharing the underlying OS kernel. As a result, they are speedier and far more lightweight than VMs.

Docker: The component parts

Docker took off with software developers as a novel way to package the tools required to build and launch a container. It was more streamlined and simplified than anything previously possible. Broken down into its component parts, Docker consists of the following:

• Dockerfile: Each Docker container starts with a Dockerfile. This text file provides a set of instructions to build a Docker image, including the operating system, languages, environmental variables, file locations, network ports, and any other components it needs to run. Provide someone with a Dockerfile and they can recreate the Docker image wherever they please, although the build process takes time and system resources.
• Docker image: Like a snapshot in the VM world, a Docker image is a portable, read-only executable file. It contains the instructions for creating a container and the specifications for which software components to run and how the container will run them. Docker images are far larger than Dockerfiles but require no build step: They can boot and run as-is.
• Docker run utility: Docker’s run utility is the command that launches a container. Each container is an instance of an image, and multiple instances of the same image can be run simultaneously.
• Docker Hub: Docker Hub is a repository where container images can be stored, shared, and managed. Think of it as Docker’s own version of GitHub, but specifically for containers.
• Docker Engine: Docker Engine is the core of Docker. It is the underlying client-server technology that creates and runs the containers. The Docker Engine includes a long-running daemon process called dockerd for managing containers, APIs that allow programs to communicate with the Docker daemon, and a command-line interface.
• Docker Compose: Docker Compose is a command-line tool that uses YAML files to define and run multicontainer Docker applications. It allows you to create, start, stop, and rebuild all the services from your configuration and view the status and log output of all running services.
• Docker Desktop: All of these component parts are wrapped in Docker’s Desktop application, providing a user-friendly way to build and share containerized applications and microservices.

Advantages of Docker

Docker containers provide a way to build applications that are easier to assemble, maintain, and move around than previous methods allowed. That provides several advantages to software developers:

• Docker containers are minimalistic and enable portability: Docker helps to keep applications and their environments clean and minimal by isolating them, which allows for more granular control and greater portability.
• Docker containers enable composability: Containers make it easier for developers to compose the building blocks of an application into a modular unit with easily interchangeable parts, which can speed up development cycles, feature releases, and bug fixes.
• Docker containers make orchestration and scaling easier: Because containers are lightweight, developers can launch many of them for better scaling of services, and each container instance launches many times faster than a VM. These clusters of containers do then need to be orchestrated, which is where a platform like Kubernetes typically comes in.

Also see: How to succeed with Kubernetes.

Drawbacks of Docker

Containers solve a great many problems, but they don’t solve them all. Common complaints about Docker include the following:

• Docker containers are not virtual machines: Unlike virtual machines, containers use controlled portions of the host operating system’s resources, which means elements aren’t as strictly isolated as they would be on a VM.
• Docker containers don’t provide bare-metal speed: Containers are significantly more lightweight and closer to the metal than virtual machines, but they do incur some performance overhead. If your workload requires bare-metal speed, a container will get you close but not all the way there.
• Docker containers are stateless and immutable: Containers boot and run from an image that describes their contents. That image is immutable by default—once created, it doesn’t change. But a container instance is transient. Once removed from system memory, it’s gone forever. If you want your containers to persist state across sessions, like a virtual machine, you need to design for that persistence.

Docker today

Container usage has continued to grow in tandem with cloud-native development, now the dominant model for building and running software. But these days, Docker is only a part of that puzzle.

Docker grew popular because it made it easy to move the code for an application and its dependencies from the developer’s laptop to a server. But the rise of containers led to a shift in the way applications were built—from monolithic stacks to networks of microservices. Soon, many users needed a way to orchestrate and manage groups of containers at scale.

Launched at Google, the Kubernetes open source project quickly emerged as the best way to orchestrate containers, superseding Docker’s own attempts to solve this problem with Docker Swarm (RIP). Amidst increasing funding trouble, Docker eventually sold its enterprise business to Mirantis in 2019, which has since absorbed Docker Enterprise into the Mirantis Kubernetes Engine.

The remains of Docker—which includes the original open source Docker Engine container runtime, Docker Hub image repository, and Docker Desktop application—live on under the leadership of company veteran Scott Johnston, who is looking to reorient the business around its core customer base of software developers.

The Docker Business subscription service, and the revised Docker Desktop product, both reflect those new goals: Docker Business offers tools for managing and rapidly deploying secure Docker instances, and Docker Desktop requires paid usage for organizations with more than $10 million in annual revenue and 250 or more employees. But there’s also the Docker Personal subscription tier, for individuals and companies that fall below those thresholds, so end users still have access to many of Docker’s offerings.

Docker has other offerings suited to the changing times. Docker Hardened Images, available in both free and enterprise tiers, provide application images with smaller attack surfaces and checked software components for better security. And, in step with the AI revolution, the Docker MCP Catalog and Toolkit provide Dockerized versions of tools that give AI applications broader functionality (such as by allowing access to the file system), making it easier to deploy AI apps with less risk to the surrounding environment.

Resulta difícil encontrar un área de la empresa moderna en la que la inteligencia artificial (IA) no haya encontrado aplicación, y los procesos de selección tecnológica no son una excepción. Una encuesta de MyPerfectResume revela que el 73% de los empleadores afirma utilizar IA en las decisiones de contratación, mientras que el 52% la emplea para decisiones relacionadas con la reestructuración organizativa y la planificación de puestos.

Por otro lado, los candidatos también recurren cada vez más a estas herramientas. Según datos de SAP, el 52% de las personas que buscan empleo actualmente utiliza IA para apoyar su proceso de búsqueda, principalmente para mejorar los materiales de candidatura (85%) y prepararse para entrevistas (73%).

Jasmine Escalera, experta en carreras profesionales de Zety, plataforma especializada en orientación laboral y creación de currículums, considera que “la tecnología puede ayudar a las empresas a ser más eficientes, pero las decisiones de contratación siguen beneficiándose del criterio humano, especialmente cuando la experiencia de un candidato requiere un contexto que los sistemas automatizados de evaluación no siempre son capaces de comprender”.

Está claro que la IA ya forma parte esencial del proceso de contratación. Por ello, las organizaciones deben definir una estrategia clara sobre cómo utilizarla en el futuro, abordando cuestiones como los sesgos en la selección, la transparencia y el equilibrio adecuado entre la intervención humana y la asistencia tecnológica.

Identificar las señales de alerta

La IA promete aportar eficiencia tanto a candidatos como a empleadores, pero una excesiva dependencia de la tecnología puede generar consecuencias no deseadas. Los datos de MyPerfectResume muestran además que el 65% de los encuestados considera que la IA rechaza automáticamente a candidatos antes de que una persona llegue a revisar sus solicitudes, mientras que un 14% afirma que la IA descarta de entrada a más de la mitad de los aspirantes.

Asimismo, el 47% cree que la tecnología ha dejado fuera del proceso a candidatos que, de otro modo, habrían avanzado en la selección. Además, el 51% asegura utilizar IA para identificar perfiles considerados de riesgo, como profesionales percibidos como job hoppers —personas con frecuentes cambios de empleo— o candidatos con interrupciones en su trayectoria laboral.

Según Escalera, marcar a determinados candidatos como riesgosos y descartarlos antes de que un reclutador revise su currículum puede excluir perfiles cuya experiencia profesional cuenta una historia más compleja de lo que un algoritmo está preparado para interpretar. Por ejemplo, quienes regresan al mercado laboral tras un periodo de ausencia pueden aportar capacidades valiosas que no encajan fácilmente en los criterios automatizados de evaluación.

También preocupa que la IA descarte a profesionales que desean cambiar de sector o que cuentan con cualificaciones que no se reflejan exactamente en el lenguaje utilizado en una oferta de empleo, impidiendo que un reclutador humano llegue siquiera a revisar su candidatura.

Laurie Cure, directora ejecutiva de la consultora Innovative Connections, afirma haber observado casos en los que la IA ha eliminado a candidatos altamente cualificados, pero más nerviosos durante las entrevistas, que necesitaban más tiempo del previsto por el sistema para responder a una pregunta. También señala situaciones en las que los aspirantes utilizan un lenguaje diferente al que la IA está programada para detectar, lo que impide que sean recomendados para continuar en el proceso.

Además, ha constatado escenarios en los que la IA utiliza datos históricos para identificar patrones asociados a empleados considerados exitosos, priorizando determinadas universidades, trayectorias profesionales, antigüedad o características similares. Aunque estos elementos no constituyen necesariamente un sesgo en sí mismos, pueden perpetuar la creencia de que existe una correlación directa entre dichos factores y el rendimiento profesional, algo que a menudo no se sostiene.

Por ello, añade Cure, es esencial que las personas sigan formando parte activa de estos procesos, aportando contexto, intuición, matices y la capacidad de detectar potencial en los candidatos, algo que la IA todavía no puede replicar.

Y dice: “Creo que estamos permitiendo que la IA se convierta en el proceso, cuando debería limitarse a apoyarlo para hacer que la contratación sea mejor”.

Priorizar la precisión frente a la velocidad

Para Cure, uno de los principales problemas es que muchas organizaciones han perdido el equilibrio adecuado. En lugar de utilizar la IA como complemento al trabajo humano, la emplean para realizar la mayor parte, o incluso la totalidad, del cribado curricular.

Las empresas que implementan IA únicamente para acelerar determinadas fases del proceso, sin valorar previamente si realmente aportará beneficios, corren el riesgo de introducir sesgos no deseados.

“Esto permite gestionar grandes volúmenes de candidaturas y aporta una mayor consistencia en la aplicación de los criterios de selección, pero probablemente deja fuera a muchos buenos candidatos”, señala, para añadir: “El componente humano debe desempeñar un papel muy activo en la definición de los requisitos de los puestos para evitar que sean excesivamente restrictivos. Las organizaciones deben prestar atención a cómo instruyen a la IA para realizar su trabajo y ser cautelosas al definir los criterios de evaluación y filtrado”.

En última instancia, la IA no es una herramienta que pueda implantarse y olvidarse, ni debería contemplarse únicamente como un mecanismo para ganar eficiencia, ya que muchos procesos continúan beneficiándose —e incluso dependen— del juicio humano.

Por ello, resulta fundamental realizar auditorías periódicas de los sistemas de IA utilizados en contratación y recordar que el uso de estas tecnologías no exime a las organizaciones de sus obligaciones legales y éticas en materia de igualdad de oportunidades laborales. Esto hace que el equilibrio entre intervención humana y automatización sea aún más relevante.

Transparencia y confianza de los candidatos

La irrupción de la IA también ha introducido un factor de desconfianza en los procesos de selección. Los empleadores no siempre tienen claro hasta qué punto los candidatos han recurrido a herramientas de IA, mientras que los aspirantes desconocen en muchos casos cómo se utiliza exactamente esta tecnología durante la contratación.

Los candidatos saben que las empresas están incorporando IA a sus procesos, pero a menudo desconocen el alcance de su utilización y en qué momento pueden esperar interactuar con una persona.

“Esa falta de claridad puede generar escepticismo y frustración, especialmente en un mercado laboral que ya resulta extremadamente competitivo”, explica Escalera. A su juicio, “el objetivo no debería ser convencer a los candidatos de que la IA no se utiliza, sino ayudarles a comprender cómo la tecnología sirve de apoyo a la toma de decisiones, en lugar de sustituir el criterio humano que hay detrás de ellas”.

Como recomendación, Cure propone que las organizaciones comiencen elaborando un mapa completo de su proceso de contratación, identificando cada una de sus fases. Esto permite visualizar con claridad dónde la IA aporta valor y en qué puntos sigue siendo necesaria la intervención humana.

Las empresas pueden acabar dependiendo excesivamente de la IA o, por el contrario, dedicar recursos humanos a tareas que podrían automatizarse y destinarse a actividades de mayor valor añadido.

“Las personas aportan una comprensión más amplia de la trayectoria profesional de un candidato y tienen la capacidad de detectar cuándo alguien posee el potencial necesario para evolucionar dentro de un puesto. También son capaces de interpretar trayectorias profesionales no convencionales y motivaciones personales con mayor precisión que la IA. Por su parte, la IA aporta consistencia, eficiencia, estandarización de criterios y un nivel de objetividad beneficioso para el proceso. Si logramos combinar eficazmente ambos elementos en los puntos adecuados, la contratación sale reforzada, no debilitada”, concluye Cure.

Michael Taylor lleva 25 temporadas en el equipo Mercedes-AMG Petronas de Fórmula 1, donde ha desempeñado todas las funciones relacionadas con las tecnologías de la información, desde el apoyo en pista hasta los sistemas de ingeniería y la transformación empresarial. En la actualidad, como director de TI, dirige un equipo de 18 personas responsable de una de las operaciones con mayor volumen de datos del mundo.

Cuando un coche sale del box, lleva 300 sensores. Mientras está en marcha, genera más de un millón de puntos de datos por segundo. Cada componente, sistema y vuelta produce datos de telemetría que los ingenieros utilizan para ganar fracciones de segundo: la diferencia entre ganar y perder. “La Fórmula 1 lleva muchos años centrada en los datos. La métrica clave en nuestro deporte es el cronómetro, y así ha sido desde que comenzó el Campeonato del Mundo en la década de 1950. Pero ahora lo medimos todo. Si lo mides, puedes mejorarlo”, cuenta.

El reto no es recopilar datos —la Fórmula 1 lleva transmitiendo telemetría en directo desde la década de 1980—. Se trata de tomar decisiones a gran velocidad sin dejar de mantener el control que permite que una operación compleja y de alto riesgo siga funcionando.

Para los CIO que se enfrentan a la presión de avanzar rápidamente en materia de IA al tiempo que gestionan el riesgo, la seguridad y la calidad de los datos, las lecciones que Taylor ha aprendido a base de mucho esfuerzo en el pit lane ofrecen un marco útil: cómo equilibrar la velocidad y el control, cuándo mantener a las personas al tanto de lo que ocurre y por qué una gobernanza “suficientemente buena” es mejor que una gobernanza perfecta que nunca llega a ponerse en práctica.

Innovación frente a estabilidad: “Una batalla constante”

En la mayoría de las empresas, la tensión entre innovación y control se desarrolla a lo largo de trimestres o años. En la F1, ocurre cada semana. “Es realmente difícil. Y es algo que no siempre acertamos. Aquí es donde confiamos en las personas. La experiencia en el sector es realmente importante a la hora de tomar decisiones relacionadas con el cambio”, admite Taylor.

El equipo opera en dos modos distintos. Entre carrera y carrera, se encuentran en la fábrica de Brackley, en el Reino Unido. Las instalaciones, que son la sede central del diseño, la fabricación y el funcionamiento de sus monoplazas de Fórmula 1, ganadores de campeonatos, incluyen un campus tecnológico de 60 000 metros cuadrados. Todo gira en torno a la gestión de proyectos y programas, con margen para la experimentación. Pero a medida que se acerca el fin de semana de carrera, todo se centra en la ejecución.

“Tenemos ese modo normal cuando no estamos compitiendo. Volvemos a la fábrica para diseñar, construir y mejorar”, explica el directivo. “Pero a medida que nos acercamos al fin de semana de carrera, pasamos a ejecutar todo ello de la forma más eficaz. No debemos realizar cambios que afecten a los ingenieros”.

Esta dualidad marca todas las decisiones tecnológicas. La misma agilidad que impulsa la innovación durante la semana debe dar paso a la estabilidad cuando los resultados están en juego. Taylor lo llama una “batalla constante”.

Modernización a la velocidad de las carreras

Mercedes-AMG Petronas llevaba utilizando SAP desde 1999. La plataforma sustenta todo el proceso del equipo, desde el diseño hasta la pista: desde la aprobación del diseño, pasando por la planificación, el aprovisionamiento, la fabricación, las pruebas y el desarrollo, hasta el montaje del coche en la pista.

“Todos esos pasos son procesos fundamentales”, afirma Taylor. Por eso, cuando llegó el momento de modernizarse, el equipo lo abordó como una parada en boxes: planificado al segundo, ejecutado con precisión. Eligieron RISE with SAP —el paquete combinado de ERP en la nube y migración del proveedor—, acordaron iniciar el proceso en diciembre de 2024 y fijaron como objetivo la puesta en marcha en agosto de 2025, coincidiendo con el parón obligatorio de dos semanas del deporte.

“Es el momento perfecto para introducir cambios. Tenemos que planificarlo todo a la perfección para que todo vaya sobre ruedas cuando volvamos a competir”»”, explica.

Terminaron ocho semanas antes de lo previsto. “Somos unos obsesionados del control debido a la naturaleza de este deporte y a sus plazos estrictos”, afirma. Su equipo prefiere gestionar los sistemas de forma interna en lugar de depender de grandes integradores de sistemas que “se asoman un poco y desaparecen”. Con solo 18 personas en el equipo de TI, recurren a la experiencia de SAP para problemas específicos y, a continuación, retoman las riendas. “Una vez hecho esto, seguimos siendo los responsables y nos encargamos de la gestión”, agrega, “y SAP hace lo que mejor sabe hacer”.

El camino seguro debe ser el más fácil

La propiedad intelectual en la Fórmula 1 tiene una vida útil muy corta. En cuanto un nuevo componente se monta en el coche y se fotografía en el pit lane, los competidores pueden verlo. Pero eso no resta valor a lo que hay detrás.

“La verdadera ventaja no es solo la pieza”, afirma Taylor. “Es el razonamiento, el modelado, la simulación, los modos de fallo, las compensaciones y la dirección de desarrollo que hay detrás”.

Proteger todo eso requiere una estrategia de seguridad ofensiva. El responsable de seguridad de la información de Taylor depende directamente de él, y el equipo pone a prueba activamente sus propias defensas. “Actúa, piensa y trabaja como un hacker. Estamos pensando en cómo podemos contrarrestar las amenazas sin que ello afecte a los usuarios finales”, relata.

En una cultura que fomenta la ingeniería y en la que se da libertad a las personas para actuar con rapidez, una seguridad demasiado estricta resulta contraproducente. Taylor aprendió pronto que la perfección es enemiga del progreso. “Si la seguridad se interpone en el camino del negocio, este encontrará formas de sortearla. La tarea no consiste en ralentizar a la organización, sino en hacer que el camino seguro sea el más fácil”.

El factor humano

Dada la evolución semanal de la IA, el equipo de Taylor está llevando a cabo proyectos piloto en toda la organización: aprendizaje automático para la simulación, flujos de trabajo automatizados en la planificación de la producción y copilotos que ayudan a los desarrolladores a escribir código. Pero se resiste a la tentación de precipitarse.

“Todavía estamos buscando nuestro camino”, afirma. “No hay una solución única para todos. Estamos probando todo lo que hay disponible, pero dentro de seis a diez meses tomaremos decisiones sobre qué ampliar”.

A pesar del revuelo que rodea a la IA basada en agentes, Taylor sigue apostando por la supervisión humana. “Sigo creyendo firmemente que ‘los humanos deben estar en el bucle’. Cuando nuestra plantilla esté en sintonía con la IA, ahí es donde veremos el beneficio real: cuando esta complemente a nuestra gente”.

La IA también ha elevado el listón en materia de gobernanza de datos. “Lo que ahora se considera ‘suficientemente bueno’ incluye una mayor visibilidad, permisos más claros y una propiedad más definida», explica Taylor. «Hay que ser más riguroso a la hora de determinar a qué datos puede acceder la IA”.

La clave, empezar por las consecuencias

El consejo de Taylor para los CIO de otros sectores que se enfrentan a cuestiones similares es aparentemente sencillo: “Empieza por las consecuencias, no por la tecnología”.

En los servicios financieros, podría tratarse de un perjuicio para el cliente o de un incumplimiento normativo. En la sanidad, de la seguridad del paciente o de la pérdida de la confianza pública. En la F1, la consecuencia de un fallo de seguridad es la pérdida de la ventaja competitiva.

“Una vez que comprendes las consecuencias, puedes decidir qué requiere un control más estricto, qué hay que supervisar, qué hay que conservar y qué simplemente necesita mejores prácticas de seguridad”, afirma Taylor.

Es una lección aprendida a lo largo de 25 temporadas al límite de lo técnicamente posible, donde las decisiones se toman en milisegundos y el margen entre el éxito y el fracaso se mide en fracciones de segundo.

El factor clave para el éxito de la implantación de la IA está pasando a ser, en gran medida, el talento disponible, y no las herramientas de IA instaladas, lo que ejerce presión sobre los responsables de TI para que mejoren las competencias de su plantilla. Dado que las competencias en IA son las más demandadas y las más difíciles de encontrar, muchos responsables de TI y sus colegas de la alta dirección están poniendo en marcha programas integrales de formación en IA para los empleados, tanto para los profesionales de TI que desarrollan las herramientas de IA como para los usuarios de la empresa que las utilizarán.

Las empresas inteligentes tendrán que invertir mucho en la mejora de las competencias, afirma Chris Campbell, director de sistemas de información de la Universidad DeVry (California, Estados Unidos). “El ritmo del cambio es sencillamente demasiado rápido como para depender únicamente de la contratación externa. Las organizaciones que desarrollen capacidades de IA entre su plantilla actual tendrán ventaja sobre aquellas que intenten ganar una guerra de ofertas por un grupo relativamente reducido de expertos”, relata.

Además, los elementos clave que conducen a una implementación beneficiosa de la IA han cambiado con el tiempo, añade. “Al principio, a todo el mundo le preocupaba el acceso a las herramientas de IA. Hoy en día, las herramientas están por todas partes. Lo que veo que cuesta a las organizaciones es averiguar cómo aplicarlas a problemas empresariales reales e integrarlas en la forma en que se lleva a cabo el trabajo en la práctica”, agrega.

En DeVry, algunos de los defensores más acérrimos de la IA no provienen de ámbitos tradicionales de la IA, sino de la ingeniería de software, el análisis empresarial, la ciberseguridad, la gestión de proyectos y las operaciones, afirma. “Entienden el negocio, saben dónde están los puntos de fricción y pueden ver dónde la IA puede generar valor. Esas habilidades suelen ser más importantes que una experiencia profunda en un modelo o herramienta concretos”, señala.

Es difícil encontrar profesionales con experiencia en IA, sobre todo cuando los responsables de TI buscan candidatos que hayan logrado llevar con éxito iniciativas de IA de la fase experimental a la de producción. “No creo que todas las empresas necesiten crear un gran equipo de especialistas en IA”, afirma Campbell. “En muchos casos, las personas mejor posicionadas para impulsar la adopción de la IA ya se encuentran dentro de la organización”.

Mejora de las competencias para una cultura de creadores de IA

La firma de servicios profesionales y contabilidad KPMG está abordando su reto de talento en IA impartiendo formación generalizada en IA a sus empleados, afirma Rema Serafi, vicepresidenta de fiscalidad de KPMG. El principal problema de muchas organizaciones en materia de IA en 2026 será la falta de talento, no la falta de tecnología, añade.

El 40% de los CIO encuestados para el informe ‘State of the CIO‘ de este año señalaron la falta de talento interno como uno de los principales obstáculos para implementar sus estrategias de IA.

Para hacer frente a esto, KPMG ha puesto en marcha un programa piloto de formación en IA de seis semanas, con el objetivo de que todos los empleados puedan implementar sus propias herramientas de IA, explica Serafi. El programa familiariza a los empleados con Python y otras tecnologías que sirven de base para las herramientas internas de IA, añade.

KPMG también ha renovado la estructura de sus equipos para garantizar que tres categorías de empleados —usuarios avanzados de IA, creadores y desarrolladores— trabajen en estrecha colaboración, afirma Serafi. “Todo el mundo tendrá acceso a nuestras herramientas y todo el mundo será un usuario avanzado, hasta tal punto que aquellos profesionales que no contaban con conocimientos de IA al incorporarse, que no eran ingenieros ni tecnólogos, si quieren aprender, les certificaremos para que también puedan crear herramientas”, afirma.

Implementar herramientas de IA sofisticadas y de primera clase sin formar a los empleados es como comprar un coche de Fórmula 1 pero no contratar a un piloto profesional, dice. “Si no contamos con profesionales que sepan cómo utilizarla, no podrán sacar el máximo partido a lo que tienen a su disposición”, añade Serafi.

KPMG encargó un estudio a la Universidad de Texas (Estados Unidos) y descubrió que los empleados que utilizan la IA con regularidad producen un trabajo de mayor calidad y se sienten menos estresados. Los empleados que sean usuarios expertos en IA progresarán más rápido en sus carreras, sugiere. Sin embargo, uno de los retos de los programas de formación es mantenerse al día con la rapidez con la que evoluciona la IA. “De hecho, las funciones están cambiando en muy poco tiempo. Antes se veía a ingenieros tradicionales trabajando con IA, pero ahora se ven profesionales que realmente pueden orientar, dar forma y dirigir la IA en el trabajo que realizan para sus clientes”.

Reciclaje profesional: “El único camino realista hacia el futuro”

Otro defensor de la formación integral en IA para los empleados es Elmer Morales, fundador y director ejecutivo de Koder.com, una startup de programación de IA agente. Según él, encontrar talento externo en el ámbito de la IA se ha vuelto extremadamente difícil para la mayoría de las empresas.

“El reciclaje profesional ya no es opcional. Es el único camino realista a seguir para la mayoría de las organizaciones. El mercado de talento externo no puede satisfacer simultáneamente las necesidades de todas las empresas, y esperar a que las universidades se pongan al día no es una estrategia”, afirma.

Las empresas que triunfan con la IA consideran la mejora de las competencias como una inversión fundamental, no solo como una iniciativa de recursos humanos, añade Morales. “La falta de talento es, en estos momentos, el principal obstáculo concreto para las ambiciones en materia de IA. Las empresas pueden adquirir los mejores modelos, la mejor infraestructura y las mejores herramientas, y aun así no producir nada de valor porque carecen de personas que sepan cómo integrarlo todo en un sistema que realmente funcione en producción”, explica.

Morales sugiere que los responsables de TI recurran a su equipo de ingeniería actual para desarrollar el talento necesario para la implementación de la IA. “Los ingenieros que ya se dedican a esto con obsesión por las noches y los fines de semana, que lanzan proyectos personales y experimentan con nuevos modelos, solo necesitan permiso, recursos y un problema real que resolver. Los mejores equipos de IA que he visto no se crearon mediante la contratación, sino creando las condiciones para que las personas adecuadas dieran un paso al frente”, concluye.

La multinacional farmacéutica danesa Novo Nordisk está muy interesada en acelerar el tiempo que se tarda en lanzar medicamentos al mercado a medida que expiran las patentes. “Si tienes un medicamento superventas, un retraso de una semana puede suponer entre 10 y 100 millones de dólares”, afirma Stephanie Bova, responsable de transformación digital de la empresa. “Es una cantidad enorme, porque dispones de menos tiempo de protección mediante patente”.

La IA generativa ofrecía la posibilidad de acelerar drásticamente múltiples etapas del proceso de desarrollo de medicamentos. Y, dado que Novo Nordisk ya llevaba un seguimiento minucioso de la duración de sus procesos clave, contaba con una ventaja de la que carecían muchas otras empresas. Por lo tanto, debería haber sido relativamente sencillo incorporar un poco de IA generativa, ver cómo mejoraba la productividad y observar cómo llegaban los beneficios. Pero no fue tan fácil. El proceso de desarrollo de un fármaco consta de muchas partes, que tienen lugar en distintos momentos y en distintos departamentos. “Las personas son expertas en sus propios ámbitos, pero no necesariamente conocen el siguiente ámbito ni cómo encaja todo. El sistema es tan grande y complejo que no se puede ver todo el rendimiento de una sola vez”, afirma Bova.

Es posible que la documentación de los procesos no se corresponda con lo que la gente hace realmente en la práctica, y que diferentes personas realicen la misma tarea de formas distintas. Además, algunas tareas cruciales pueden pasar prácticamente desapercibidas desde fuera. El equipo de fabricación, por ejemplo, puede formar parte de un grupo completamente diferente y no ser consciente de que el medicamento se está preparando para su presentación ante la FDA (la agencia gubernamental estadounidense del medicamento), y que aún no tiene toda la documentación lista. “Así que has avanzado muy rápido solo para tener que esperar a que ellos te alcancen”, añade Bova.

Este es solo uno de los muchos retos a los que se enfrentan las empresas al intentar medir los resultados de los proyectos de IA, y la razón por la que las encuestas son tan contradictorias.

Si nos fijamos en las tareas individuales, Novo Nordisk puede demostrar mejoras en la productividad y claros beneficios positivos derivados del uso de la IA. Pero si damos un paso atrás y analizamos los resultados financieros de la empresa, el panorama se vuelve más confuso. En primer lugar, si se omiten pasos críticos, el tiempo de comercialización no mejorará. Además, un nuevo medicamento tarda años en llegar a los clientes, por lo que los efectos positivos en los resultados no se notarán hasta pasado un tiempo. Y eso es solo el principio del problema que plantea la medición del retorno de la inversión.

Medición de procesos

Para abordar los puntos ciegos de sus procesos, Novo Nordisk recurrió a la nueva generación de minería de procesos: gemelos digitales de las operaciones en tiempo real impulsados por IA. “Nos asociamos con la empresa de inteligencia de procesos Celonis para obtener un gemelo digital de nuestros datos de procesos. Fuimos los primeros del sector en aplicarlo al ámbito clínico”, explica Bova. La herramienta recopila información de los sistemas de la empresa para hacer un seguimiento de lo que los empleados hacen realmente, en lugar de utilizar encuestas para recabar información sobre lo que una parte de los empleados recordaba haber hecho en algún momento.

El primer proyecto consistió en un proceso sencillo de siete pasos y, al crear un gemelo digital del mismo, Novo Nordisk descubrió que, dependiendo de quién lo llevara a cabo, podía tratarse de un proceso de cinco o de nueve pasos. “Si reúnes a diez expertos en la materia en una sala, obtienes todo tipo de interpretaciones y, con el tiempo, se producen desviaciones”, cuenta.

El proyecto puso de manifiesto múltiples fallos en los procesos existentes. En algunos casos, fue necesario volver a formar a los empleados. En uno de ellos, hubo que actualizar la interfaz de usuario. Sin embargo, una vez que se estandariza un proceso, surge la oportunidad de tomar una “fotografía” de la situación anterior, de modo que haya algo con lo que comparar posteriormente y comprobar si la mejora mediante IA o la automatización arrojan algún resultado.

Otra cuestión que tuvieron que resolver de antemano fue decidir qué hacer con el tiempo ahorrado que se generara. “No quieres despedir a nadie”, afirma Bova. “Se trata de personal altamente cualificado y difícil de encontrar. Quizá deberíamos plantearnos redistribuir un poco los equipos”.

En la actualidad, la empresa cuenta con varios cientos de agentes de IA en funcionamiento, etiquetados dentro de la infraestructura del gemelo digital para poder identificarlos. “Si algo falla, sabemos exactamente dónde solucionarlo”, dice, y añade que la siguiente fase es la coordinación entre múltiples agentes. “Hoy en día, los tenemos conectados, pero no contamos con ‘agentes de agentes”.

Aún es demasiado pronto para saber si hay retorno de la inversión, ya que, en el desarrollo de fármacos, el proceso lleva años. “Pero, al analizar el proceso de principio a fin, espero que podamos recortar dos años del ciclo de desarrollo. Dos años menos hasta la comercialización, en comparación con la situación actual”»”, indica.

Los medicamentos que ya se encuentran en la fase final de desarrollo no experimentarán una aceleración tan notable, pero los que acaban de iniciarse serán los que más se beneficien. Sin embargo, los resultados finales no se verán hasta dentro de varios años.

La industria farmacéutica no es la única en la que el verdadero valor proviene de la optimización simultánea de múltiples procesos interconectados. Según PwC, los proyectos tácticos de IA a menudo no aportan un valor cuantificable, y los beneficios tangibles provienen de implementaciones a escala empresarial coherentes con la estrategia de negocio.

De hecho, muchas empresas no han experimentado ni un aumento de los ingresos ni una reducción de los costes gracias a la IA en los últimos 12 meses, a pesar de su adopción casi universal. Aun así, el gasto empresarial en IA se prevé que casi se duplique a finales de año en comparación con el año pasado, según KPMG.

Medición de la productividad

La mayoría de las empresas empiezan a pequeña escala, implantando chatbots de IA para los empleados con el fin de ayudar a mejorar la productividad. Y el ritmo de adopción en este ámbito ha sido asombrosamente alto, solo equiparado por la incapacidad de medir las ganancias de productividad que se supone que se deben alcanzar.

Disponer de una referencia es clave, afirma Anand Rao, profesor de IA en la Universidad Carnegie Mellon, de Estados Unidos, pero en algunos casos resulta difícil de medir y, en otros, es prácticamente imposible. Tomemos, por ejemplo, las decisiones relacionadas con los seguros, en las que los resultados pueden tardar años en hacerse evidentes. En el caso de los seguros de vida, podrían ser décadas, afirma. Y para algunos tipos de decisiones, las empresas no disponen de ningún tipo de indicador.

“Existe un estigma social a la hora de decir que estoy tratando de analizar tu proceso de toma de decisiones y lo bien que las estás tomando. Como seres humanos, no nos gusta que se evalúen nuestras decisiones”, señala. Luego, cuando una decisión sale bien al final, la gente se atribuye encantada el mérito. “Si la decisión sale mal, se achaca a factores externos”.

Pero incluso en el caso de tareas específicas en las que es posible realizar mediciones, las empresas a menudo no se esfuerzan por llevarlas a cabo antes de implementar herramientas de IA. “No partimos de una referencia”, apunta Julie Averill, antigua vicepresidenta ejecutiva y directora de sistemas de información global de la cadena de moda Lululemon. Averill es ahora directora general de Gold Thread, una consultora de transformación digital. “Partimos de la suposición de que la IA iba a ayudar a la gente a tomar mejores decisiones. Y eso te lleva a no poder medir bien los resultados”, explica.

Existen métricas alternativas que una empresa puede tener en cuenta en su lugar, añade, como las tasas de uso o la satisfacción de los usuarios. “Esto está ocurriendo y está aportando beneficios, algunos de los cuales se pueden ver y otros no. Hay que confiar en el proceso. Es igual que con la nube. Sabes que es el camino del futuro y puedes ver las ventajas, pero es difícil llegar hasta allí, y se requieren muchos cambios. Pero cuanto antes lo hagas, antes te habrás adaptado a la nueva forma de operar y podrás sacarle realmente partido”.

Hay otras áreas en las que es más fácil disponer de métricas concretas, como el servicio de atención al cliente. “Se trata de tareas repetitivas y suele ser el primer ámbito que las empresas automatizan con IA. Hay resultados muy tangibles que se pueden medir y se puede establecer una referencia muy sólida”, explica Averill.

Lululemon también lleva años utilizando la IA para mejorar la personalización y las recomendaciones, y esa es otra área que se puede cuantificar. Además, la automatización puede reducir la introducción manual de datos, lo que disminuye las tasas de error. La IA también se puede utilizar para ayudar en la supervisión del cumplimiento normativo, la detección de fraudes y el mantenimiento predictivo de los equipos, todos ellos casos de uso que se pueden cuantificar.

¿Pero la productividad de los empleados en general? Eso es difícil de medir, y no solo para Lululemon. Una forma obvia podría ser analizar los despidos en profesiones expuestas a la IA. Al fin y al cabo, los titulares están por todas partes. Pero en un informe publicado en marzo, Anthropic no encontró indicios de un aumento del desempleo en las profesiones altamente expuestas, aquellas en las que las personas tienen más probabilidades de ser despedidas debido a la IA.

A principios de 2025, la empresa de investigación METR intentó cuantificar la productividad de los desarrolladores comparando la rapidez con la que los desarrolladores experimentados eran capaces de realizar tareas con IA y sin ella. ¿El resultado? Los desarrolladores afirmaron que esperaban que la IA les permitiera trabajar un 24% más rápido y estimaron que, en realidad, la IA les había permitido hacerlo un 20 % más rápido. Pero los datos revelaron una realidad totalmente diferente. El uso de la IA, en realidad, les ralentizó un 19%.

Por supuesto, las herramientas de IA están mejorando. METR intentó realizar un estudio de seguimiento, comparando de nuevo las tareas realizadas con y sin IA, pero no pudo encontrar suficientes desarrolladores dispuestos a volver al enfoque sin IA, a pesar de que los investigadores les pagaban por participar en el estudio.

Existen casos anecdóticos de empresas en las que un solo ingeniero realiza el trabajo de cien gracias al uso de la IA. O aquella vez en que se filtró accidentalmente todo el código fuente de Claude Code, de medio millón de líneas, y el desarrollador coreano Sigrid Jin creó una reconstrucción desde cero en dos horas, que luego subió a GitHub, donde se convirtió en el proyecto más rápido de la historia en alcanzar las 100.000 estrellas.

Pero, como ocurre con cualquier otro tema relacionado con la IA, la realidad es más compleja. En el caso concreto del desarrollo de software, escribir el código es, en realidad, solo una pequeña parte de lo que implica desarrollar software.

La consultora DX analizó recientemente métricas clave de ingeniería de 400 empresas y, en un informe reciente, constató que el uso de la IA había aumentado un 65% desde noviembre de 2024, pero que la productividad relacionada con la IA se situaba justo por debajo del 10%.

Costes ocultos

Al igual que resulta difícil medir los beneficios de la IA en términos de productividad, también puede resultar complicado cuantificar los costes. Cuando una empresa empieza a utilizar la IA, los costes pueden ser relativamente fáciles de estimar. ¿A cuánto ascienden las cuotas mensuales totales de suscripción a los chatbots de IA que utilizan los empleados? ¿Cuál es el coste de entrenar o ajustar un modelo personalizado? Pero cuando se pasa a casos de uso más complejos, los cálculos se vuelven más difíciles, afirma Averill. “Ahora existen todos los sistemas relacionados con la IA. Esos son más difíciles de cuantificar, pero su impacto es mayor”, dice.

Por ejemplo, si la IA se integra en los procesos empresariales mediante RAG, existe el gasto continuo de las llamadas a la API, pero también los cambios que hay que realizar en otros sistemas, explica. Y la cosa se complica cada día más. “No hemos realizado un esfuerzo muy concertado para implantar la telemetría y la instrumentación”, afirma Swaminathan Chandrasekaran, director global de IA y laboratorios de datos en KPMG. Según él, obtener una visión global de los costes totales de la IA en una empresa es como predecir el tiempo.

“La razón por la que contamos con un sistema de predicción meteorológica tan impresionante en este país es que disponemos de decenas de miles de estaciones meteorológicas que recopilan datos”, explica. “Sin eso, no sabríamos qué tiempo va a hacer”.

Las empresas deben implantar sistemas de medición para evaluar todos los aspectos del consumo relacionado con la IA, señala, empezando por el número de tokens utilizados, quién los utiliza y cómo se correlaciona esto con el rendimiento laboral. “Esa medición brilla por su ausencia”, afirma.

Al menos cuando los humanos utilizan chatbots de IA, hay un límite en el número de preguntas que son físicamente capaces de formular, además de unos costes de suscripción predecibles. Y cuando los procesos empresariales se habilitan con IA a través de RAG, las llamadas a la API de los modelos de lenguaje grandes (LLM) las realizan sistemas empresariales predecibles y programados de forma tradicional.

Pero ahora, la IA agentiva está empeorando aún más las cosas, ya que los agentes pueden actuar de forma impredecible y el número de llamadas a la API puede dispararse rápidamente fuera de control. En un informe del Boston Consulting Group, dos tercios de las empresas señalan gastos de escalado de la IA incontrolables.

Otro coste que algunas empresas quizá no prevean bien, o que no controlen porque forma parte de un presupuesto diferente, es el relacionado con los datos. Ya sea preparando datos para el entrenamiento o el ajuste fino, utilizando incrustaciones de RAG o configurando el acceso directo a MCP a través de agentes, estos costes pueden acumularse rápidamente cuando entra en escena la IA.

“Las tarifas de salida son uno de los gastos más importantes”, afirma Tom Coughlin, miembro del IEEE y presidente de la consultora Coughlin Associates. “Si tienes que sacar datos de la nube, esas tarifas de salida podrían ser considerables”. Además, están todos los costes de personal que conlleva la implementación de la IA, añade.

“A largo plazo, la IA aportará un gran valor a las personas, pero estas deben saber cómo utilizarla correctamente. Si no cuentan con esas habilidades, se encontrarán en desventaja”, expone.

Soluciones y mensajes contradictorios

Luego está la cuestión de resolver los problemas. La mayoría de las empresas han sufrido al menos un incidente relacionado con la IA en los últimos 18 meses, y la mayoría de ellos han supuesto pérdidas económicas, algunas de más de 500.000 dólares. Además, está la IA que se está integrando en todo.

“Conocemos nuestros costes directos”, afirma Andrew Johnson, director de sistemas de información (CIO) de Brownstein Hyatt Farber Schreck, un bufete de abogados estadounidense. “Pero donde resulta más difícil de cuantificar es con las plataformas que ya tenemos implantadas y las aplicaciones SaaS que no contaban con capacidades de IA. Nos piden aumentos extraordinarios y los atribuyen a las nuevas capacidades que aporta la IA. ¿Cuánto se le debe atribuir a la IA? Eso es un poco difuso”, relata.

Incluso cuando la IA permite ahorrar dinero, a menudo hay costes adicionales asociados a ello. Por ejemplo, el bufete gastaba unos 70.000 dólares al año en una plataforma de gestión de contratos. Desarrollar su propia versión con IA supuso unos 40.000 dólares en costes de mano de obra y otros 3.000 dólares al año en alojamiento. El mantenimiento continuo será mínimo para esa aplicación en concreto, añade, lo que supondrá un total de otros dos mil dólares al año.

Pero también hay otros costes indirectos asociados al funcionamiento de las aplicaciones propias, como las auditorías de seguridad, las evaluaciones de vulnerabilidad, las pruebas de penetración y la revisión del código. “Cuanto más compleja y arriesgada es la plataforma, menor es el interés por intentar crear una solución interna”, indica.

Aun así, el equipo de desarrollo de software es ahora mucho más productivo gracias a la IA, ya que cuatro o cinco desarrolladores son capaces de hacer el trabajo de 20 o 30. Pero las mejoras en la productividad no se traducen en un ahorro de mano de obra, ya que los desarrolladores tienen mucho trabajo nuevo que hacer. “Tenemos una enorme lista de oportunidades pendientes para desarrollar soluciones”, afirma.

La tendencia del trabajo a expandirse para ocupar todo el tiempo disponible no se da solo en el desarrollo de software, señala Rao, de Carnegie Mellon. Supongamos, por ejemplo, que se espera que la IA suponga una mejora del 20% en la productividad, explica. “Antes había cien personas haciendo ese trabajo, y ahora solo necesitamos 80. Pero, al final del año, la plantilla no ha cambiado. «En las tareas que realizaban, hay una mejora, añade, “pero las personas añadirán tareas para suplir o complementar ese 20%. No es que se vayan a casa una hora antes, sino que están encontrando otras actividades que generan valor”.

De hecho, en algunos casos, el aumento de la productividad en una empresa puede llegar a perjudicar los resultados. Los abogados, por ejemplo, cobran por horas. “La eficiencia va en contra de nuestras formas tradicionales de ganar dinero”, afirma Johnson, de Brownstein. “Tenemos que pensar más allá de eso. No es perjudicial para nuestros intereses a largo plazo, pero supone un reto a corto plazo. Sin embargo, si no lo hacemos, es probable que no seamos competitivos a medio y largo plazo”.

Así pues, si una nueva herramienta de IA ayuda a un abogado en la diligencia debida, no existe una relación directa entre la inversión en esa herramienta y el aumento de los ingresos. “Es un hecho que la dirección es la correcta”, afirma Johnson. “Pero no podemos afirmar que vaya a generar un rendimiento concreto”.

Power consumption worldwide for data centers is projected to grow to 565 terawatt hours (TWh) in 2026, up 26% from 447 TWh in 2025, with AI-oriented data centers taking up an increasing amount of the pie.

Worldwide data center power demand is expected to rise 27% in 2026 and reach 133 gigawatts (GW), up from 105GW in 2025. It is projected to reach 291GW by 2030, which reflects the unprecedented scale and pace of GenAI boosting demand.

Those figures consider variables like parts and supply shortages, delayed or cancelled data center projects, and the impact of the conflict with Iran, said Linglan Wang, director analyst and lead economist at Gartner.

AI-optimized servers are a relatively new phenomenon but they have rapidly gained uh traditional data centers in terms of power use. Gartner estimates AI-optimized server adoption will account for 31% of data center power consumption in 2026, and that by 2027 their power consumption will surpass that of conventional servers.

“Surging demand for compute-intensive AI workloads is driving unprecedented data center power growth, while AI capacity is now constrained by power availability, making data center power security the new battle ground for scaling and protecting margins in the global AI race,” said Wang in a statement.

Wang said of the 565TWh consumed this year, the U.S. will account for about 204TWh, or 36% of the total amount consumed. And of the 204TWh consumed this year, dedicated AI data centers will consume 68TWh, or one-third of the total. So in just five years, AI data centers have gone from zero to of the total power consumption in the US.

Non-AI data center growth has been minimal by comparison.

The difference in growth of power consumption between conventional servers and AI-optimized servers is remarkable. Worldwide, conventional servers consumed 193 terawatt hours (TWh) of power in 2025 and are projected to rise 1.2% to 195 TWh in 2026 and another 2.4% in 2027 to 200 TWh This 3% basic growth will continue to 2030.

Now compare that to the AI-optimized servers. They consumed 95 TWh of power in 2025, rose 84.2% to 175 TWh in 2026 and another 47.8% to 258 TWh in 2027. By 2030, Wang estimates AI-optimized servers will account for near half of all power consumed by data centers worldwide.

With data center power electricity consumption estimated to reach over 1,200TWh by 2030, grid supply will be insufficient to meet the demands of future data center construction, affecting all data center users.

“Infrastructure and operations leaders must prioritize efficiency upgrades and secure grid access. They also need to invest in high-efficiency cooling systems and edge computing to mitigate power constraints and ensure sustainable, scalable growth,” Wang said.

Conocido sobre todo por sus servicios como “boutique de inversión”, el banco Singular Bank, nacido en el año 2020 gracias al impulso del exconsejero delegado del Banco Santander Javier Marín Romano, después de adquirir y transformar la estructura del antiguo banco digital Self Bank, es en la actualidad una entidad con más de 400 profesionales, 17 oficinas en España y más de 180 banqueros y agentes financieros que gestionan casi 18.000 millones de euros de patrimonio de clientes.

La compañía financiera es noticia estos días por un sonado cambio de propietario: el grupo inversor estadounidense Warburg Pincus, que poseía más del 93% de las acciones, ha vendido su participación a un grupo de inversores nacionales e internacionales liderados por ING, que se convierte ahora en el principal dueño de la entidad, con 40%, mientras que el resto se diversifica entre ‘family offices’ españoles (21,5%), el propio equipo directivo y los empleados del banco (15,5%), la firma española de inversión ProA Capital (15%) y la financiera mexicana Actinver (8%). Un movimiento que, sin embargo, no afectará a la operativa de Singular Bank, que seguirá funcionando como una entidad independiente dentro del mercado español de banca privada y con una oferta de productos complementaria a la de su nuevo dueño mayoritario, ING, como confirma a CIO ESPAÑA Rubén Andrés Priego, director general de Tecnología y Operaciones de Singular Bank y miembro del equipo directivo, entrevistado por esta cabecera unos días antes de que se hiciera pública esta información. La charla gira, no obstante, en torno a otro asunto: el intenso viaje digital experimentado por el banco, y los retos y las oportunidades que se abren a la organización en un futuro próximo.

El directivo, un ejecutivo experimentado en el mundo de la banca minorista y privada y en consultoría financiera (desempeñó puestos de responsabilidad en Banco de España, Banco Popular, BBVA, Banca March y EVO Banco) aterrizó en Singular Bank en enero de 2025. En este periodo, explica, ha inyectado las últimas innovaciones de la inteligencia artificial al modelo “híbrido” con el que contaba la entidad, que combina “la excelencia digital y en automatización con una labor intrínsecamente humana”. Pero empecemos por el principio.

La IA da una vuelta de tuerca a la transformación de Singular Bank

“Singular Bank es un banco con una historia relativamente corta, de unos siete años”, rememora el CIO durante la entrevista, subrayando que, aunque la entidad nació como un banco orientado a la banca privada, a través de Self Bank dispone de una plataforma bancaria 100% digital que permite a los clientes gestionar sus inversiones y “tomar sus propias decisiones financieras”. Al aterrizar en la corporación, hace más de un año y medio, y después de mantener, dice, casi 70 reuniones con el consejo de administración, el comité de dirección y empleados de diferentes áreas del banco, el directivo vio la necesidad de “llevar a cabo un plan de transformación que no solo pasaba por modificar la plataforma tecnológica que había y que mantenía la cuenta de resultados, así como todos los canales, la plataforma de inversión, etc. sino afrontar una segunda gran ola: el uso de la inteligencia artificial en la compañía”.

La estrategia de Singular Bank en torno a la inteligencia artificial se articula en tres grandes líneas de actuación, como relata Rubén Andrés Priego. La primera consiste en impulsar el uso de la IA en el trabajo diario de los empleados. Para ello, la empresa selló un acuerdo con OpenAI, en marzo de 2025, con el fin de distribuir 50 licencias de ChatGPT entre los 400 profesionales de la entidad. La segunda línea se centra en la aplicación de la IA al ámbito de la ingeniería, bajo un enfoque de context engineering (ingeniería de contexto), con el que están transformando su modelo de desarrollo tecnológico. Y el tercer eje pasa por crear una arquitectura propia orientada a los agentes de inteligencia artificial. Sobre esta base, explica el CIO, la entidad ha lanzado Singularity, una plataforma que integra la IA de OpenAI, la visión del equipo de estrategia y el criterio del banquero para ofrecer un mejor asesoramiento al cliente, “uno de los proyectos estrella de este año”.

Esta apuesta por la IA y, en concreto, por la tecnología de OpenAI es de tal calado que la empresa creadora de ChatGPT ha seleccionado al de Singular como uno de los casos de éxito más destacados de Europa en la aplicación de IA dentro del sector financiero. “Lo que tiene Singularity de particular es que lo han creado los propios usuarios”, indica Andrés, que explica que el banco formó a los usuarios de ChatGPT para que fueran ellos los que identificaran oportunidades y propusieran nuevas aplicaciones. “Una de las grandes ventajas de la IA generativa es que ha reducido las barreras tecnológicas: hoy el valor diferencial está más en identificar el caso de uso adecuado que en la propia ejecución técnica”, añade Andrés Priego.

A partir de ahí, relata, los banqueros empezaron a detectar necesidades que requerían una infraestructura más sofisticada que una simple interfaz conversacional. “Fue entonces cuando decidimos crear un grupo de 20 banqueros que actuaron como embajadores de Singularity y participaron activamente en el diseño de la herramienta. Mantuvimos sesiones semanales para perfeccionarla y, hoy en día, los resultados son de éxito total”.

La plataforma Singularity está diseñada para facilitar el asesoramiento al cliente en las fases previas a cada reunión. La plataforma recopila información procedente de todos los sistemas del banco y se integra con Salesforce, gestores documentales, bases de conocimiento, datos de rentabilidad y catálogos de productos. Todo ese ecosistema está conectado a una red de 20 agentes de IA que analizan la información y generan recomendaciones y resultados útiles para el banquero. El objetivo, indica el CIO, es “liberar a los profesionales de tareas operativas y de bajo valor”, como la recopilación manual de información, para que puedan centrarse en lo realmente importante: “El asesoramiento personalizado al cliente”.

“Una de las grandes ventajas de la IA generativa es que ha reducido las barreras tecnológicas: hoy el valor diferencial está más en identificar el caso de uso adecuado que en la propia ejecución técnica”

La acogida de la plataforma, subraya Rubén Andrés, ha sido excelente. “Actualmente, 80 banqueros participan en el proyecto y el 90% utiliza la herramienta de forma habitual en su trabajo diario”. Este mes de julio, añade, Singularity se ampliará a los 200 banqueros que tiene la entidad. “La vamos a conectar con toda la inteligencia de inversiones y productos. Ya no va a ser solo una herramienta de recolección de información, sino que también utilizará la inteligencia del banco para perfilar el asesoramiento”.

El ROI (retorno de inversión) de este caso de uso es significativo: “Los banqueros se ahorran entre 60 y 90 minutos diarios en la preparación de reuniones”, afirma el CIO. Un ahorro que redunda en “más tiempo para pensar qué necesita el cliente y qué podemos aportarle como banco para mejorar su día a día, su vida y sus objetivos”. 

El banquero, no obstante, sigue siendo una pieza fundamental de la ecuación, según Rubén Andrés. “Es indispensable; por ejemplo, en momentos de incertidumbre, donde hay caídas de mercados y la situación se tensa, el banquero tiene la cabeza fría y pone raciocinio a las emociones del cliente, al que acompaña en las inversiones, pero siempre apoyado en unas capacidades avanzadas de análisis de datos e inteligencia”. Es más, según el CIO, “el humano es imprescindible en el mundo de la banca”, sea cual sea el modelo: “Banca masiva, mainstream digital, banca privada o un término intermedio que sería Self Bank, un banco 100% digital con capacidades avanzadas y con unos banqueros remotos que también pueden asesorar a los clientes”.

El ejecutivo cree que la banca del futuro será más humana porque es precisamente esto lo que va a diferenciar a los distintos actores entre sí. “El factor humano aumentará la calidad en el asesoramiento y en el trato al cliente. Por otro lado, también veremos redes de agentes en el entorno digital; me atrevería a decir que ya no competiremos por la experiencia de usuario (‘user experience’), sino por la del agente (‘agent experience’). Vamos a tener que generar capas de agentes que se comuniquen entre sí y generen una experiencia muy fluida para poder analizar los productos de los que disponemos, la oferta, y comparar unos con otros y saber qué encaja mejor con el cliente en función de su contexto y el del banco. Vamos a ver una revolución en banca en los próximos años de manera clara”, expone.

Gobierno, cultura y adopción, los desafíos de abrazar la inteligencia artificial

Aunque la IA trae consigo ingentes oportunidades, también abre retos de distinta índole. Preguntado por este asunto, el CIO contesta: “El mayor retorno que tiene la IA actualmente es tecnológico. Avanza cada vez más rápido y es más accesible, de hecho, cualquiera puede usar ChatGPT incluso para programar; pero el mayor reto lo hemos encontrado en materia de gobierno, cultura y adopción”.

Para subsanar el desafío del gobierno, en Singular Bank han creado un “comité de gobierno de la IA y una política que todos los empleados deben conocer y firmar antes de poder utilizar todas estas herramientas”, explica el CIO. En este comité, de carácter multidisciplinar —está formado por el equipo de Legal Compliance, el DPO (delegado de protección de datos), el equipo de seguridad y el de tecnología y operaciones— y alineado con la regulación vigente —como la IA Act (Reglamento europeo de IA) y el RGPD (Reglamento General de Protección de Datos), entre otros— se mide el riesgo que tiene cada una de las plataformas de IA antes de adoptarlas. Solo después se ponen a disposición de los empleados. Además, agrega, en los casos de uso que han desplegado, como Singularity, realizan un análisis continuo del rendimiento de los modelos para garantizar que éste se ajusta a lo buscado y, si no, se aplican ajustes a nivel tecnológico. 

Para superar el reto cultural y las barreras de adopción, pues “toda esta revolución de la IA ha generado muchos miedos a la pérdida de empleo y a ser sustituido”, el banco ha trabajado en ofrecer amplia formación sobre estas nuevas tecnologías “desde el punto de vista de hacia dónde va el mercado, pero también mirando al pasado, porque si nos hubiéramos negado a la imprenta, el ferrocarril y todas las revoluciones industriales, no estaríamos en el nivel de sofisticación actual; hemos trasladado a los empleados que esto es una revolución a la que hay que sumarse, pues gracias a ella vamos a tener mejores profesionales y un mejor servicio a nuestros clientes”. La clave, añade, ha sido hacer a los empleados “creyentes del cambio, darles formación y acompañarlos”.

El gran cambio de mentalidad con la IA, explica, es que los propios empleados pueden desarrollar sus propias soluciones tecnológicas, sin pedirlas al equipo de tecnología. “Esta es la gran revolución que estamos acometiendo”, sentencia.

El coste, en el punto de mira

Una de las grandes preocupaciones de los líderes de TI a la hora de abrazar la IA es que el coste se dispare y provoque situaciones similares a las vividas con la adopción de cloud en el pasado. “Cuando iniciamos el proyecto con OpenAI, en marzo de 2025, trabajábamos con un modelo de tarifa plana: pagábamos una licencia que cubría tanto el desarrollo de ingeniería con herramientas como Cursor como el uso de ChatGPT. Todo estaba incluido. Actualmente hemos pasado a un modelo de coste por consumo de tokens. Desde la perspectiva de negocio, no nos preocupa esta evolución, ya que la plataforma cubre con creces nuestras necesidades actuales. Además, hemos realizado proyecciones a futuro y no prevemos ningún problema significativo. Incluso en el caso de que se produjera un ligero sobrecoste, los beneficios obtenidos compensarían con creces ese incremento del gasto”, reflexiona Rubén Andrés.

Desde el punto de vista de ingeniería, añade, “el retorno también compensa el sobrecoste, ya que hemos multiplicado la productividad y las capacidades de nuestros desarrolladores”. Sí han observado, afirma el CIO, la necesidad de establecer cuotas y mecanismos de control del consumo, pues en algún caso han detectado que ciertos desarrolladores utilizaban modelos muy avanzados para tareas que no requerían ese nivel de capacidad, lo que generaba un consumo innecesario de tokens. Unas situaciones en las que modelos más sencillos habrían ofrecido el mismo resultado con un coste considerablemente menor.

El gran cambio de mentalidad con la IA, explica Rubén Andrés, es que los propios empleados pueden desarrollar sus propias soluciones tecnológicas, sin pedirlas al equipo de tecnología. “Esta es la gran revolución que estamos acometiendo”

Por todo ello, explica, el banco está aplicando los mismos principios de gestión financiera que ya utilizó con la nube: “Hemos trasladado el uso de FinOps al ámbito de la inteligencia artificial para optimizar el uso de los recursos, controlar los costes y garantizar que cada caso de uso emplee el modelo más adecuado, además de hacer un seguimiento mensual del consumo”.

Impacto en el desarrollo de software

Los desarrolladores de software son algunos de los perfiles profesionales más directamente impactados por el auge de la IA agentiva y generativa. “En el mercado en general muchos programadores ven la IA como una amenaza, pero, en realidad, esto va a hacer que se multiplique el software porque, de hecho, el mundo necesita más. Los bancos ya teníamos mucha más demanda de la que podíamos abordar. Por eso yo no veo que la IA sea un problema para los desarrolladores”.

Dicho esto, el CIO reconoce que el tipo de perfiles técnicos que busca la entidad en la actualidad ha cambiado: “Ahora buscamos perfiles técnicos senior, pues cuanta más experiencia tiene el profesional, mejor adopta la IA; también que tengan baja resistencia al cambio”. En este sentido, en el banco ya trabajan de forma que sus técnicos lideran equipos virtuales formados por los roles [agentes] de project manager, analista funcional, analista orgánico, etc. pero alimentados con el contexto y la arquitectura de la entidad. “Una iniciativa con la que te vuela la cabeza”, sentencia Rubén Andrés.

El ROI del uso de la IA asociado al área de desarrollo de ingeniería es también significativo, según el directivo. “Ahora un programador desarrolla software como si fuera un equipo de 15 desarrolladores, y lo hace a una velocidad nunca vista antes y con una calidad totalmente alineada con la requerida por el banco”.

El área de Tecnología de Singular Bank, cuyo equipo asciende a 41 personas, está abordando “una transformación completa de todos los sistemas legacy con toda esta tecnología”, recalca el CIO. “Es un catalizador del cambio”, añade.

Foco en la soberanía tecnológica

Preguntado por si le preocupa la soberanía tecnológica en el complejo contexto actual, marcado por un escenario geopolítico tensionado, Rubén Andrés es contundente: “Mucho”. Más aún, reconoce, después de ver cómo el Gobierno de Estados Unidos paralizaba recientemente el acceso a los modelos más avanzados de Anthropic (una decisión después revertida). Por ello, la filosofía del CIO es que “todo lo que construyamos permita la continuidad de negocio, es decir, el aumento de capacidades cognitivas es un ‘on top off’ de lo que son los básicos de poder llevar a cabo el asesoramiento y el resto de las tareas que hemos hecho antes de tener estos sistemas”. Además, reconoce, ya están trabajando en “desacoplar la capa agentiva. Esta pertenece a Singular Bank, es nuestra propia plataforma, a la que ponemos por encima una capa de experiencia. Ahora la capa de agentes la tenemos con tecnología de OpenAI (ChatGPT), pero se podría cambiar por cloud o una capa propia”.

Además, desvela a CIO ESPAÑA, Singular Bank está reforzando su estrategia de continuidad de negocio mediante una arquitectura multirregión en AWS que distribuye sus sistemas entre España (en Zaragoza) y el norte de Europa. El objetivo, asegura, es garantizar la resiliencia operativa y la recuperación rápida de los servicios ante incidencias graves, desde fallos técnicos hasta posibles ciberataques o eventos geopolíticos que afecten a una determinada ubicación.

Singular Bank está reforzando su estrategia de continuidad de negocio mediante una arquitectura multirregión en AWS que distribuye sus sistemas entre España (en Zaragoza) y el norte de Europa

Ya desde el punto de vista de la ciberseguridad, en la entidad están empleando la propia IA para crear ‘red teams’ virtuales que se encarguen de analizar continuamente la superficie de ataque y detectar posibles problemas y poder resolverlos antes de que los detecte un tercero. “La ciberseguridad nos preocupa mucho porque, al final, somos una infraestructura crítica y debemos ser responsables y tener control sobre lo que manejamos”.

La ventaja que aporta disponer de capacidades de análisis en ciberseguridad junto a las de un desarrollo vertiginoso facilita que “la defensa pueda abordarse de manera mucho más rápida”, reflexiona el portavoz.

Preguntado por cómo absorbe el banco toda la avalancha normativa que existe y si esta supone un freno a la innovación, el directivo también es claro: “Llevo trabajando en banca 20 años y nunca he visto la regulación como un freno para este sector. Honestamente, creo que este argumento se ha utilizado como excusa, pero la regulación es muy necesaria, garantiza que demos un servicio seguro y confiable”.

En Singular Bank, añade, “hay un equipo muy abierto a las nuevas tecnologías y a analizar la regulación desde un punto de vista más de facilitar el cambio que de bloquearlo”. “Si se adopta con sentido común y agilidad y todos los equipos del banco trabajan en pro del negocio y de la innovación esta no es un freno”.

Aumentar la escalabilidad del banco, el eje de futuro

En un futuro próximo, el equipo de Tecnología y Operaciones de Singular Bank, con Rubén Andrés al frente, proseguirá la transformación y modernización en la que está inmerso el banco. “Estamos renovando todos los sistemas legacy a través de tecnologías con IA y context engineering y, por otro lado, continuaremos trabajando la parte de agentes. Ya hemos desarrollado algunos que reemplazan o capacitan a las áreas de operaciones para poder hacer conciliaciones bancarias cada cinco minutos, mientras que antes las hacíamos cada día; esto nos permitirá aumentar la escalabilidad del banco, que es nuestro objetivo de cara a los próximos años. Y, finalmente, seguiremos apostando fuerte por las arquitecturas agentivas para poder generar experiencias de cliente mucho más naturales a través de conversaciones a través de los canales digitales”.

Respecto a la evolución futura del rol del CIO en general, el ejecutivo es plenamente consciente de la transformación que esta función ha tenido en los últimos años, ahora “más pegado al negocio”. “En la actualidad, se ha amplificado más el rol del CIO, que ya no está ligado a la continuidad, la resiliencia o la seguridad, sino es un rol de agente del cambio, impulsor de la adopción de nuevas tecnologías, formador, visionario de nuevos modelos de negocio… En definitiva, un rol, paradójicamente en esta era de la IA, cada vez más humano”.