Here in this high-tech era of 2026, keeping important info backed up and synced should be effortless and something that just happens on its own, automatically, without any actual thought or ongoing human effort.

In many areas of our digital life, that mercifully does Just Work™ in exactly that way. Fire up an email in most modern mail services, and you can stop at any point and find your in-progress draft in that same app on any other device. The same applies to any file you’re finessing within Google Drive or other cloud storage services or document you’re dawdling over in Docs.

One area where seamless syncing somehow still doesn’t occur, though, is in the domain of downloaded documents on Android. If someone sends you a PDF or a Word file and you save it to your phone, that file exists in an archaic-seeming silo — only locally, on that one gadget. And that, of course, means (a) you can’t access it from any other device, and (b) if you misplace your phone or move into a new one at some point along the way, the file will be left behind in time and entirely unavailable.

Well, take a moment to join me in celebration: Amidst all the Gemini gobbledegook that no one asked for (and that often falls somewhere between “pointless” and “actively counterproductive”), Google’s giving us a major upgrade to Android’s backup capabilities right now. It’s a simple-seeming switch buried in your system settings, and it’s up to you to find and activate it.

Once you do, though, those once-orphaned documents on your Android device’s local storage will be perpetually synced and protected, automatically, without any ongoing thought or effort.

All you’ve gotta do is find and flip that one new switch.

[Don’t let yourself miss an ounce of Android Intelligence. Join my free weekly Android Intelligence newsletter and get one new thing to try in your inbox every Friday!]

The Android backup lowdown

So, for a quick bit of pertinent context on this: Android’s backup systems have actually come a really long way over the years.

‘Twas a time, y’see, when little to nothing about you would sync and carry over automatically from one Android device to another. Years ago — back in the ancient-seeming prehistoric era of the early 2010s — Android enthusiasts in the know would rely on community-created third-party apps for everything from remembering and resyncing downloaded apps to restoring data from within those apps and onward. And reconfiguring your system preferences would be a whole time-consuming song and dance every single time you reset a device or moved into a new one, as little to nothing would automatically carry over.

Most of that stuff is now effortless and automatic. And, thanks to apps like Google Messages, Calendar, Drive, and Docs, many other areas of important data are also synced on their own at the app level — outside of any system mechanisms.

Locally stored files, however, have remained an awkward omission. To this day, anything you download on any Android device exists only on that one device and isn’t synced or backed up anywhere. The only way that happens is — in a blast-from-the-past twist — if you go out of your way to find and set up a third-party app to handle the heavy lifting.

That brings us to today. Right now, as we speak, Google’s in the midst of sending out a quiet under-the-hood update that (brace yourself…) adds in the option to automatically sync and back up any documents on your device as a native part of Android’s backup setup.

See?

The option is on its way to all devices running 2018’s Android 9 release and higher. (If you’re still using a phone with an Android version older than that, you’re now a whopping eight years out of date, and you have much bigger problems.)

Once the added option is present and available for you, you’re literally lookin’ at 10 seconds to find and activate it.

Lemme show ya how.

Android’s document backup addition

I promise: This couldn’t be much simpler.

No matter what kind of Android device is in front of you, just head into your system settings and open the section called “Accounts and backup,” “Back up or copy data,” or something along those same lines. (The exact wording can vary based on who made your device and when it was released or last updated.)

Either tap the line labeled “Google Backup” or look for an option to “Back up data” via Google Drive. You should then either see a series of options for different areas of available backup right then and there — or, depending on your device, you might have to tap a line labeled “Other device data” (or something similar) to find the full list of possibilities.

However you get there, once you’re lookin’ at that list, you’ll see a newly added line for “Documents” if this latest under-the-hood update has reached you.

And from there, all that’s left is to tap it and enable the switch to include that in your automated backups from that moment forward.

If you aren’t seeing the option yet, don’t panic. Google always sends these under-the-hood updates out bit by bit over time, so the change probably just hasn’t reached your device quite yet. As long as you’re running Android 9 or higher, it’ll get there. Set yourself a reminder to check back once a week or so. Odds are, you’ll see it pretty soon.

Notably, all documents synced in this way are always encrypted for security, and they’re kept in your personal (or, depending on the nature of your account, perhaps company-connected) Google Drive storage. That does mean they’ll count against your overall Google storage total, so keep an eye on your Drive storage total to make sure you’re in solid shape and look to the Google One storage hub if you ever want some simple suggestions for freeing up space.

Speaking of other Google services: If you ever want to keep other types of locally stored non-document files from an Android device synced and available elsewhere, you can easily rely on Google Photos for syncing screenshots and other images — after enabling sync in general, be sure to look in the app’s “Collections” areas to find the “On this device” folder and then flip the toggle to “Backup all device folders” (or get more nuanced and open specific individual on-device folders if you want to sync some but not all of those areas) — and you can still turn to those aforementioned third-party apps for broader syncing of anything else imaginable.

But with documents now being handled automatically and natively, that’s one big worry now out of your hair. Just note that the onus will fall on you to find and flip the switch and actively opt in to the feature on each and every Android device you’re using.

Take 10 seconds to do that, though, and you’ll have one less void in your Android data arena. And you don’t need Gemini to tell you that that can only be a good thing.

Get practical Android knowledge in your inbox every Friday with my free Android Intelligence newsletter — one new thing to try each week, straight from me to you.

Cloudflare recently beat Q1 2026 earnings. Revenue up 34% year over year. EPS ahead of consensus. Full-year guidance raised. Then, in the same breath, they announced 1,100 layoffs, 20% of the company. CEO Matthew Prince’s explanation: “The way we work at Cloudflare has fundamentally changed.”

Block did the same thing. Beat guidance, raised outlook, cut 4,000+ jobs. Both framed it as architecting for the AI era.

This is not a contradiction. This is the new math boards are running. And if you’re a CIO who hasn’t started running it yourself, you’re behind.

The benchmark has moved

AI-native companies have quietly reset what “efficient” means for a technology organization. Midjourney generates over $500M in revenue with roughly 160 employees, over $3M per head. Anthropic hit a $14B annualized run rate in early 2026 with fewer than 3,000 employees. Across the top AI-native startups, the average revenue per employee is $3.48M, nearly twelve times the traditional SaaS benchmark of $300K.

Boards aren’t comparing you to your 2019 self anymore. They’re comparing you to Anthropic.

This is the pressure Cloudflare and Block are responding to. They’re not cutting people because the business is struggling. They’re cutting because investors have internalized a new denominator. Headcount is no longer a proxy for capacity; it’s a liability on the efficiency ratio.

For CIOs, this creates a hiring problem that looks nothing like the cloud or mobile talent gaps of the past decade. Those gaps were about volume: hire 100 cloud engineers, absorb the cost, build the capability… This one is about density; you’re not looking for 100 people. You’re looking for 10 who can deliver what 100 couldn’t, and justify $1M or more in value per seat.

Finding bodies to fill seats has never been easier. Finding people who operate at that level of leverage is a different problem entirely.

‘Acqui-hires’ are a shortcut with a hidden cost

Companies have figured out that recruiting AI-native talent one by one is too slow and that it’s faster to buy a team. Google’s acquisition of the Windsurf founders, Meta bringing in the Scale AI team, Accenture’s string of AI-focused acquisitions: these are acqui-hires dressed up as M&A. The premium on experienced AI talent is high enough, and the urgency real enough, that organizations are skipping traditional hiring loops entirely and buying their way in.

I’ve been on the other side of this. My company, MadKudu, was acquired by HG Insights specifically to bring AI-native capability into an established enterprise business. HG needed change agents who had already figured out how to build and ship in this new era, not just people who’d read about it. That’s the thesis behind most of these deals.

But there’s a cost that doesn’t show up in the acquisition price.

AI-native teams are fast because they operate with a different set of defaults: full access to tools, minimal governance layers, the ability to experiment and ship without a six-week approval cycle. That operating model is not a perk; it’s the fundamental mechanism. It’s why a team of 10 can do what an enterprise team of 100 can’t.

When you acqui-hire that team and then slot them into your existing approval processes, you’ve bought the people and killed the engine. The change agents you paid for become change-frustrated. The attrition that follows is expensive and predictable.

The harder realization: acquiring an AI-native team means accepting how they work. That requires deliberately carving out space for them to operate differently, not just tolerating it but institutionalizing it. The acquisition is an organizational change program, not just a hiring event.

The CIO’s real problem

The governance stack most enterprise organizations run was designed for a headcount world. Every tool vetting cycle, every vendor review, every security approval was calibrated assuming you were managing a large team where consistency and control were the primary objectives.

That calculus breaks when your goal is talent density. The same approval processes that protect against data leaks are now the reason your best people can’t do their best work. When it takes six weeks to approve a tool that your competitor’s team is already shipping with, you’ve traded velocity for the perception of safety.

The practical fix is structured experimentation: clear guardrails, defined boundaries, but explicit permission to try tools before deciding whether to roll them out broadly. Gating everything prevents you from ever discovering what 10x productivity looks like.

The skills inventory question is also more nuanced than it sounds. Job titles won’t tell you where the leverage is. You need to map the actual tasks within each function and assess which can be automated or augmented with AI. That’s where you find the people who, with the right tools, become your $1M/employee talent, not because you hired differently, but because you enabled better.

This is also where the build-versus-buy question gets genuinely tricky. As AI reshapes how products are built and delivered, your internal operating model — how you work, how fast you ship, how you use data — is becoming core IP. Outsourcing delivery means outsourcing the part of the organization where your competitive advantage is now being built.

Closing the gap without slowing down

The AI talent wars are not primarily a recruiting problem. They’re a rethinking of what organizations are supposed to look like.

Boards have a new benchmark. Cloudflare, Block, Amazon, Meta and others have already started restructuring to meet it, publicly, painfully, even while beating their numbers. The question for CIOs isn’t whether this pressure arrives; it’s whether you’re ahead of it or behind it when it does.

The organizations that navigate this well won’t win by outbidding competitors for a handful of elite engineers. They’ll win by designing operating systems that amplify the leverage of the talent they do have, by enabling their best people rather than constraining them, and by treating AI fluency as a core organizational capability rather than a niche specialization.

Talent density is the new headcount model. The sooner your governance, your tooling and your board conversations reflect that, the better positioned you’ll be when the next efficiency report lands.

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

For CIOs, learning from the startup ecosystem has never been more critical.

As pressure mounts to transform business operations with AI and agentic systems, IT leaders should be looking to those on the AI vanguard for insights into the strategic and technical decisions necessary to launch, grow, and thrive in today’s AI-disrupted business environment.

So why not immerse yourself in Silicon Valley’s most famous firehose of hyper-accelerated fail-fast and dream-big culture by registering for TechCrunch Disrupt 2026?

Three packed days of 200-plus sessions across six stages will spark new ideas for reshaping your AI strategy, provide fresh perspectives on the architectural, workflow, and resource decisions involved in moving AI from pilots to scale, and give you a sneak peek of business disruptions to come.

Get 10% off your TechCrunch Disrupt pass with the exclusive code CIO10. 

This year’s TechCrunch Disrupt, held Oct. 13-15 at San Francisco’s Moscone West, will feature big-picture conversations on what’s next in AI; discussions on how AI agents are rewriting SaaS, enterprise workflows, software pricing, and security; and demonstrations of AI’s future across robotics, manufacturing, defense, and industrial operations; and more.

Over 10,000 attendees will hear from 250-plus startup founders, technology executives, and enterprise IT leaders about how the future of programming is being rewritten, what enterprise AI security requires, how startups are orchestrating workloads across models while managing cost and reliability at scale, why creating a safety culture is essential for AI deployment, and how startups are deciding what work humans should own versus what should be delegated to AI as they work to build hybrid teams without losing speed, accountability, or culture.

And of course, the rising tide of enterprise-focused startups will be there seeking to bring agentic systems to your business workflows, as well as vendors familiar to your enterprise IT portfolios, such as AWS, Google, and Databricks, and enterprise IT colleagues creating mutually beneficial partnerships with the startup community, such as American Express.

That’s not to mention TechCrunch Disrupt’s signature Startup Battlefield, in which 200 standout companies showcase their innovations to compete for a $100K equity-free prize. The battlefield will give CIOs a rapid-fire, broad view of what’s possible — and a possible early look at the next big enterprise player. After all, Dropbox, Trello, and Cloudflare, among others, roamed that same battlefield before the world knew their names.

And with M&A now an early-stage startup strategy for many from day one, TechCrunch Disrupt’s exhibition floor provides IT leaders not just an opportunity to discuss the nuts and bolts of innovation architecture or how an upstart product can enhance your workflows, but a chance to find your next innovation partner, or more.

Leading-edge startups are figuring out how to make AI work at scale. Shouldn’t you be?

Don’t miss your chance to experience TechCrunch Disrupt 2026. Book your pass today and use the exclusive code CIO10 to save 10% before prices increase.

For CIOs, learning from the startup ecosystem has never been more critical.

As pressure mounts to transform business operations with AI and agentic systems, IT leaders should be looking to those on the AI vanguard for insights into the strategic and technical decisions necessary to launch, grow, and thrive in today’s AI-disrupted business environment.

So why not immerse yourself in Silicon Valley’s most famous firehose of hyper-accelerated fail-fast and dream-big culture by registering for TechCrunch Disrupt 2026?

Three packed days of 200-plus sessions across six stages will spark new ideas for reshaping your AI strategy, provide fresh perspectives on the architectural, workflow, and resource decisions involved in moving AI from pilots to scale, and give you a sneak peek of business disruptions to come.

Get 10% off your TechCrunch Disrupt pass with the exclusive code CIO10. 

This year’s TechCrunch Disrupt, held Oct. 13-15 at San Francisco’s Moscone West, will feature big-picture conversations on what’s next in AI; discussions on how AI agents are rewriting SaaS, enterprise workflows, software pricing, and security; and demonstrations of AI’s future across robotics, manufacturing, defense, and industrial operations; and more.

Over 10,000 attendees will hear from 250-plus startup founders, technology executives, and enterprise IT leaders about how the future of programming is being rewritten, what enterprise AI security requires, how startups are orchestrating workloads across models while managing cost and reliability at scale, why creating a safety culture is essential for AI deployment, and how startups are deciding what work humans should own versus what should be delegated to AI as they work to build hybrid teams without losing speed, accountability, or culture.

And of course, the rising tide of enterprise-focused startups will be there seeking to bring agentic systems to your business workflows, as well as vendors familiar to your enterprise IT portfolios, such as AWS, Google, and Databricks, and enterprise IT colleagues creating mutually beneficial partnerships with the startup community, such as American Express.

That’s not to mention TechCrunch Disrupt’s signature Startup Battlefield, in which 200 standout companies showcase their innovations to compete for a $100K equity-free prize. The battlefield will give CIOs a rapid-fire, broad view of what’s possible — and a possible early look at the next big enterprise player. After all, Dropbox, Trello, and Cloudflare, among others, roamed that same battlefield before the world knew their names.

And with M&A now an early-stage startup strategy for many from day one, TechCrunch Disrupt’s exhibition floor provides IT leaders not just an opportunity to discuss the nuts and bolts of innovation architecture or how an upstart product can enhance your workflows, but a chance to find your next innovation partner, or more.

Leading-edge startups are figuring out how to make AI work at scale. Shouldn’t you be?

Don’t miss your chance to experience TechCrunch Disrupt 2026. Book your pass today and use the exclusive code CIO10 to save 10% before prices increase.

Cloudflare recently beat Q1 2026 earnings. Revenue up 34% year over year. EPS ahead of consensus. Full-year guidance raised. Then, in the same breath, they announced 1,100 layoffs, 20% of the company. CEO Matthew Prince’s explanation: “The way we work at Cloudflare has fundamentally changed.”

Block did the same thing. Beat guidance, raised outlook, cut 4,000+ jobs. Both framed it as architecting for the AI era.

This is not a contradiction. This is the new math boards are running. And if you’re a CIO who hasn’t started running it yourself, you’re behind.

The benchmark has moved

AI-native companies have quietly reset what “efficient” means for a technology organization. Midjourney generates over $500M in revenue with roughly 160 employees, over $3M per head. Anthropic hit a $14B annualized run rate in early 2026 with fewer than 3,000 employees. Across the top AI-native startups, the average revenue per employee is $3.48M, nearly twelve times the traditional SaaS benchmark of $300K.

Boards aren’t comparing you to your 2019 self anymore. They’re comparing you to Anthropic.

This is the pressure Cloudflare and Block are responding to. They’re not cutting people because the business is struggling. They’re cutting because investors have internalized a new denominator. Headcount is no longer a proxy for capacity; it’s a liability on the efficiency ratio.

For CIOs, this creates a hiring problem that looks nothing like the cloud or mobile talent gaps of the past decade. Those gaps were about volume: hire 100 cloud engineers, absorb the cost, build the capability… This one is about density; you’re not looking for 100 people. You’re looking for 10 who can deliver what 100 couldn’t, and justify $1M or more in value per seat.

Finding bodies to fill seats has never been easier. Finding people who operate at that level of leverage is a different problem entirely.

‘Acqui-hires’ are a shortcut with a hidden cost

Companies have figured out that recruiting AI-native talent one by one is too slow and that it’s faster to buy a team. Google’s acquisition of the Windsurf founders, Meta bringing in the Scale AI team, Accenture’s string of AI-focused acquisitions: these are acqui-hires dressed up as M&A. The premium on experienced AI talent is high enough, and the urgency real enough, that organizations are skipping traditional hiring loops entirely and buying their way in.

I’ve been on the other side of this. My company, MadKudu, was acquired by HG Insights specifically to bring AI-native capability into an established enterprise business. HG needed change agents who had already figured out how to build and ship in this new era, not just people who’d read about it. That’s the thesis behind most of these deals.

But there’s a cost that doesn’t show up in the acquisition price.

AI-native teams are fast because they operate with a different set of defaults: full access to tools, minimal governance layers, the ability to experiment and ship without a six-week approval cycle. That operating model is not a perk; it’s the fundamental mechanism. It’s why a team of 10 can do what an enterprise team of 100 can’t.

When you acqui-hire that team and then slot them into your existing approval processes, you’ve bought the people and killed the engine. The change agents you paid for become change-frustrated. The attrition that follows is expensive and predictable.

The harder realization: acquiring an AI-native team means accepting how they work. That requires deliberately carving out space for them to operate differently, not just tolerating it but institutionalizing it. The acquisition is an organizational change program, not just a hiring event.

The CIO’s real problem

The governance stack most enterprise organizations run was designed for a headcount world. Every tool vetting cycle, every vendor review, every security approval was calibrated assuming you were managing a large team where consistency and control were the primary objectives.

That calculus breaks when your goal is talent density. The same approval processes that protect against data leaks are now the reason your best people can’t do their best work. When it takes six weeks to approve a tool that your competitor’s team is already shipping with, you’ve traded velocity for the perception of safety.

The practical fix is structured experimentation: clear guardrails, defined boundaries, but explicit permission to try tools before deciding whether to roll them out broadly. Gating everything prevents you from ever discovering what 10x productivity looks like.

The skills inventory question is also more nuanced than it sounds. Job titles won’t tell you where the leverage is. You need to map the actual tasks within each function and assess which can be automated or augmented with AI. That’s where you find the people who, with the right tools, become your $1M/employee talent, not because you hired differently, but because you enabled better.

This is also where the build-versus-buy question gets genuinely tricky. As AI reshapes how products are built and delivered, your internal operating model — how you work, how fast you ship, how you use data — is becoming core IP. Outsourcing delivery means outsourcing the part of the organization where your competitive advantage is now being built.

Closing the gap without slowing down

The AI talent wars are not primarily a recruiting problem. They’re a rethinking of what organizations are supposed to look like.

Boards have a new benchmark. Cloudflare, Block, Amazon, Meta and others have already started restructuring to meet it, publicly, painfully, even while beating their numbers. The question for CIOs isn’t whether this pressure arrives; it’s whether you’re ahead of it or behind it when it does.

The organizations that navigate this well won’t win by outbidding competitors for a handful of elite engineers. They’ll win by designing operating systems that amplify the leverage of the talent they do have, by enabling their best people rather than constraining them, and by treating AI fluency as a core organizational capability rather than a niche specialization.

Talent density is the new headcount model. The sooner your governance, your tooling and your board conversations reflect that, the better positioned you’ll be when the next efficiency report lands.

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

AI agents can turn a clear description into working software, the engineer’s judgement is what makes the difference: deciding what to build, catching the tradeoff the agent didn’t know to weigh, and owning the call on whether the result is right.

That judgement has always been the hard part of engineering. It just used to be bundled into the act of writing code, where a skilled engineer did it while typing. As agents take on more of the typing, that judgement separates out and becomes the clear center of the role. Leaders who adapt early will get their metrics, their talent pipelines, and their delivery models working with this shift rather than against it.

Judgement is defining, constraining, and deciding

Judgement is all about defining the problem precisely enough that an agent builds the right thing. It’s setting the constraints the agent won’t infer on its own. It’s spotting the tradeoff buried three layers down that only shows up if you understand the system. And it’s looking at a finished implementation and knowing whether it’s genuinely good enough to ship.

This is the harder part of the job and the real driver of quality. It was easy to underrate when it lived inside day-to-day coding. Now it’s what separates a strong team from an average one.

The shift changes where time, growth, and metrics go

If the high-value activity is intent, review, and judgement rather than raw output, a few assumptions are worth revisiting.

Where engineers spend their time. Less of the day goes to producing boilerplate and mechanical implementation, and more goes to the reasoning that used to get squeezed to the edges: framing the problem and owning the judgement calls that determine quality.

How teams grow their people. Defining problems well, spotting risk, and critically evaluating work you didn’t write yourself have always been senior skills. When agents handle more of the mechanical work, those skills become learnable earlier. That puts the emphasis on leaders to teach the reasoning: why a choice gets made and how to weigh the tradeoffs that come with it.

What you measure. Lines shipped, tickets closed, and velocity charts all measured throughput of the old scarce resource. They say very little about the new one. The teams that adapt will start measuring the quality of intent going in and the reliability of judgement coming out, because that’s where the results now live.

Reinvest the time you get back

The tempting response is to treat the freed-up capacity as pure speed: same work, same tooling, just faster. That captures the easy win and misses the real one. If engineers spend their reclaimed time reviewing a rising volume of agent output with no better context than before, review quietly becomes the new constraint, and you’ve moved the problem rather than solved it.

The organizations that get ahead will invest the reclaimed capacity into the judgement layer: creating stronger specs and acceptance criteria before work starts, building review practices that test agent output against intent, and capturing the reasoning behind decisions where the next person can find it, so it doesn’t have to be reconstructed every time. That’s how the shift becomes an advantage for your team.

The through-line for leaders

The engineering job is moving up a level, from executing the work to directing and validating it. That’s a more strategic role, and it rewards clarity of thought over speed of output. Leaders who see the shift early can help their engineers grow into the work that’s now most valuable.

See how leading engineering organizations are operationalizing this shift at jira.dev.

Here in this high-tech era of 2026, keeping important info backed up and synced should be effortless and something that just happens on its own, automatically, without any actual thought or ongoing human effort.

In many areas of our digital life, that mercifully does Just Work™ in exactly that way. Fire up an email in most modern mail services, and you can stop at any point and find your in-progress draft in that same app on any other device. The same applies to any file you’re finessing within Google Drive or other cloud storage services or document you’re dawdling over in Docs.

One area where seamless syncing somehow still doesn’t occur, though, is in the domain of downloaded documents on Android. If someone sends you a PDF or a Word file and you save it to your phone, that file exists in an archaic-seeming silo — only locally, on that one gadget. And that, of course, means (a) you can’t access it from any other device, and (b) if you misplace your phone or move into a new one at some point along the way, the file will be left behind in time and entirely unavailable.

Well, take a moment to join me in celebration: Amidst all the Gemini gobbledegook that no one asked for (and that often falls somewhere between “pointless” and “actively counterproductive”), Google’s giving us a major upgrade to Android’s backup capabilities right now. It’s a simple-seeming switch buried in your system settings, and it’s up to you to find and activate it.

Once you do, though, those once-orphaned documents on your Android device’s local storage will be perpetually synced and protected, automatically, without any ongoing thought or effort.

All you’ve gotta do is find and flip that one new switch.

[Don’t let yourself miss an ounce of Android Intelligence. Join my free weekly Android Intelligence newsletter and get one new thing to try in your inbox every Friday!]

The Android backup lowdown

So, for a quick bit of pertinent context on this: Android’s backup systems have actually come a really long way over the years.

‘Twas a time, y’see, when little to nothing about you would sync and carry over automatically from one Android device to another. Years ago — back in the ancient-seeming prehistoric era of the early 2010s — Android enthusiasts in the know would rely on community-created third-party apps for everything from remembering and resyncing downloaded apps to restoring data from within those apps and onward. And reconfiguring your system preferences would be a whole time-consuming song and dance every single time you reset a device or moved into a new one, as little to nothing would automatically carry over.

Most of that stuff is now effortless and automatic. And, thanks to apps like Google Messages, Calendar, Drive, and Docs, many other areas of important data are also synced on their own at the app level — outside of any system mechanisms.

Locally stored files, however, have remained an awkward omission. To this day, anything you download on any Android device exists only on that one device and isn’t synced or backed up anywhere. The only way that happens is — in a blast-from-the-past twist — if you go out of your way to find and set up a third-party app to handle the heavy lifting.

That brings us to today. Right now, as we speak, Google’s in the midst of sending out a quiet under-the-hood update that (brace yourself…) adds in the option to automatically sync and back up any documents on your device as a native part of Android’s backup setup.

See?

The option is on its way to all devices running 2018’s Android 9 release and higher. (If you’re still using a phone with an Android version older than that, you’re now a whopping eight years out of date, and you have much bigger problems.)

Once the added option is present and available for you, you’re literally lookin’ at 10 seconds to find and activate it.

Lemme show ya how.

Android’s document backup addition

I promise: This couldn’t be much simpler.

No matter what kind of Android device is in front of you, just head into your system settings and open the section called “Accounts and backup,” “Back up or copy data,” or something along those same lines. (The exact wording can vary based on who made your device and when it was released or last updated.)

Either tap the line labeled “Google Backup” or look for an option to “Back up data” via Google Drive. You should then either see a series of options for different areas of available backup right then and there — or, depending on your device, you might have to tap a line labeled “Other device data” (or something similar) to find the full list of possibilities.

However you get there, once you’re lookin’ at that list, you’ll see a newly added line for “Documents” if this latest under-the-hood update has reached you.

And from there, all that’s left is to tap it and enable the switch to include that in your automated backups from that moment forward.

If you aren’t seeing the option yet, don’t panic. Google always sends these under-the-hood updates out bit by bit over time, so the change probably just hasn’t reached your device quite yet. As long as you’re running Android 9 or higher, it’ll get there. Set yourself a reminder to check back once a week or so. Odds are, you’ll see it pretty soon.

Notably, all documents synced in this way are always encrypted for security, and they’re kept in your personal (or, depending on the nature of your account, perhaps company-connected) Google Drive storage. That does mean they’ll count against your overall Google storage total, so keep an eye on your Drive storage total to make sure you’re in solid shape and look to the Google One storage hub if you ever want some simple suggestions for freeing up space.

Speaking of other Google services: If you ever want to keep other types of locally stored non-document files from an Android device synced and available elsewhere, you can easily rely on Google Photos for syncing screenshots and other images — after enabling sync in general, be sure to look in the app’s “Collections” areas to find the “On this device” folder and then flip the toggle to “Backup all device folders” (or get more nuanced and open specific individual on-device folders if you want to sync some but not all of those areas) — and you can still turn to those aforementioned third-party apps for broader syncing of anything else imaginable.

But with documents now being handled automatically and natively, that’s one big worry now out of your hair. Just note that the onus will fall on you to find and flip the switch and actively opt in to the feature on each and every Android device you’re using.

Take 10 seconds to do that, though, and you’ll have one less void in your Android data arena. And you don’t need Gemini to tell you that that can only be a good thing.

Get practical Android knowledge in your inbox every Friday with my free Android Intelligence newsletter — one new thing to try each week, straight from me to you.

A client called me last week with a problem I have been hearing about more often lately. They had made significant reserved instance commitments with a major cloud provider, overbuying for what they thought would be heavy AI training workloads. Now they were sitting on thousands of dollars in idle capacity every month. Their plan was simple: resell it to someone else. Except they couldn’t.

I have been doing cloud consulting for a long time, and this situation once had a straightforward solution. You went to the marketplace, listed your unused reservations, and found a buyer. The process was a bit clunky, but it worked. These days, the answer is far more complicated, and my client learned this the hard way.

AI has made this problem increasingly common. Companies initially committed to compute capacity based on ambitious training plans. Prototype projects were expected to scale, and inference workloads were projected to grow substantially. Then reality hit. Some projects did not materialize. Some models trained faster than expected. Some inference patterns were lighter than anticipated.

Many organizations now hold reserved capacity they can’t use, discard, or share without a complex, increasingly restricted process. This reality is something every company with significant cloud spend needs to clearly understand.

The history of cloud resale

There was once a functioning resale market for cloud reserved instances. AWS, for example, maintained a Reserved Instances Marketplace where companies that had purchased reserved capacity could sell those reservations to other AWS customers. This was a legitimate, AWS-sanctioned process. Companies would register as sellers, list their unused reservations with pricing and terms, and if a buyer appeared, the marketplace would facilitate the transaction.

The resale market was useful for companies that had overestimated their needs or whose business changes reduced their cloud consumption. Instead of simply absorbing the cost of unused commitments, they could recoup some of that investment by selling to other organizations with unmet demand. It created a secondary market that added liquidity to what was otherwise a rigid financial arrangement.

My client had some experience with this resale market a few years ago and assumed they could use it again. They were unpleasantly surprised to learn that the rules had changed.

AWS changes the rules

In January 2024, AWS implemented a significant policy change that effectively shut down the resale of EC2 Reserved Instances on its platform. AWS stopped allowing companies to resell their unused reserved capacity through the Reserved Instance Marketplace or any other official channel. If you have a reserved instance commitment with AWS, you are essentially stuck with it unless you can use it yourself or modify your reservation.

This change had a real impact on companies that had relied on resale as part of their cloud financial management strategy. It reduced flexibility and increased the risk of long-term reserved commitments. When I explained this AWS policy change to my client’s representatives, I could hear the frustration in their voices. They had made their commitment in good faith, carefully modeled their expected AI workloads, and now faced the reality that there was no easy exit.

The reasoning behind this change is not entirely clear, but AWS likely viewed capacity resales as something that complicated their billing and commitment models without providing enough benefit to the overall ecosystem. Regardless of the company’s reasons, the primary resale path for the largest cloud provider has been effectively closed.

What options still exist?

What can companies do now when they find themselves with reserved capacity they no longer need? The first possibility is to work directly with the cloud provider to modify or exchange the reservation if it is convertible. Some reservation types allow modifications, such as changing the instance type, region, or tenancy. This will not eliminate the commitment, but it may help companies better align their reservations with actual workload needs.

The second option is to use third-party brokers and marketplaces that operate independently of the cloud providers. Although AWS has shut down its official resale channel, brokers and marketplaces still facilitate resale arrangements for other cloud providers and for some AWS scenarios. These arrangements can be more complex and carry more risk, but they remain a possibility for companies determined to move unused capacity.

The third alternative is to optimize usage. Companies can invest in better utilization monitoring, workload placement, and automation to ensure that reserved capacity is used as efficiently as possible. This does not recover the money already spent, but it reduces future waste.

My client explored all three alternatives and found that each had significant limitations. Modifications were possible, but only within a narrow range. Third-party brokers were interested, but the process was opaque and uncertain. Optimization helped, but it could not eliminate the fundamental overcommitment they had already made.

The broader implications

Cloud commitments are more rigid than many enterprises initially realize because they lack a liquid market and because providers control modifications, transfers, or cancellations. Right now, I see this pattern most often in the AI space. Companies commit to massive amounts of compute for training and inference based on projections that rarely reflect the actual workloads. Then they are surprised to find themselves locked into payments. The AI boom has led to significant overcommitment because enterprises remain unaware that the resale mechanisms that once existed have been largely shut down.

This is why cloud financial management has become such an important discipline. Companies need to be far more thoughtful about how they commit to cloud resources, how they model their future consumption, and how they build flexibility into their cloud strategies. The days of assuming you can always resell your way out of an overcommitment are effectively over, at least with AWS.

For Azure and Google Cloud, the resale landscape is slightly different, but the same general principles apply. These providers have their own capacity transfer policies and, like AWS, those policies can change at any time. Companies should understand their options before making large, committed purchases and build contingency plans in case their actual usage diverges from their projections—or if resale policies change.

The bottom line is that reselling unused reserved cloud instances is far more complicated than it sounds. The market is not as open as it once was, the options are limited, and the providers themselves hold most of the cards. My client got burned, and I doubt they will be the only one. Companies that want to optimize their cloud spending should focus on accurate forecasting, thoughtful commitment sizing, and ongoing optimization rather than relying on resale as a safety valve. That approach worked at one point, but those days are largely gone.

As the CSO grows in prominence, security leaders are increasingly earning a seat at the executive table, reporting directly to the CEO with the expectation to help drive business strategy and ensure organizational success.

Reporting to the CEO unlocks greater access and influence for security leaders, and while CSOs who report to their organization’s CIO still have clout, it’s a very different experience picking up the phone to speak directly with the CEO as a strategic partner.

Regardless of reporting structure, CSOs must clearly understand what they are being tasked to solve. That might sound simple, but making the leap to being a CEO’s direct report requires a new perspective, a different set of skills, and a business-level focus on metrics to do so.

We asked several current CSOs, CEOs, and IT staffing experts for advice on how security executives can best navigate a direct reporting relationship with their CEO. Offering insights below are George Gerchow, CSO at Bedrock Data and member of the IANS faculty; Matt Chiodi, CSO of Cerby; Chris Schueler, CEO at Cyderes; and Greg Fuller, vice president of the Technology Skills Suite at Skillsoft.

1. Understand how the CEO views your role

Most CEOs expect that, when you report directly to them, you fully own your functional area. Whether it’s cybersecurity, operations, or finance, they look to you as the expert in that domain. The CEO may have opinions, but ultimately, you are expected to lead and provide direction.

CEOs expect their CSO to be a true strategic partner, not just a risk reporter — connecting cybersecurity to revenue protection, regulatory compliance, customer trust, and operational resilience. In turn, CSOs should expect CEOs to treat governance as a strategic enabler, not a bureaucratic necessity.

2. Power up on skills vital to your organization at an executive level

On the technology side, AI and machine learning, cloud security, incident response, zero trust architecture, and governance, risk, and compliance (GRC) are the areas where threats evolve fastest and strategic leadership has the greatest impact. 

Equally important are “power skills”: communication, critical thinking, adaptability, and emotional intelligence. The ability to translate complex risk into business terms is what separates a strong CSO from a purely technical one. Skills, not titles, define effectiveness in the eyes of a CEO.

3. Take advantage of your direct access

Direct access to the CEO will enable you to influence strategy, shape resilience planning, and ensure cybersecurity is treated as a business imperative rather than a cost center. That authority is strongest when the CEO understands cybersecurity as a strategic lever, not just a technical function. 

While a direct reporting relationship gives you access to the CEO, it also comes with the responsibility to operate at that level. You need to provide clear, executive-level visibility into your cybersecurity program.

4. Brush up on business translation

A CSO who leads with business alignment will always carry more influence when they can translate risk into business language rather than technical jargon. Building programs that must survive an IPO, a FedRAMP audit, and real customer scrutiny forces you to tie security to revenue and trust.

The most valuable skill is translation — defining technical risk in terms of executive action and business impact that a CEO and a board can act on. You must build trust through transparency. These are the human skills that complement technology, creating a collaborative human-AI dynamic where leaders make faster, better-informed decisions. 

5. Treat conversations as risk assessment opportunities

Highly effective security leaders treat every business conversation as a risk conversation in disguise. That mindset is what largely separates a great CSO from a great technologist. Earn the CEO’s trust by speaking business first, security second. Translate every risk into revenue, reputation, or regulatory exposure.

Remember, a good CEO wants a translator, not an alarm system. They expect no surprises, a clear read on the risks that matter, and a security leader who helps the business move faster rather than slowing it down.

6. Define what a successful relationship should look like and put it in writing

Regardless of the reporting relationship, start by defining the end goal and putting it in writing. It will evolve over time, but having that initial clarity is critical. This is especially important when you’re new in a role and aiming to make your first 60, 90, or 120 days, and your first year, successful. In such cases, it’s essential to align early.

Do that collaboratively, and document it.

7. Prioritize trust and candor

The CEO needs to trust that the CSO isn’t sandbagging, and the CSO needs enough psychological safety to deliver bad news fast. When those conditions exist, security becomes a strategic asset — not a cost center.

To that end, focus on clear communication above all, and present yourself as part of a team, not a solo player. Stay calm under pressure during incidents, and treat people as peers rather than policing them. The leaders who last build trust before they need it.

8. Treat governance as a strategic competitive advantage

The strongest partnerships also share a commitment to governance as a competitive advantage.

Governance is the brakes that let you drive fast safely. When a CSO and CEO are aligned on that principle, the organization can innovate with AI while maintaining oversight and protecting against unnecessary risk. The result is an organization that does not just react to threats but builds resilience into how it operates.

9. Set clear goals and measure progress

Setting clear goals and measuring progress against those goals is essential. When expectations are clear, the areas you need to focus on become much clearer. It doesn’t solve every problem, but aligning early with your leadership, whether that’s a CEO or a CIO, can significantly reduce the pressure you may feel.

Also, never let your boss be surprised. This is where being clear on goals and consistently tracking both leading and lagging metrics becomes especially important, particularly in a direct reporting relationship with the CEO.

10. Be willing to endure challenge and discomfort

Finally, persistence and a willingness to endure discomfort for something that matters more than the pain itself are critical to surviving in this relationship. The role of a cybersecurity leader is often thankless. If you’re doing your job well, no one really notices.

Dubbed the “Genius Hacker,” Park Chan-am began his white hat hacker journey at the precocious age of 11, winning awards at domestic and international hacking competitions since his teenage years.

He has since served as a cybersecurity advisor for various Korean government agencies, including the National Police Agency, and has played a key role in the country’s defense against Democratic People’s Republic of Korea (DPRK)-affiliated cyberattacks.

At a seminar held this month as part of the 15th Information Security Day event hosted and organized by government agencies including the Ministry of Science and ICT and the Korea Internet and Security Agency (KISA), Park, now CEO of security firm Steelion, explained the changes in the security environment in the AI ​​era and the priority response tasks for information security organizations under the theme of “Major AI Threats and Security Priorities.”

“While AI is a new technology, the core of security ultimately lies in access control, supply chain management, and human verification,” he said.

Like many security experts, Park sees AI fundamentally changing the speed of cyberattacks. In the past, infiltrating a corporate network required significant time analyzing a range of software systems to find exploitable vulnerabilities — a task that the use of AI has significantly accelerated.

“In the past, it took at least four weeks to find vulnerabilities, but now it takes less than a day,” he said. “In the era of AI, all software installed within a company becomes a much more critical target for attacks.”

As a result, securing internal software and the software supply chain are paramount — and require a different perspective on accountability, Park noted.

“Clients often ask, ‘Isn’t this just a product made by the vendor?’” he said. “From the moment it is installed in the company system, that software is no longer a vendor issue but part of the corporate system.”

“We are now in an era where third-party issues can no longer be attributed solely to vendor responsibility,” he stressed.

MCP under threat

Park also sees authorization management as a key challenge security teams will face in the agentic era. For example, companies have been increasingly utilizing Model Context Protocol (MCP)-based AI agents to read emails, analyze documents, and connect internal systems with various business tasks. But as the workload handled by AI agents increases, every step an AI agent takes, reading external documents and interacting with internal systems, can become a potential attack vector.

Prompt contamination through malicious documents and the leakage of internal information via agents with excessive privileges are quite realistic scenarios, Park said. In particular, he pointed out that issues that previously ended as minor problems, such as residual privileges left by former employees or outsourced personnel, could escalate into major incidents as AI automatically links these elements together.

“When introducing AI, permissions must be designed before functions,” he said. “The entire MCP process must be approached as a single attack path.”

The ever-widening blast radius of AI testing

Local AI testing environments are becoming a dangerous security blind spot that information security leaders often overlook. Rapid experimentation with open-source AI, such as LLaMA-based models, on personal or work PCs often results in servers or ports being left open, and if vulnerabilities are discovered, intrusion pathways immediately open up.

“When the [Ollama] remote code execution vulnerability was discovered in 2024, there were over 1,000 servers exposed to the internet, but recently in 2026, it has been confirmed that over 300,000 servers from the same targets are exposed,” said Park, adding that “the act of testing AI itself can become a new security risk.”

Vulnerability management on notice

Security operations must also change, Park stressed, noting that the number of alerts that security personnel must handle has increased tenfold, and in some cases up to a hundredfold, making it virtually impossible to respond to all vulnerabilities using the same standards.

As a solution, Park sees the Common Vulnerability Scoring System (CVSS) being insufficient for determining priorities. Instead, he suggested that vulnerability response priorities be determined by utilizing the Exploit Prediction Scoring System (EPSS), which predicts the actual likelihood of exploitation, along with the US government’s Known Exploited Vulnerabilities (KEV) list.

For example, if a vulnerability’s CVSS score is 7.5, it is not classified as critical, so it is likely to be pushed down the priority list. But the response priority changes completely if the same vulnerability is listed on the KEV list, has been exploited in actual ransomware attacks, and the probability of an attack based on EPSS has skyrocketed from 1% to 90% within two months. “You must consider these factors together to identify the vulnerabilities that actually need to be patched first,” he stressed.

“Amidst the vast noise known as the AI s​lop, the criteria for deciding what to patch first is now becoming a core competency for security personnel,” he added.

Park also presented new defense techniques applicable to the AI ​​era, such as methods to detect automated attacks by analyzing behavioral differences between humans and AI attackers, and proof of work (PoW) challenges that intentionally impose computational load on AI attackers to slow down their attacks. A prime example is filtering out abnormal access by analyzing mouse movements, keyboard input, and scrolling patterns.

“It is a more realistic strategy to reduce the burden on security teams by filtering out at least some attacks, rather than trying to block them 100%,” he said.

Even in the age of AI, technology alone cannot ensure complete security, he noted. “While AI can scan for threats broadly and quickly, verifying and confirming them ultimately falls to humans,” he said. “Humans are still important.”

Major AI labs are unleashing forward-deployed engineers (FDEs) to try and grab enterprise customers. Large consultancies are dishing out tokens and assembling armies of consultants — both human and agent — to do the same.

But smaller firms are in the mix now, as well. AI is helping 28Stone Consulting, a New York-based, 230-person technology consultancy for capital markets, punch above its weight against larger rivals in the rush to deliver FDEs.

In this Q&A, Thomas Dolan and Frank Erickson, founders of 28Stone, argue that agentic AI isn’t a one-size-fits-all solution in vertical markets; success takes discipline, deep domain expertise, and human involvement to mitigate risk.

Many enterprises continue to struggle with the use of AI agents, which is consultancies are stepping in to get projects off the ground. 28Stone is among those that have published blueprints and methodologies on the development and delivery of agentic AI workflows with humans in the loop.

Computerworld spoke with both founding partners about why companies are still stumbling with agentic AI rollouts, and what a disciplined delivery process actually looks like.

After 15 years of delivering software for capital markets firms, is ‘AI-first’ a real distinction or just positioning?

Dolan: “We’re not shying away from being AI-forward. What needs to shine through is AI done intelligently — not stuff you get by buying some tokens for somebody on the trading desk. We’re an AI-first firm.”

Erickson: “And it’s temporary. At some point, AI is going to be synonymous with software development.

“The whole idea of an AI SDLC (software development lifecycle) versus an SDLC is going to be one and the same, a lot like cloud computing today. To not include AI in your strategy, you’d look like a COBOL vendor.”

What does agentic AI delivery look like?

Dolan: “We’ve got several AI initiatives delivering a pure agentic approach. We’ve doubled down on the human expertise wrapper in the SDLC. That doesn’t mean sacrificing any of the benefits of the AI models — quite the opposite.

“You don’t achieve anywhere near the same level of value from applying AI without keeping that expertise — industry, functional and technical — throughout the process.”

Where do humans stay in the loop once agents are doing the work?

Dolan: “We’re believers in starting with requirements discovery. Someone who knows the analytical nuances of a good business analyst is critically important; shaping a product owner’s business information through a markup file that can be fed into a BA agent, then treating the output as if it came from a very fast junior BA. Only then is the story complete.

“The developer takes that story, transforms it into the most efficient input, then owns the output, because they’re accountable for that code. A developer should own the code on both the input and output side.

“Your product owner, who knows the business, that’s great. But expecting them to interact with an agent and output enterprise code is ridiculous. It’s not a great plan.“

Why not just put one do-everything person in charge of AI and agents?

Erickson: “Every analyst, programmer or software engineer isn’t a great requirements analyst. And a great domain analyst with some technical background won’t know if the agent’s code is garbage, maintainable, performant.

“It’s unrealistic to expect one individual to have that breadth across domain, software engineering, testing, deployment. Clients ask all the time, and we push back: ‘Great, if you can find that guy, they’re few and far between.’ To deliver at the enterprise level, you need the human expertise, at depth.“

Dolan: “There’s system speed and latency, important in parts of finance. Then there’s speed of delivery, because other areas evolve quickly and time-to-market is critical.

“Our human wrapper may at first pass come across as a little slowed down. Maybe it is. But [Erickson] has a good analogy about one of the dangers of AI: you can end up going really fast in the wrong direction. By the time you look up, you’re way off base and have to backtrack.“

What about AI in your sector do you think is overhyped?

Dolan: “The hype around the ease of use of AI and the democratization of enterprise software delivery — that ‘anybody could do it now, it’s all being done by machines’ — is another idea that could prove costly in the long run.

“This do-it-yourself reaction is dangerous for clients, and for trust in the overall AI benefit, which is real. We compare it to the beginning of offshoring 20, 30 years ago: a golden idea that was going to cure everything. A lot of firms did it thoughtlessly, thinking it’s just labor arbitrage, and it almost inevitably failed. That all-or-nothing mentality missed that offshoring is an amazing way of getting better value for your dollar, but it has to be done thoughtfully, so the delivery process — the thing that ties it all together — stays unsevered.

“We’re seeing that now. I’ve heard, ‘We’ll just push a button, the machine’s building the system.’ The machine is not building the system. It might be writing the code, the story, running the tests.

The system is built by a team of engineers you bring in and trust. My fear is that people will say, ‘We don’t need this vendor or this technology team. I’ve got a product team. They might not be able to code at all, but they know the business,’ and it fails dramatically. 

“Then people say, ‘We played with AI, it’s not ready yet,’ and throw it all away. One of the best things we can do is ensure clients know the benefit is real.“

Erickson: “The hype can be summed up in a single phrase: vibe coding. That has done AI a massive disservice, because there’s a huge difference between vibe coding and enterprise software development, and some of the loudest proponents of AI are too latched on to it. In our industry, the only way to succeed would be a stable of unicorns. It just doesn’t scale. I get perturbed when our people internally refer to AI tooling as vibe coding; if they think that’s what they’re doing, they’re misunderstood.“

When you engage clients at different levels of AI maturity, how do you get them to a understand what works?

Dolan: “95% of our take on an agentic approach is in line with everyone else’s, but that 5% matters, especially in requirements discovery, in who’s giving the requirements and how they’re thought of. It can set you up for dramatic errors, given the speed at which you’re moving.

“There’s a dangerous human tendency we’re seeing among clients to try and cut corners at the start of a project and — in lieu of having deep, expert driven discovery sessions — just summarize what they may want using AI.

“We would hope our clients are collaborative, everyone understanding it’s early days. If a client insists on doing something we feel strongly against, like a product owner completely owning everything right up to code generation, that’s an issue we have to either push back strongly on or step out of the accountability for.“

AI body shops — LLM providers and giant consultancies — are emerging to help enterprises deploy AI. Does that model work?

Dolan: “Whether you’re partnering with an LLM or with an AI-first, generic software provider — ‘Hey, we’re not industry guys, but we know AI delivery’ — you end up, if you’re a bank or a broker-dealer, saying: ‘All right, we know our business, these guys know the AI side of it. What could go wrong? Put us together and we’ll have quality engineering.’

“The problem is what you miss: the know-how of putting industry and technical expertise together and actually delivering financial services systems. The people working at the generic delivery firms, whether an AI-only firm or a body shop somewhere, don’t have that capability.“

Does AI change the economics for smaller consultancies like yours competing against the big firms, and does it cut both ways?

Dolan: “Over our 15 years pre-AI, there were two recurring reasons we’d lose a project. One: ‘We’d love to work with you guys, given your subject matter expertise, but the costs just aren’t there compared to my budgets. I’m being forced to go to a body shop or an [offshore] delivery center.’ The other side of that coin: ‘We love your capabilities, but you’re a firm of 230 people and I need 300, 400 people.’

“AI changes the options for clients. You don’t have to sacrifice the niche vendor who knows your space just because you need a larger team or a cost target. AI levels the playing field and should allow smaller firms to compete with the larger, big-box generic firms, the Accentures of the world.“

Erickson: “It redefines what scale means. You can look at velocity as a measure of your cost to deliver, not a rate card. Scale can’t be defined in terms of headcount anymore. It’s got to be defined in terms of output.

“There’s a threat in it, too. If you’re an Accenture with hundreds of thousands of low-cost software engineers, how do you train all those people? I feel for them. But for us, a couple hundred people with a specific domain focus, it’s a huge opportunity.“

How has the profile of the people you and others hire changed with this agentic process?

Erickson: “You’re still looking for people with strong engineering and design backgrounds, and communication skills, because they interact across the software development lifecycle more than in the past.

“Many take too much joy in typing out perfect code. Sorry, I don’t need you writing for-loops and classes anymore. I need you reviewing them, understanding them, operating at a higher level. That’s a different kind of person: an engineer, not a programmer or a coder. On the [business analyst] side it’s similar: people took great pride in detailed user stories covering every path. Now it’s conversations, prompts, reviewing output — less doing, more interacting.

“More than ever, they have to be interested in the domain. They can’t just be, ‘I want to learn everything there is to know about Java.’ That’s too narrow. They don’t have to be an expert; they have to be interested. In our case, capital markets is a specific niche. The biggest challenge is getting familiar with the tools — finding time, while delivering for customers, to ramp up and make the mistakes you need to without jeopardizing projects.“

What about governance? Who’s keeping AI delivery and its costs under control?

Erickson: “This is evolving rapidly. People aren’t sure how to put governance around this. The most obvious is financial governance. People are starting to get hefty bills. One of our clients spent a million dollars on tokens over the last eight weeks alone. Sticker shock. The token-maxing policies are starting to show their flaws. It’s wild west still: learn on the fly, then figure out what needs to be governed.“

Are CIOs actually opening their wallets? And when they do, what’s the smarter way to invest?

Erickson: “There’s still a lot of caution. Forecasts keep going down on how long something should take. So: ‘I could wait three months and maybe still get it delivered by the same date someone’s promising me now, but for half the price. I’m going to wait and see when equilibrium is met.’ We haven’t seen the wallets open up like crazy — it’s slow adoption.“

Dolan: “One of our clients is looking at it from a productivity-boost perspective: instead of doing the same for less, I can do much more for the same. AI lets clients pull the trigger on things they wouldn’t have in the past — projects that might not have been approved pre-AI, where the costs have come down to a point that’s palatable with the business.“

Erickson: “And that’s the story we’re hoping to hear more of. There isn’t a huge cost anymore to exploring a business opportunity. The time and money that would have gone to a return-on-investment study could be spent on a proof-of-concept with AI, and the project done a few weeks later. Maybe [there’s] a hint of things to come, where decisions start being made quicker. 

“There’s a little fear on our side, though: a lot of tiny little projects is tough for a consulting business.“

In one ransomware response I observed, the master operational dashboard remained green while the underlying environment told a very different story. It was a classic example of what we in the IT audit profession call the “watermelon effect”—green on the outside, red on the inside.

Beneath that dashboard sat an unmapped web of legacy technical debt, undocumented service accounts and shadow cloud instances. For years, presenting a green dashboard to the audit committee could give technology leaders a false sense of comfort. If a catastrophic breach occurred, it was generally treated as an unpredictable operational tragedy, managed via cyber insurance, a carefully calibrated public relations pivot and perhaps a quiet executive transition.

Today, that corporate shield is thinner than many technology leaders assume. For technology leaders in regulated or public-company environments, executive exposure is no longer only a theoretical debate. The regulatory environment has made plausible deniability much harder to sustain.

The erosion of the corporate shield

With the application of the European Union’s Digital Operational Resilience Act (DORA) for financial entities, alongside the broader NIS2 Directive for essential and important entities, cybersecurity governance has become harder to separate from board-level oversight. DORA places ultimate responsibility for ICT risk management on the management body of financial entities, while NIS2 requires management bodies to approve and oversee cybersecurity risk-management measures. In the United States, the U.S. Securities and Exchange Commission’s cybersecurity disclosure rules require public companies to disclose material cyber incidents and describe their cyber risk management, strategy and governance in annual filings. The new burden is not simply to operate controls; it is to show, after the fact, that leadership decisions matched the risk evidence available at the time.

The serious risk to a modern CIO is not simply the occurrence of a sophisticated security incident. The true danger is the inability to reconcile what leadership presented externally to investors, regulators and the board with what the internal evidence showed inside the environment.

When a serious crisis breaks, you may find yourself surrounded by corporate defense counsel, regulatory investigators and outside forensic lawyers all asking variations of the same uncomfortable questions: What did you know, when did you discover it and what specific actions did you take next?

When those questions are asked, a slide deck asserting that your security posture is “aligned with industry best practices” will not be enough. A post-incident review may recognize that sophisticated attacks occur. What creates greater exposure is evidence that known risks were ignored, understated or left outside structured governance. To survive that level of post-incident review, one of your strongest assets is a disciplined, independent evidence trail showing that risks were identified, challenged, escalated and acted on before the first indicator of compromise appeared.

Why point-in-time comfort letters fail regulatory scrutiny

The reality we face is that legacy compliance evidence often falls short under regulatory scrutiny. For years, the annual SOC 2 Type II report or a standardized ISO 27001 certification was brandished by technology teams as the definitive proof of a functional control environment. I have sat in dozens of scoping meetings where an engineering director pointed to a freshly minted compliance report as if it were a complete defense against scrutiny.

But a compliance report is a historical artifact—a retrospective evaluation of how specific controls operated during a defined window of time months in the past. It tells an investigator that on a random afternoon in Q2, your production change-management approvals conformed to a baseline policy. It says absolutely nothing about the configuration drift, unauthorized API keys or emergency patch bypasses that developers introduced the following weekend to hit a product release deadline.

Modern regulators, boards and investors are no longer satisfied by historical comfort letters alone. Under contemporary frameworks, especially regimes focused on operational resilience, static compliance evidence is no longer enough. The expectation of due care has shifted from a passive state of compliance to an active state of continuous challenge. Increasingly, post-incident reviews look for evidence that leadership identified system vulnerabilities, formally escalated material deficiencies, evaluated systemic risk to the business and tracked remediation progress with measurable rigor.

When an architecture fails, post-incident reviews often focus quickly on ownership, escalation and whether known risks were acted upon. If your defensive documentation consists entirely of static policy documents and green dashboards, you leave an evidentiary vacuum that can invite difficult questions about executive oversight. Post-incident reviews rarely turn on perfection. They turn on whether the organization can show a traceable chain of governance.

5 non-negotiable artifacts for your executive evidence engine

This reality requires a complete reframing of your relationship with your IT audit department. Historically, this dynamic has been defined by friction. Technology leaders frequently view my peers and me as compliance traffic cops—bureaucrats who interrupt core engineering sprints to demand evidence samples, user access reviews and system configurations.

It is time to view IT audit through a pragmatic lens: we are your independent evidence engine. We are one of the few corporate functions tasked with independently challenging your control environment, documenting where exceptions were escalated and showing how management responded. When an auditor identifies a control gap and partners with you to draft a management action plan, they are not creating a bureaucratic roadblock. They are helping you construct an evidence trail that can show risk was identified, escalated and acted upon.

To transform your IT audit function into an effective executive shield, you must shift focus away from superficial check-the-box exercises and collaborate on specific artifacts. The most effective exercise you can run with your audit leadership is to flip the timeline completely and ask: if this program were reviewed six months from now, which evidence would show we governed the risk before it failed?

1. Board-facing risk registers with escalation history: A risk register that sits unreviewed on an intranet page for 12 months is not a management tool; to an investigator, it can look like evidence that known risks were not actively governed. Your material technology, cybersecurity and dependency risks must be centrally logged. More importantly, this artifact must contain a clear, chronological escalation history showing exactly when the risk was presented to leadership committees and the board, along with related minutes, decisions or follow-up actions.
2. Granular risk acceptance records: You cannot remediate every vulnerability instantly. Business continuity, legacy software limitations and budgetary boundaries require you to accept certain operational exposures. When this occurs, ensure your risk acceptance records are airtight. A defensible record must document the specific technical variance, the precise financial or operational rationale for the delay, a definitive expiration date, explicit executive sign-off and the active compensating controls deployed to reduce the blast radius in the interim.
3. Tabletop and operational simulation records: Independent frameworks such as ISACA’s Digital Trust Ecosystem Framework can help structure this evidence, but boards and regulators will still look for proof that the testing actually happened. Your audit trail should contain comprehensive records of cyber incident, disaster recovery and third-party dependency simulations. These records must detail the scenario tested, the executive participants, the control failures identified during the drill and a formalized tracking schedule showing when those gaps were closed.
4. AI governance inventories and data-flow mappings: The rapid deployment of generative AI tools across enterprise operations has created a massive blind spot for technology executives. In one audit, we found developers using an unapproved public large language model to accelerate debugging with sensitive internal code. To protect yourself, work with your audit team to build an active enterprise AI inventory that maps data lineage, identifies model business owners, documents risk classification approvals and demonstrates active technical monitoring for unauthorized data exfiltration.
5. Synchronized disclosure-control handoffs: When a material security incident or system outage occurs, the clock begins ticking for regulatory reporting. Your incident response playbook must be technically linked to your corporate disclosure controls. The audit trail should show that a documented, synchronized handoff occurred between your technical response leaders, general counsel, chief financial officer and corporate communications team. This evidence helps show that your external statements match internal technical realities.

In the modern corporate ecosystem, technology leadership is no longer just an engineering challenge; it is an exercise in rigorous, evidence-based governance. The regulatory landscape has changed, and the expectation of continuous traceability cannot be avoided.

Open and direct collaboration with your IT audit team will not prevent a zero-day exploit, an unexpected cloud outage or a critical third-party vendor failure. That is not the purpose of enterprise risk management.

The true value is far more practical: when a serious incident puts your program under review, you will not be forced to defend your reputation with a feeling, an unverified assumption or a misleadingly green dashboard. Instead, you will have an independent record showing that risk was actively seen, appropriately challenged, properly escalated and responsibly managed. In today’s regulatory environment, that disciplined trail of evidence may be the difference between a failure that can be explained and one that begins to look negligent.

.

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

Today’s CIOs must master a complex balancing act of maintaining operational excellence while enabling AI experimentation, modernizing legacy environments while accelerating innovation, leading workforce transformation while maintaining culture, and communicating fluently across boards, business units, customers, and technical teams alike.

Few leaders understand this balancing act better than former Verizon CIO Jane Connell. Over her career, Connell has helped some of the world’s largest enterprises modernize operations, reduce complexity, and transform how technology enables business value at scale. As a 2026 CIO Hall of Fame inductee, she is widely respected not only for operational excellence and strategic vision but also for her commitment to mentoring, workforce transformation, and preparing the next generation of leaders for a rapidly changing future.

On a recent episode of the Tech Whisperers podcast, we unpacked Connell’s unconventional leadership story and the playbook that has shaped one of technology’s most impactful leaders. In this exclusive interview after the show, edited for length and clarity, Connell shares more lessons from her Hall of Fame journey and why she believes the future of technology leadership will depend less on org charts and more on curiosity, credibility, and human connection.

Dan Roberts: When you think about preparing the next generation of technology leaders, what capabilities or mindsets do you believe will matter most in this next era?

Jane Connell: One is curiosity, or what I call the “why” factor: What do we need to do and why do we need to do it? It’s having a mindset of unlocking the art of the possible. You must be comfortable with what you know, what you don’t know, and asking the question why, because in this era of AI and where technology is going, it’s not about automating things you know; it’s about what you don’t already know, and what that unlocks. AI creates patterns and opportunities and re-engineers through its own intelligence, so there has to be a lot of instinct involved, and you’re going to have to understand and learn what it’s telling you.

I’m on the board of Rutgers, and one of the conversations we’re in with future leaders in education is that you don’t have those entry-level jobs anymore. They’re going to be AI. But those were building blocks for us. We came up the ranks and did those jobs, and that created the knowledge. [Future leaders are] not going to have that, so how do you create the foundation of knowledge — which is that art of asking why or what — to question if the bots or the patterns are biased or wrong. You’re not going to have the experience to rely on and say, “That’s wrong; I know that’s wrong because I did those. I know how this operates.”

Second is having humility and being comfortable in your skin — that you don’t know everything, but you’re going to learn it. You’re going to involve yourself with people. It’s about workforce structure, not organizational structure. Who do you need to talk to, and what do you have to find out?

I also believe followership is going to be huge, because the way work gets done is not hierarchical. It’s going to be engineered based on the process and AI. You have to create followership of people working together, and they’ve got to want to work with you. This isn’t going be “you work for me, do as I say.” Followership is going to be a key skill for influencing and organically having that kind of impact, versus someone with authority.

With that is the accountability to have high integrity, be credible, and be a person someone would trust. Because all this is going to break down the hierarchy of authority, you have to bring that human side and be a really good leader, which means people want to follow you, they trust you, they want to work with you, and they know you’re going to take them to a better place.

One recurring theme throughout your career has been your ability to bridge deep technology expertise with strong business acumen. Why is that combination becoming even more critical in the age of AI and digital transformation?

You can’t impact anything tech-alone. It all resides on having business acumen and then having the technical ability to know how to use tech to solve the problem, not the other way around.

At the root of all this is every company’s Achilles’ heel: the data. Access to data has been a privilege — those who have it, those who don’t. Now you’re bringing structured and unstructured [data] together for these AI models to work, and that’s a new skill set that requires you to know the business inside and outside.

You also have to stay externally relevant and know where innovation is coming from. And you’re going to need to know how to architect that into the way your company goes to market, which requires you to know the business processes, how it runs, and how it could run.

That’s the role of leaders moving forward, immersing yourself in the problems the business needs to solve. There’s no boundaries there. It’s not what department you report in and what process you own. It’s seamless. That’s the duality people need to command and grow into.

Looking back on a career that spans multiple industries with different operating models, cultures, and regulatory environments, what were some of the most important calculated risks you took in terms of your growth?

There were two pivotal moments in my career that were the biggest risks but probably my biggest gains in growth. One was when I went into a full-time tech role and ran infrastructure. I was a fish out of water, and not the likely successor. Part of the reason I did it goes back to a something we talked about on the podcast: Well, why not me? And I want more. That’s just my tenacity.

It was during the dot-com days of the late 90s, early 2000s. It didn’t matter if you were the CEO or a board director, if you didn’t know tech and you didn’t understand how to wield it, you were never going to be successful. I knew that no matter what job I may want in the future, I had to know tech. So it was a calculated decision: I’m going to jump into tech.

Some very senior supply chain leaders who controlled my career told me, “You’re going to fail, and I’ll have a safety net for you when you come back.” Well, I didn’t fail and I never went back. That pressure was there, but I knew why I was doing it. This wasn’t just a job for ego’s sake. This was, I have to know tech. The future is tech. It’s kind of like AI now.

The other pivotal moment was changing industries. I left Johnson & Johnson at a great time. We had gone through a huge transformation, started our global services organization, and the perfect moment happened for me to retire early there. I didn’t know what I wanted to do. It was the first time I took a break in my career to let the world come to me instead of me planning it. Do I want to open a business? Do I want to consult? Do I want to stay retired? I was fortunate enough that I could, but I got bored.

The financial industry wasn’t on my radar. Coming out of healthcare, with the purpose and the connection with saving lives, helping people, it’s easy to connect to. Financial wasn’t, for me. But one of the executive search firms said to me, when you interview, the biggest question hanging over your head is going to be, could you be successful elsewhere because you grew up in J&J. You had advocates, you had influence, you knew the industry. It’s like your deck was stacked for you. Could you do all that when you’re a nobody coming off the street?

So when the CIO role opened at State Street, I interviewed — and talk about being your authentic self. I had already done all this transformation, I already knew the outcomes, I knew everything I did was always enterprise and always end-to-end transformation. And because I wasn’t really vying for the job, I was having this conversation with the CFO and saying, “Here’s what your organization is lacking, here’s the noise you’re going to hear, do you really have the appetite for it?” And “I’d like talk to the COO and see if they’re ready to hear this about the value chain. I may not know your problem yet, but I guarantee it’s one of these three things.”

I was testing their advocacy of, do you really want to transform? Are you ready? Because you have to own this. I can’t take accountabilities for your organizations. I can help you get there. I’m an enabler for you, but you have to own it. And it was a very different interview. By the end of it, I loved Ron [O’Hanley, State Street Chairman and CEO] and his whole team. I took the job on the leadership and the person more than the industry, and it was very successful.

I followed the same recipe when I went to Verizon. Those were big growing moments. They were risky, they were very uncomfortable, but it was the biggest growth that I’ve ever had.

Whether it’s a tough message to the C-suite, a difficult conversation with peers, or helping teams make sense of uncertainty and change, you tell people the truth in a way they can hear it. How can other leaders develop that ability to take people on the journey, especially when the message isn’t easy?

Skirting a problem is not the way to solve it. I’ve never been the person to say what you want to hear. I’ll tell you how you get there, and I’ll get you the results you want, but I’m going to be super honest because I want to manage the expectations of what we have to achieve.

What I’ve learned as a leader is to take accountability. Say what you’re going to do, then do it, and if you hit a roadblock, be the first to call it. That gets you access, because people see it as a calculated risk. Anybody in the C-suite has resources and budget, but the earlier you signal and don’t waste money and resources, the more access to people and resources you will have.

The greatest lesson I learned from one of the leaders in my path was: If you can’t say it in an elevator, and you can’t say it on one slide, you’re talking too much. So, think about it as one slide: What is it you need? What are you going to achieve? What are the risks? What are you taking accountability for? How will you measure it? It doesn’t matter what the message is when you can be that succinct. You’ve got them laser-focused on what it is. You gave them just enough of the periphery to know how you got there, and then it’s their belief in you that you can do it if they give you the money and resources, because that’s what you’re looking for.

It sounds so simple but putting things together succinctly is hard work. You have to take all the unnecessary noise out, and keep the conversation focused. You don’t want their mind wandering, wondering where is she going, or what are they doing? Give it to them upfront and tell them what you need.

You’ve spoken about entering corporate environments early in your career feeling intimidated by people with more traditional credentials or educational backgrounds. What advice can you give rising leaders about battling imposter syndrome?

Take the time to figure out what makes you uncomfortable, what makes you feel like an imposter, or what in that meeting you dread going in where you’re not acting like yourself. Are you more quiet than usual? Are you not asking the question you’d normally ask? Figure out what those issues are, and then address the things that make you uncomfortable. I went to college later because that bothered me. Those credentials do matter. So I addressed it and got my degrees and certifications.

The other thing is to find people you trust, people whose opinion you respect, and bring them on the inside of what you’re working on. Maybe it’s dealing with a difficult business partner. You may not particularly want to be friends with them, but you’re going to have to work with them. Find the people that work effectively with them. You do this with high integrity — this is not about talking about that person — but find the allies that work with them. Nine times out of ten, they feel the way you do, but they found a way to work with the person. Pick their brain. Bring them in the fold and say, “I need this alliance. I can’t get there, and quite frankly, I know I’m resisting because maybe I just don’t like them. How did you get there?”

People are generous. Ask their opinion, ask how they’re showing up. “Am I creating the trigger? Is there something I’m doing in that meeting or in that room that I’m not coming out with a decision or whatever I needed?”

The greatest gift is feedback. There’s feedback you do something with, and there’s feedback you don’t, but either way, it’s a gift. Somebody’s giving it to you. It’s not personal; it’s business. And those things really help build your confidence and leadership style.

In an era increasingly shaped by automation and disruption, Jane Connell believes the most enduring competitive advantage may come from something deeply human: the ability to inspire confidence, curiosity, resilience, and possibility in others. For more advice from this Hall of Fame CIO, tune in to the Tech Whisperers podcast.

See also:

• Mastering the chess of IT leadership today
• Developing a customer-first culture for IT
• Coherence: Where leadership and AI success intersect

Widgets, widgets, widgets. Has there ever been an Android feature so full of promise that went unloved by Google for so very long?

Okay, so maybe there has been — erm, lots of times, actually. But even so, Android’s widgets system is a perfect example of an exceptional advantage that Google basically buried, abandoned, and left on the brink of extinction up until its overdue revival in 2021’s Android 12 update. (And that revival, by the way, happened for no apparent reason whatsoever. Just a totally random, unprompted change of heart after a decade of indifference. Riiiiiiiiight.)

Google may have given up on widgets for a while, but the good news is that (a) they’re back, baby — still now, more than ever, even in our overly AI-obsessed 2026 timeline — and (b) the Android developer community keeps chuggin’ along and coming up with ever-more creative new ways to embrace widgets beyond what Google itself sees fit to give us. That means no matter what Android version your favorite phone is running, you can step up your own Android widget game and give yourself some fresh and fruitful paths to make the most of your phone’s framework.

Here, my dear, are some fantastic beyond-the-basics ways to put your favorite Android widgets to use and change the way you get stuff done on your phone. 

[Psst: Love learning new things? Get my free Android Intelligence newsletter to get a tasty new tip in your inbox every Friday.]

Android widget enhancement #1: The on-demand home screen pop-up

Widgets are a wonderful way to interact with all sorts of info without ever having to open up apps, but having too many widgets can quickly lead to a cluttered and overwhelming home screen.

Well, here’s a neat way to give yourself the benefit of a widget while still maintaining a neat and minimal space for working: An excellent app called Popup Widget lets you create an on-demand pop-up widget (get it?!) that looks like a regular ol’ icon on your home screen but then loads any widget you want when tapped.

See?

You can even get really wild and set up a single icon that opens multiple widgets at the same time — like your inbox and your calendar together:

Not bad, right?

Popup Widget costs two bucks and doesn’t require any special permissions or manners of access. And it’s pretty simple and self-explanatory to set up: Once you install and open the app, it’ll walk you through adding in whatever pop-up widgets you want. You can choose the name and even the icon associated with each one along with its precise placement on your screen and how much the screen behind it should dim when it’s loaded.

The app will offer to add the shortcut directly onto your home screen for you then, or you can also find all of your Popup Widget creations by pressing and holding the main Popup Widget icon in your app drawer.

Alternatively, if you’re already using a custom Android launcher like Smart Launcher or Niagara, you can find similar options for summoning widgets on demand within their settings — no separate apps even required.

And that, my widget-loving wallaby, is but our first winning widget possibility.

Android widget enhancement #2: The on-demand universal pop-up

If you like the idea of having a widget on demand but would rather have it be available to summon from anywhere instead of just from your home screen, this next wacky widget option is just the thing for you.

It comes from a spectacular app called Edge Gestures, which works in conjunction with Popup Widget to take that same concept and make it universally accessible. (I told ya it was wacky!)

When you first install Edge Gestures, the app will prompt you to enable it as a system accessibility service and to grant it the ability to display over other apps. These permissions sound scary — and they should! — but in the case of this specific utility, they’re absolutely appropriate and necessary in order for it to operate. The former is the only way an app is able to create a custom system-wide gesture, which we need for this setup to work its magic, and the latter is how your widget is able to be shown on top of whatever else you’re doing.

(If you’re at all worried, note that Edge Gestures doesn’t request any other significant system permissions. Beyond that, it’s reputable, it’s been around for quite a long while, and it has a large number of overwhelmingly positive reviews.)

Where were we? Oh, right: Once you’re inside the Edge Gestures configuration area, you’ll be able to select exactly what gesture you want to use for pulling up your widget. I’d think carefully about finding something that won’t interfere with anything else, like the system-level Android gestures, and that’ll be convenient to access without being a command you’re likely to trigger by mistake.

So, for instance, you might make the gesture a simple swipe downward along the left side of your screen. To do that, you’d find the “Swipe down” option within the app’s “Left” tab, and you’d set it to “Popup Widget” — and then create or select whatever Popup Widget item you want. And remember: You can select one widget or multiple widgets, too.

Prepare yourself for some serious oohing and ahhing:

As you can see, this opens up a whole new world of mobile multitasking potential. I mean, really: How could you not love that?!

The final thing worth doing is going into all the other gesture options in that same configuration area and tapping “Clear” for each of ’em to get rid of Edge Gestures’ default actions. I’d also go into whichever side of the screen you aren’t using — left or right — and tap the toggle to turn the gestures for that side off entirely. That way, you won’t inadvertently activate any gestures that you don’t actually want or need.

Edge Gestures costs $2 to use.

Android widget enhancement #3: The physical key call

Next, here’s an interesting twist on that same on-demand Android widget idea: You can make any widget especially easy to access from anywhere without even having to mess around with any on-screen swiping by setting one of your phone’s physical keys as a trigger for the widget’s appearance.

I’ll give you a second to catch your breath and process the sheer splendor of that sorcery.

Back? Cool. So, the key to this feat (har har) is the combination of the aforementioned Popup Widget and a handy Android contraption called Key Mapper — which makes it easy to map your phone’s physical keys to all kinds of crazy custom actions.

In this case, we’ll set it up so that pressing and holding one of your volume keys causes whatever widget you want to be summoned, like so:

Pretty nifty, no?

I’ve got step-by-step instructions for making this happen in this separate guide.

Android widget enhancement #4: The floating bubble

If you like the notion of having a widget always available but aren’t so keen on the hidden gesture concept, an app called Overlays will let you create a small floating bubble that you can position anywhere on your screen and then tap to pull any widget up when you want it — just like with Android’s recently revived Bubbles multitasking system, only compatible with any Android device and version and with the simplicity of a widget instead of the complexity of an entire app.

Check it out:

By default, Overlays gives you a bunch of its own little widgets to choose from, but the real power comes from adding in widgets from the Android apps you actually rely on. To do that, tap the “Triggers” tab at the bottom of the Overlays configuration area, then tap the red plus button in the lower-right corner of the screen. Select “Manual,” then type in whatever name you want for your widget and tap the icon to pick any icon you like.

Tap “Save,” then select “Widget” and find the widget you want from the list. At that point, you’ll see a preview of the widget. Move or resize it if you like, then hit the arrow in the upper-left corner of the screen to exit out of that interface. Last but not least, tap the name of your newly made widget on the screen that comes up next to change its status to “Always on.”

As soon as you head out of the app and back to your home screen, your fancy new widget should pop right up. All you’ve gotta do is tap the little downward-facing arrow in its corner to minimize it down to a bubble, which you can then press and hold to move anywhere your widget-worshipping heart desires.

Overlays can also create widgets that automatically appear based on context — so you could have something show up every time you connect to a certain Bluetooth device or Wi-Fi network, for instance. To explore those options, just follow the same steps from above but pick “Event” instead of “Manual” when you reach the “Triggers” tab configuration.

Overlays is free with an optional $4 in-app upgrade that removes some ads from the configuration tool and unlocks a handful of advanced features.

Android widget enhancement #5: The widget stack

Last but not least in our collection of wacky Android widget possibilities is one of my favorite widget wonders — and that’s the ability to stack multiple widgets and then swipe between ’em on your home screen without having ’em take up any extra space.

Check it out:

This enhancement presents a bit of a choose-your-own-adventure-style path:

First, if you’re using a reasonably recent Samsung Galaxy gizmo, the option is should already be present and available in your standard Samsung home screen setup. Just press and hold any open space on your home screen and then select the option to add a widget — then, once the widget is added, press and hold it and look for the “Create stack” command.

With any other Android gadget — or even with a Samsung device, if you want extra options and flexibility — you can use a custom Android launcher like the aforementioned Smart Launcher or Niagara as well as the retro-geeky T9-themed Key Launcher I introduced to you earlier this summer.

Those launchers replace your phone’s entire home screen environment and give you all sorts of interesting new possibilities for optimizing your interface and making it especially well-suited for you. And the stacked widget feature is just one small sliver of what they offer and how they’ll transform your Android experience.

So there ya have it: five wacky, wild, wonderful ways to make widgets even more wow-inducing. Some days, you’ve just gotta love Android and the endless customization, control, and power it provides.

Put even more Googley goodness in your noggin with my free Android Intelligence newsletter — one exceptional new thing to try every Friday!

Venture-backed firms are buying up the support, finance-ops and managed-services providers enterprises rely on and re-platforming them around AI agents — and the renewal that follows arrives priced per outcome, sold as your advantage. The acquisition-built structure and unproven stability create governance and continuity risks your vendor process isn’t sized for. Here’s how to keep the leverage on your side of the table.

The first time an AI-native services pitch crossed my desk, I nearly signed it. The savings were real, the agents demoed cleanly and the pricing was the kind procurement loves — per resolved case, not per seat. What I almost missed was who got to define the word “resolved.” On an earlier outsourced-support arrangement, back in my public-sector days, the vendor’s reported resolution rate looked excellent right up until we pulled the reopen numbers ourselves. Auto-closed tickets had been counted as wins. Users had quietly stopped logging issues at all. The dashboard was green; the service was not.

That gap — between the number on the contract and what your users actually live with — is the whole game now, and it is about to scale across your portfolio. Gartner’s 2026 CIO and Technology Executive Survey found only 17% of organizations have deployed AI agents, but more than 60% expect to within two years — the steepest adoption curve of any emerging technology it tracks. The providers running your services are moving first, and the contracts are changing faster than most of us can govern them.

The agents underneath these pitches are also nowhere near as reliable in production as they look in the room. Gartner expects more than 40% of agentic AI projects to be canceled by the end of 2027 on cost, unclear value and weak risk controls, and reckons only about 130 of the thousands of self-described agentic vendors are the real thing — the rest are “agent washing” old chatbots and RPA. Treat any headline resolution rate the way you treat a vendor’s own uptime stats: Marketing, until you have seen it run on accounts like yours.

What’s behind the pitch

The challenger’s economics aren’t magic. They come from a reshaping of the services market: Venture-backed firms buying up fragmented, labor-heavy providers — support desks, contact centers, AP and finance ops, slices of managed IT — and re-platforming them around agents. Many of the companies pitching you are not one company at all but several acquired shops stitched onto a shared AI layer. That barely comes up in the sales meeting. It matters enormously once you are the customer.

The direction is independently corroborated, not vendor hype. Everest Group reports outcome-based pricing in business-process services moving from pilots to scaled adoption as AI makes outcomes measurable enough to contract on, with the binding constraint now governance and verified baselines. HFS Research tracks the same “services-to-software” shift across consulting, IT, and operations providers. Here is the part worth holding onto: Most enterprises are early, so you have a little time. But the first vendors to reprice you this way will be the small, single-source ones in the long tail of your portfolio — which, if your stack looks anything like mine, is most of it.

Don’t assume the incumbent is the safe choice

And don’t kid yourself that renewing with the familiar name keeps you clear of this. The big integrators are pulling labor out of their own delivery just as fast — Accenture cut tens of thousands of roles and rehired against an AI-skills filter — and rewriting deals around a share of savings instead of time and materials. Outcome pricing is becoming the default everywhere. There is no version of this where you sit it out.

Two risks your vendor process won’t catch

The first is governance, and the roll-up structure makes it worse than the usual AI-vendor worry. The company you are contracting with isn’t one system. It is several acquired firms with different data practices and security postures, with an AI layer dropped on top at speed. Your customer records, invoices and support transcripts flow into agents whose decisions you often can’t trace, across entities that were never built to one standard. The numbers here aren’t comforting: IBM’s 2025 Cost of a Data Breach Report found 63% of breached organizations had no AI governance policy at all, and 97% of those that suffered an AI-related breach lacked basic AI access controls — AI adoption, IBM concluded, is outpacing both security and governance. When an agent botches a dispute or misroutes regulated data, the regulator and the customer come looking for you, not the platform. And here is the organizational trap: The savings line is what your CFO signs; the provenance question is the one your audit committee won’t ask until after the incident. Nobody raises it for you.

The second is whether the provider will still be standing in three years. These platforms are new, built by acquisition, venture-funded and not one has run through a full contract term or a real downturn. With Gartner expecting more than 40% of agentic AI projects to be canceled by 2027, putting core operations on a young, agent-dependent vendor is a single point of failure dressed up as innovation. Write the exit and data-portability terms before you sign — while you still have leverage to.

Six questions for the renewal

When the challenger shows up — or your incumbent reprices to match — these are the questions I would put on the table. They come down to one thing: Making sure you, not the vendor, own the number.

1. Definition, baseline, guardrails. Make “resolved” mean what your users experience, measured against a baseline you have captured yourself, and tie it to metrics you own — first-contact resolution, reopen rate, time-to-resolution. Expect procurement to resist because pinning this down slows the deal. Hold the line; it is the whole ballgame.
2. Real agent, or agent washing. Gartner reckons only a sliver of self-described agentic vendors are the genuine article. Make them prove it: Production resolution on accounts like yours, and the human-escalation rate sitting behind that number. Not a demo.
3. Auditability, as a gate. SOC 2 at minimum, increasingly ISO 42001 or NIST AI RMF alignment, plus model cards, decision logs and an incident-response plan they have actually tested. If they can’t show how data is walled off between their acquired entities, or how an agent’s decision gets traced, they aren’t ready for anything regulated. This belongs in the shortlist criteria, not the post-mortem.
4. Where autonomy stops. Decide which actions an agent can take alone and which need a human, how it hands off with context and who is accountable when it acts on its own. Put names against it before go-live.
5. The exit. An embedded agent platform gets stickier than the staffed incumbent it replaced, faster than you would think. Lock down data portability, knowledge-base ownership and a way out while you are still the one with leverage.
6. Capacity, not just cost. The best outcome here often isn’t a smaller bill. It is the demand that your old service levels were quietly turning away. Nobody answered the tickets. The cases that aged out. Ask what fixing that is worth before you optimize purely for headcount.

The move

Outcome pricing is where this lands, and on balance, that is progress. But in the near term, it hands the advantage to whoever can measure the outcome — and in most shops, that isn’t the buyer. The edge isn’t picking the cleverest challenger or the safest incumbent. It is being able to hold any of them to a result, on your numbers. Look again at why Gartner thinks so many of these projects die: Not the technology — cost, fuzzy value, weak controls. Our side of the table. So, start there. Take one high-volume, measurable workflow, pilot it against a baseline you own, instrument it with your own metrics, and treat the muscle you build doing that as the real deliverable. Get it right and the pricing model stops mattering. Skip it, and you have just agreed to pay for someone else’s definition of done.

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

I attended several major technology conferences in 2025 where the first AI agents embedded in enterprise SaaS platforms were announced. Some of these agents showed promise and a glimpse into the future of work, while others looked like natural language extensions of a platform’s existing functionality.  

At the end of 2025, Anthropic and OpenAI launched new AI models and code-generating capabilities. More developers tried vibe coding, and some platforms launched spec-driven development capabilities. By February 2026, even The New York Times reported that the AI disruption had arrived, noting that code generators were building “apps that may be flawed, but credible.”

Wall Street investors took notice of the code-generation improvements and other disruptive factors, driving a selloff in SaaS stocks, now referred to as the “SaaSpocalypse.” Part of their concern stemmed from the belief that CIOs would use AI to write software that would replace SaaS solutions.

AI innovations from SaaS and solution providers

But I thought differently and wrote a response in my article asking whether AI is the end of SaaS as we know it. CIOs might use AI to accelerate application modernization, but I doubt they would replace their ERP, CRM, and even smaller SaaS point solutions by building them.

Instead, I believed it would be SaaS companies that would take the most advantage of AI code-generation capabilities.

This hypothesis drove me to attend nine conferences this spring to see how SaaS companies were launching AI agents and defining a new future of work. I wrote eight articles on what CIOs need to know about data management, agile organizations, marketing, ERPs, critical process management, and other evolutions to plan for in the AI era.

Now, looking across all nine conferences, I can draw some conclusions about how AI agents are shaping the future of work. Here are my learnings and what CIOs need to consider when evaluating and deploying AI agents in the workplace.

Agentic, human-in-the-middle, or augmenting human?

SaaS companies have very distinct perspectives on the future of work, including the extent to which humans will play which roles and whether and how quickly we’ll see agentic, fully automated work.

For example, Atlassian proclaimed, “step into the future of human-AI collaboration,” while SAP unveiled “the autonomous enterprise.” Snowflake aimed to “make AI real for business,” while Appian targeted “serious AI built on process.”

These vendors’ marketers had to decide whether to lead with AI, people, or business in their messaging, but so must CIOs as they contemplate their AI strategies and how to get employees to fully adopt AI agents.

Some CIOs see a fully automated agentic AI as the future, with human-in-the-middle as a transitional phase as departments build trust in AI agents’ decision-making and automation capabilities.

Other CIOs see AI more as a tool that delivers productivity improvements by augmenting human decision-making capabilities. Many of these CIOs see human augmentation as essential to supporting critical thinking, innovation, and creativity.

Deloitte’s State of AI Report, published in January, provides a benchmark. It states that 36% of IT leaders expect at least 10% of their jobs to be fully automated in the next year, and 82% expect to reach that benchmark in three years.

Many organizations will have a mix of AI agents, choosing automation where reliability at scale is possible, but opting for human augmentation in operationally critical or customer-facing domains. But how CIOs position AI agents is not only an operational strategy; it’s also a cultural statement that shapes employees’ embrace of AI and whether detractors vocalize job-loss fears.

In the short term, it will also weigh in on which AI agents to use from different partners and which areas to build in-house.

Many options to test and deploy AI agents

Many solution providers are demonstrating significantly more AI agents this year. For example, SAP went from 40 Joule Agents in 2025 to over 200 in 2026. Three technology capabilities are fueling this significant growth:

• Adobe, Appian, Boomi, Cisco, Domo, Salesforce, SAP, Snowflake, and others offer data fabrics and data-pipeline capabilities to connect data sources outside the primary workflows supported by their platforms. Appian, Pega, Quickbase, and SAP also centralize business process automation, an important starting point for developing AI agents.  
• MCP servers enable integration and communication between AI agents and are used to facilitate multistep agentic workflows. Virtually all the companies announcing major investments in AI agents are also announcing MCP integration capabilities and related partnerships.
• Solution providers are not just using AI code-generating capabilities; many are launching their own AI agent development tools. The first beneficiaries of these development tools are the solution providers themselves and their integration partners, who use them to accelerate the development of AI agents and make them available to customers.

The result is that CIOs will have many options about which agents to test, but will have to dedicate analysts to understand the capability, cost, and compliance trade-offs. Additionally, expect AI agent capabilities to evolve significantly over the next few years, so CIOs should continuously revisit their decisions regarding deployed AI agents, focusing on performance, benefits, and ROI.

CIOs should also watch for signs of shadow AI and employee confusion about which AI agents to experiment with on different platforms. The AI strategy should include a transparent, defined process for selecting, reviewing, evaluating, procuring, deploying, driving adoption, monitoring, and collecting end-user feedback around AI agents.

AI development capabilities for engineers and citizen builders

The apparent ease-of-use of AI code generators may lead some engineering teams to build AI agents rather than buy them from SaaS providers. But CIOs should quickly realize that coding is just one step in developing AI agents, and that aggressively pursuing a build strategy can lead to AI debt and increased AI costs.

DevOps teams can code AI agents using tools such as Claude, Codex, Lovable, and Replit — a do-it-yourself approach. Some SaaS companies are providing an alternative, with AI agent development tools that leverage the data, infrastructure, and governance baked into their platforms. Many of these development tools offer flexibility, allowing developer teams to select AI models and development environments.

Examples of new and enhanced AI development tools I saw at conferences this quarter include:

• Appian Composer and Agent Studio
• Atlassian Rovo Dev
• Boomi Companion
• Cisco Cloud Control Studio
• Domo App Catalyst
• Pega Infinity Studio
• Quickbase Pave
• Snowflake CoCo
• SAP Joule Studio.

I also reviewed Nutanix Agentic AI, a platform-as-a-service for accelerating the deployment of agentic AI workloads, and Adobe Firefly AI Assistant for creatives.

These development tools can target different audiences. Some look like low-code development tools targeted at software developers, whereas others are no-code and enable citizen developers, i.e., businesspeople, to develop applications and agents. Additionally, some of these tools support spec-driven development and generate artifacts such as product requirement documents (PRDs), data models, and testing capabilities.

Before commissioning AI development for apps and agents, CIOs should sponsor proofs of technical, data, modeling, security, and governance capabilities.

The context layer powering AI agents

Between AI agents and the enterprise’s intelligence, including structured data sources, defined business processes, and agent interactions (both human-to-agent and agent-to-agent), lies an evolving “context layer.”

This layer refers to the enterprise knowledge that AI agents draw on when evaluating signals and recommending or taking actions. Context may include a knowledge graph, a semantic layer, cleansed document repositories, and other knowledge bases.

The context layer, skills, tools, out-of-the-box agents, and governance capabilities are some areas to review where solution providers differentiate. Some examples: 

• Many support the Open Semantic Interchange, and some brand their context layers, such as the Atlassian Teamwork Graph, Boomi Knowledge Hub, and the SAP Knowledge Graph.
• Some are branding their guardrails, such as Adobe’s AI Brand Intelligence, Appian’s Private AI, and Quickbase AI Control Center.
• To manage AI agents at scale, some are extending the notion of data catalogs and other governance tools to the AI domain with products such as Boomi Connect, SAP AI Agent Hub, and Snowflake Horizon Catalog.

CIOs should recognize that while solution providers will compete on capabilities, the real “secret sauce” of the context layer lies in the company’s trusted data, well-defined business processes, and employee adoption of AI agents.

Conversational user experiences and coworkers

AI agents use the context layer, but also tap into skills, which encode the procedures they can follow, and tools, which prescribe the actions they can take. Before AI agents are ready to pilot, their governance, including permissions, approval gates, and other guardrails, must be defined. Other capabilities to look for when defining AI agents include orchestration, testing evals, and observability.

In 2025, many solution providers bolted on AI agents to their existing user experiences. This year, many solution providers showcased new conversational user experiences that employees can use instead of traditional ones built with forms, flows, reports, and static dashboards. Conversational user experiences are where AI agents and people come together, whether it’s human-in-the-middle or human augmentation.

Solution providers also grouped their AI agents into assistants or coworkers. For example, Adobe CX Coworker illustrates human augmentation, helping marketers manage campaigns with prompts and monitor their performance. SAP launched Joule Assistants across several business functions, including finance, human capital, supply chain, and customer experience. Other assistants, such as Appian AI Copilot, Atlassian Rovo, Cisco AI Assistant, Nutanix NIVA, and Snowflake CoWork, offer AI-first user experiences to assist different end-user types.

CIOs should demo these AI-first user experiences to glimpse the future of work.

Developers are already getting used to these experiences through code generators and vibe coding tools. Now, similar capabilities are being tailored across all business functions. CIOs should ramp up their change management programs to accelerate the adoption of these AI capabilities.

Solution providers are showcasing AI capabilities that can help CIOs reshape their businesses. But in Q2, there were only a few examples of how AI can help CIOs drive growth, evolve business models, or embed AI into customer-facing products. I expect to see a wave of further AI innovations that will go beyond productivity improvements and efficiencies and help CIOs pursue growth-driving digital transformation strategies.  

Sacolick travelled to conferences mentioned in this article as a guest of Adobe, Appian, Atlassian, Domo, Nutanix, SAP, and Snowflake. In addition, he was hired by Quickbase to speak at its conference.

Python’s rich ecosystem of data science tools is a big draw for users. The only downside of such a broad and deep collection is that sometimes the best tools can get overlooked.

Here’s a rundown of some of the best newer or less-known data science projects available for Python. Some, like Polars, are getting more attention but still deserve wider notice. Others, like ConnectorX, are hidden gems.

ConnectorX

Most data sits in a database somewhere, but computation typically happens outside of it. Getting data to and from the database for actual work can be a slowdown. ConnectorX loads data from databases into many common data-wrangling tools in Python, and it keeps things fast by minimizing the work required. Most of the data loading can be done in just a couple of lines of Python code and an SQL query.

Like Polars (which I’ll discuss shortly), ConnectorX uses a Rust library at its core. This allows for optimizations like being able to load from a data source in parallel with partitioning. Data in PostgreSQL, for instance, can be loaded this way by specifying a partition column.

Aside from PostgreSQL, ConnectorX also supports reading from MySQL/MariaDB, SQLite, Amazon Redshift, Microsoft SQL Server and Azure SQL, and Oracle. The results can be funneled into a Pandas or PyArrow DataFrame, or into Modin or Dask (via Pandas), or Polars (via PyArrow). General support for reading from ODBC is a work in progress.

DuckDB

Data science folks who use Python ought to be aware of SQLite—a small, but powerful and speedy relational database packaged with Python. Since it runs as an in-process library, rather than a separate application, SQLite is lightweight and responsive.

DuckDB is a little like someone answered the question, “What if we made SQLite for OLAP?” Like other OLAP database engines, it uses a columnar datastore and is optimized for long-running analytical query workloads. But DuckDB gives you all the things you expect from a conventional database, like ACID transactions. And there’s no separate software suite to configure; you can get it running in a Python environment with a single pip install duckdb command.

DuckDB can directly ingest data in CSV, JSON, or Parquet format, as well as a slew of other common data sources. The resulting databases can also be partitioned into multiple physical files for efficiency, based on keys (e.g., by year and month). Querying works like any other SQL-powered relational database, but with additional built-in features like the ability to take random samples of data or construct window functions.

DuckDB also has a small but useful collection of extensions, including full-text search, accelerated vector similarity search, Excel import/export, direct connections to SQLite and PostgreSQL, Parquet file export, and support for many common geospatial data formats and types.

Optimus

One of the least enviable jobs you can be stuck with is cleaning and preparing data for use in a DataFrame-centric project. Optimus is an all-in-one tool set for loading, exploring, cleansing, and writing data back out to a variety of data sources.

Optimus can use Pandas, Dask, CUDF (and Dask + CUDF), Vaex, or Spark as its underlying data engine. Data can be loaded in from and saved back out to Arrow, Parquet, Excel, a variety of common database sources, or flat-file formats like CSV and JSON.

The data manipulation API resembles Pandas, but adds .rows() and .cols() accessors to make it easy to do things like sort a DataFrame, filter by column values, alter data according to criteria, or narrow the range of operations based on some criteria. Optimus also comes bundled with processors for handling common real-world data types like email addresses and URLs.

One possible issue with Optimus is that it’s still under active development but its last official release was in 2020. This means it might not be as current as other components in your stack.

Polars

If you spend much time working with DataFrames and you’re frustrated by the performance limits of Pandas, reach for Polars. This DataFrame library for Python offers a convenient syntax similar to Pandas.

Unlike Pandas, though, Polars uses a library written in Rust that takes maximum advantage of your hardware out of the box. You don’t need to use special syntax to take advantage of performance-enhancing features like parallel processing or SIMD; it’s all automatic. Even simple operations like reading from a CSV file are faster. Rust developers can craft their own Polars extensions using pyo3.

Polars provides eager and lazy execution modes, so queries can be executed immediately or deferred until needed. It also provides a streaming API for processing queries incrementally. Streaming isn’t available yet for many functions, although Polars can always fall back to the in-memory engine for such operations if need be. You can also plot execution graphs for queries, streaming or otherwise, if you want to get an idea of what memory or CPU consumption is like for the query (via the external Graphviz library).

DVC

A major and pervasive issue with data science experiments is version control—not of the project’s code, but its data. DVC, short for Data Version Control, lets you attach version descriptors to datasets, check them into Git as you would the rest of your code, and keep versions of data and code consistent together.

DVC can track most any kind of dataset as long as they can be expressed as a file, whether kept in local storage or in a remote storage service like an Amazon S3 bucket. You can describe how data models are managed and used by way of a “pipeline,” which DVC’s documentation describes as being like “a Makefile system for machine learning projects.”

The use cases for DVC are intended to be more than just allowing data to be versioned alongside code. It also works as a fast data cache for remotely hosted data, a methodology for tracking experiments conducted with data, and a registry or catalog for machine learning models created with the data. Visual Studio Code users can integrate DVC workflows into the editor by way of the DVC VS Code extension.

Cleanlab

Good machine learning datasets are hard to come by, because it’s expensive and time-consuming to create clean, properly labeled data. Sometimes, though, you have no choice but to use data that’s raw and inconsistent. Cleanlab (as in, “cleans labels”) was made for this scenario.

Cleanlab uses existing, high-quality machine learning datasets to analyze lower-quality, unlabeled (or poorly labeled) datasets. You create a model based on the original dataset, use Cleanlab to figure out what needs to be improved in the original dataset, then re-train using your automatically cleaned and adjusted dataset to see the difference.

Cleanlab is data-model and data-framework agnostic, a powerful aspect of its design. It doesn’t matter if you’re running PyTorch, OpenAI, scikit-learn, or Tensorflow; Cleanlab can work with any classifier. It does, however, have specific workflows for common tasks like token classification, multi-labeling, regression, image segmentation and object detection, outlier detection, and so on. It’s worth perusing the example set to see for yourself how the process works and what results you can expect.

Snakemake

Data science workflows are hard to set up, and that’s even harder to do in a consistent, predictable way. Snakemake was created to automate the process, setting up data analysis workflows in ways that ensure everyone gets the same results. Many existing data science projects rely on Snakemake. The more moving parts you have in your data science workflow, the more likely you’ll benefit from automating that workflow with Snakemake.

Snakemake workflows resemble GNU Make workflows—you define the steps of the workflow with rules, which specify what they take in, what they put out, and what commands to execute to accomplish that. Workflow rules can be multithreaded (assuming that gives them any benefit), and configuration data can be piped in from JSON or YAML files. You can also define functions in your workflows to transform data used in rules, and write the actions taken at each step to logs.

Snakemake jobs are designed to be portable—they can be deployed on any Kubernetes-managed environment, or in specific cloud environments like Google Cloud Life Sciences or Tibanna on AWS. Workflows can be “frozen” to use a specific set of packages, and successfully executed workflows can have unit tests automatically generated and stored with them. And for long-term archiving, you can store the workflow as a tarball.

Generative AI is a kind of artificial intelligence that creates new content, including text, images, audio, and video, based on patterns it has learned from existing data.

Today’s generative models are typically built on foundation-model architectures such as large-language models (LLMs) and multimodal systems, enabling them to carry on conversations, answer questions, write stories, generate code, and produce images or videos from brief prompts.

Generative AI is different from discriminative AI, which draws distinctions between different kinds of input. Where discriminative AI answers questions like “Is this image of a rabbit or a lion?”, generative AI instead responds to prompts such as “Describe to me how a rabbit and lion look different from one another” or “Draw me a picture of a lion and a rabbit sitting next to each other” — and in both cases produces text or imagery that, while grounded in the AI’s training data, isn’t just a copy of something that already existed.

Just a few years ago, generative AI was once a novelty focused on chatbots and artistic image generation. Today, it has become a core enterprise technology, and powers everything from content creation and software development to customer support and analytics workflows. But with that power comes a new set of challenges — from model alignment and hallucination to governance and data-integration hurdles.

In this article, we’ll look at how generative AI works, explore how it has evolved into the foundation-model era, examine how to implement it effectively, and offer best practices for getting value out of it, today and in the future.

How does generative AI work?

For decades, early artificial-intelligence efforts often focused on rule-based systems or narrowly trained models that were built for one task at a time. While these efforts produced useful systems that could reason and solve human tasks, they were generally a far cry from sci-fi visions of thinking machines. Programs that could talk to people never seemed to get very far past the level of ELIZA, a “computer therapist” created at MIT in the mid 1960s; even Siri and Alexa after much fanfare were revealed to be fairly limited.

The big structural shift that gave birth to modern generative AI came with the concept of a transformer, first introduced in “Attention Is All You Need,” a 2017 paper from Google researchers.

Using a transformer architecture as a basis, you can build a system that derives meaning from analyzing long sequences of input tokens (words, sub-words, bytes) to understand how different tokens might be related to one another, then determines how likely any given token is to come next in a sequence, given the others. In AI lingo, we call these systems models. Because a model analyzes very large datasets and parameter counts, it can pick up on statistical patterns and knowledge implicitly embedded in the data.

This is all easier said than done. The process of adjusting a model’s internal parameters so it gets better at predicting the next token in sequences is called training. During training, the model repeatedly guesses the next token in a given sequence, compares its prediction to the actual one, measures the error, and updates its parameters to reduce that error across billions of examples. Over time, that process teaches the model the statistical relationships that will allow it to generate coherent language (or code, or images) later.

What is a foundation model?

You’ll often hear the word large used for transformer-based models of these types, like the LLMs we mentioned earlier. Large in this context refers to the large number of internal numerical values that the model adjusts during training to represent what it has learned, along with breadth and diversity of data used to train the model and the underlying compute resources powering this whole process.

This is in contrast with the narrow models of the earlier era of AI/ML, which werebuilt for one purpose and trained on a limited dataset. For instance, a spam filter may be very good at what it does, but it’s only trained on email data and all it can do is classify emails. Large models, by contrast, serve as what’s known as foundation models. They’re trained broadly on diverse data (text, code, images, or multimodal data) and then adapted or specialized for many downstream tasks.

These foundation models are the basis for most of the popular generative AI tools and services on the market today. They can be specialized in several ways:

• Fine-tuning: Giving a foundation model further training on a smaller, task-specific dataset
• Retrieval-augmented generation (RAG): Giving the model the ability to pull in external knowledge when asked a question
•  Prompt engineering: Tailoring a query so the model gives the sort of answers you’re looking for.

How do AI systems write computer code?

One of the surprising discoveries of the gen AI era was that in recent years was that foundation models trained on natural-language text can also, when fine-tuned with code examples, also write computer code — often better than many purpose-built systems. Still, it makes sense, when you think about it — after all, high-level computer languages are designed by humans and ultimately based on human language.

This 2023 InfoWorld article highlights how models like PaLM, LLaMA and other transformer-based systems fine-tuned on code repositories propelled this shift, but since AI giants like OpenAI have moved into this space. This all matters because code generation (or code-assisted productivity) has become a key enterprise use case of generative AI — perhaps the key use, given the industry’s enthusiastic adoption of it.

What are AI agents?

So far, we’ve been talking about chatbots, writing assistants, image-generation tools. They respond to prompts, output text or images, and then stop. A new category of tool called agentic AI goes further: it plans, executes, and in many cases learns as it works.

Because large models already understand language, code, and even structured data to some extent, they can be repurposed to generate not only descriptive text but operational instructions. For example: an agent might parse the intent “generate a sales-report”, then format internal calls like getData(salesDB, region=NA, period=lastQuarter), and then call an API, all by generating text that’s interpreted as instructions. The MCP framework standardizes the “language” of those instructions and the plug-points into tools and data so that the model doesn’t need bespoke integrations for each new workflow.

These kinds of autonomous agents have several enterprise use cases:

• Software automation: Agents that generate code, call unit tests, deploy builds, monitor logs and even roll back changes autonomously.
• Customer support: Instead of simply drafting responses, agents interact with CRM APIs, update ticket statuses, escalate issues, and trigger follow-up workflows.
• IT operations/AIOps: Agents monitor infrastructure, identify anomalies, open/close tickets, or auto-remediate based on defined rules and context from logs.
• Security: Agents may detect threats, initiate alerts, isolate compromised systems, or even attempt to manage threat containment — though this raises new risks.

How can you implement generative AI in the enterprise?

We’ve now touched on what generative AI can do. But how can you make it work reliably in your business. The difference between a pilot and full-scale deployment often comes down to systems, structure and governance as much as to models themselves. InfoWorld’s Matt Asay offers a deep dive into enterprise gen AI essentials, but here are some important points to keep in mind:

Choosing between API, open-source or custom fine-tuned models. One of the first major decisions for any enterprise project is: do you use a model via an API (e.g., from a vendor like OpenAI or Anthropic), deploy an open-source model internally, or build/fine-tune a custom model yourself? Each has trade-offs.

APIs offer speed and minimal setup, but may expose data, limit customization or accrue high cost — and will leave you at the mercy of your vendor. Open source allows internal control and may ease fine-tuning, but requires infrastructure, expertise, and support. Custom fine-tuning gives you the tightest alignment to your use-case, but lengthens time to value and increases risk.

Governance, data privacy and compliance. Deploying generative AI in an enterprise setting raises new governance, privacy and regulatory issues. For example: Who owns the data that’s ingested? How is proprietary data protected if you call a third-party API? What traceability exists for model outputs—a huge question for regulated industries? One useful framework is covered in “A GRC framework for securing generative AI” Data governance must adapt for the new era,  and new frameworks are evolving to help.

Human-in-the-loop review. Even the best models make mistakes and cannot simply be put on autopilot. You need a human-in-the-loop (HITL) process: real people need to review outputs, validate for bias, approve high-stakes content, and tune prompts or models based on feedback. Incorporating HITL checkpoints helps mitigate risk and improve overall quality.

Integration with existing systems and RAG pipelines. Retrieval-augmented generation, which we touched on earlier, connects foundation models into business workflows, systems, and enterprise data stores. RAG can bind LLMs to your organization’s internal knowledge bases, thereby reducing hallucinations (which we’ll discuss in a moment) and increasing the relevance of gen AI output.

What causes AI hallucinations?

Probably the biggest limitation of generative AI is what those in the industry call hallucinations, which is a perhaps misleading term for output that is, by the standards of humans who use it, false or incorrect.  

Every generative AI system, no matter how advanced, is built around prediction. Remember, a model doesn’t truly know facts—it looks at a series of tokens, then calculates, based on analysis of its underlying training data, what token is most likely to come next. This is what makes the output fluent and human-like, but if its prediction is wrong, that will be perceived as a hallucination.

Because the model doesn’t distinguish between something that’s known to be true and something likely to follow on from the input text it’s been given, hallucinations are a direct side effect of the statistical process that powers generative AI. And don’t forget that we’re often pushing AI models to come up with answers to questions that we, who also have access to that data, can’t answer ourselves.

In text models, hallucinations might mean inventing quotes, fabricating references, or misrepresenting a technical process. In code or data analysis, it can produce syntactically correct but logically wrong results. Even RAG pipelines, which provide real data context to models, only reduce hallucination—they don’t eliminate it. Enterprises using generative AI need review layers, validation pipelines, and human oversight to prevent these failures from spreading into production systems.

What are some other problems with generative AI?

Generative AI has proven to be such a disruptive technology that’s stoking near-apocalyptic fears that it will result in a superintelligence that will enslave or destroy humanity. Meanwhile, in the present day, increasingly troubling reports of so-called AI psychosis are emerging, where people have mental health episodes triggered by the uncanny and sometimes sycophantic ways chatbots affirm whatever you talk to them about and try to keep the conversation going.

Compared to such existential questions, the following business-related problems may seem petty. But they’re real issues for enterprises considering investing in AI tools.

• Data leakage and regulatory risk. When a model is fine-tuned or prompted with sensitive information, that data may be memorized and unintentionally reproduced. Using third-party APIs without strict controls can expose proprietary or personally identifiable information (PII). Regulatory frameworks like GDPR and HIPAA require explicit governance around where training data resides and how inference results are stored.
• Prompt injection occurs when an attacker manipulates a model’s instructions—embedding hidden directives or malicious payloads in user input or external content the model reads. This can override safety rules, expose internal data, or execute unintended actions in agentic systems. Guardrails that sanitize inputs, restrict tool-calling permissions, and validate outputs are becoming essential.
• Copyright and content ownership. Many foundation models are trained on data scraped from the public internet, creating disputes over copyright and data provenance. Enterprises using generated output commercially need to confirm usage rights and review indemnity terms from vendors.
• Unrealistic productivity expectations. Finally, organizations sometimes expect generative AI to deliver instant productivity gains. The reality, it turns out, is more mixed. Enterprise adoption requires infrastructure, governance, retraining, and cultural change. The models accelerate work once properly integrated, but they don’t automatically replace human judgment or oversight.

The current generation of enterprise AI systems includes several layers of defense against these risks:

• Guardrails that constrain model behavior and filter unsafe outputs.
• Model validation frameworks that measure factual accuracy and consistency before deployment.
• Policy layers that enforce compliance rules, redact sensitive data, and log model actions.

These safeguards reduce—but don’t remove—the inherent uncertainty that defines generative AI.

GenAI: essential for the enterprise

Generative AI has evolved from a novelty into a core layer of enterprise technology. Foundation models and agentic systems now power automation, analytics, and creative workflows — but they remain fundamentally probabilistic tools. Their strength lies in scale and adaptability, not perfect understanding.

For organizations, success depends less on chasing model breakthroughs than on integrating these systems responsibly: building guardrails, maintaining oversight, and aligning them with real business needs. Used wisely, generative AI can amplify human capability rather than replace it.

Node.js is a popular and versatile cross-platform JavaScript runtime environment. Node was the first runtime to allow developers to run JavaScript outside the browser, opening a new world of possibilities in server-side JavaScript. Its ease of use, massive ecosystem and performance characteristics have continued to secure its place as one of the most important technologies of the modern web.

Anytime you need to run JavaScript on the server—be it for a systems utility, a REST API, data processing, or anything else—Node is an excellent choice. There are newer runtimes, namely Deno and Bun, but Node remains the standard for server-side JavaScript.

Also see: 10 JavaScript concepts you need to succeed with Node.

Getting started with Node

If you haven’t already experienced Node, this article will introduce you. We’ll step through installing Node and the NPM package manager, spinning up a simple web server, and using the Node cluster module to take advantage of multiple CPU cores.

We’ll also look at using the NPM package manager to install additional Node modules and other JavaScript packages. And we’ll dip a toe into using a Node framework, in this case the ubiquitous Express server, to create more feature-rich and flexible Node.js servers. Let’s get started!

Installing Node and NPM

There are a few ways to install Node, including the installer that Node itself provides, but the recommended way is with a version manager. The most common version manager is NVM. This makes it easy to install Node and change versions when you need to. (There is also a Microsoft Windows-specific version called nvm-windows.)

NVM can be installed with an installer or using a CLI. In the following example, we use curl:

$ curl -o- https://raw.githubusercontent.com/nvm-sh/nvm/v0.40.3/install.sh | bash

Once you have NVM installed, installing the most recent version of Node is simple:

$ nvm install latest

The install latest command makes the latest version available. Mine is Node 24.9.0, so I activate it with:

$ nvm use 24.9.0

Anytime you need to install another version of Node, you can use nvm install and nvm use to switch between them.

You should now see Node available at your command prompt:

$ node -v

v24.9.0

When you install Node this way, the Node package manager (NPM) is also installed:

$ npm -v

11.6.0

Note that using NVM also avoids potential permissions issues with NPM packages when using the installer.

A simple web server in Node

To start simply, we can use an example from the Node homepage. Copy the Synopsis example code as directed there and paste it into your code editor, then save it as example.js:

const http = require('node:http');

const hostname = '127.0.0.1';
const port = 3000;

const server = http.createServer((req, res) => {
  res.statusCode = 200;
  res.setHeader('Content-Type', 'text/plain');
  res.end('Hello, InfoWorld!\n');
});

server.listen(port, hostname, () => {
  console.log(`Server running at http://${hostname}:${port}/`);
});

Open a shell in the directory where you saved the file, and run the file from your command line:

$ node example.js

Server running at http://127.0.0.1:3000/

You can now go to the browser and check it out at 127.0.0:3000, and you should see a simple greeting. Back at the terminal, press Control-C to stop the running server.

Before we go further, let’s pull apart the code.

Creating a simple HTTP server with Node

We start with the command:

const http = require(‘http’);

This is how you include a module in your code, in this case, the standard http module. (The http module ships with Node, so you don’t have to add it as a dependency.) This module provides the createServer and listen functions we’ll use later on.

You might have noted that this example used a CommonJS import. While older, this style of import is still very common in Node programs as well as some documentation. However, it’s gradually being phased out in favor of ES Modules (ESM), the standardized module system introduced in ECMAScript 2015. An ESM import would look like this:

import http from 'http';

After we import the http module, we define a couple of values we need (hostname and port):

const hostname = '127.0.0.1';

const port = 3000;

Next, we create the server:

const server = http.createServer((req, res) => {
  res.statusCode = 200;
  res.setHeader(‘Content-Type’, ‘text/plain’);
  res.end(‘Hello World\n’);
});

The creatServer command accepts a callback function, which we define using the fat arrow notation. The callback function passes two arguments, the request (req) and response (res) objects needed to handle HTTP requests. The req argument contains the incoming HTTP request, which in this case is ignored. The res.end method sets the response data to ‘Hello InfoWorld\n’ and tells the server that it is done creating the response.

Next, we have:

server.listen(port, hostname, () => {
  console.log(`Server running at http://${hostname}:${port}/`);
});

The server.listen function accepts three arguments. The first two are the port and hostname, and the third is a callback that is executed when the server is ready (in this case, it prints a message to the console).

Having all the event handlers defined as callbacks is one of the most subtle and powerful parts of Node. It’s key to Node’s asynchronous non-blocking architecture.

Node.js runs on an event loop, which always reverts to handling events when not otherwise engaged. It’s like a busy order-taker continually picking up orders and then updating the order-maker with their order. We receive updates via the callbacks.

A multi-process web server with Node

Node’s asynchronous, non-blocking nature makes it good at handling many parallel requests, but it’s not truly concurrent by default. There are a few ways to make a Node application use multiple threads for true concurrency. One of the simplest is to use the PM2 project, which lets you run the same Node application in many processes.

By launching each application instance in its own process, the operating system can make use of multiple cores on the machine. This is not usually a concern at first, but it’s a key performance consideration to bear in mind.

You can install PM2 globally like so:

$ npm install -g pm2

For our example, we want to make it obvious that the different processes are handling requests. We can achieve that goal with a small change to the server:

res.end(`Hello, InfoWorld! Handled by ${process.pid}`);

The process.pid field is a built-in environment variable, providing a unique ID for the currently running process in Node. Once PM2 is installed and the app is updated, we can run it like so:

$ pm2 start example.js -i max

That should launch several instances of the same program, as shown here:

Then, if you open multiple windows, you can see the unique ID of each instance:

An Express web server with Node

For our final example, we’ll look at setting up an Express web server in Node. This time we’ll use NPM to download Express and its dependencies. NPM is one of the greatest storehouses of software on the planet, with literally millions of libraries available. Knowing how to use it is essential for working with Node.

NPM works just like other package managers you may have used, letting you define and install dependencies in a structured way. To install Express, go to your project directory and type:

$ npm install express

Node should respond with something like: added 68 packages in 5s.

You will notice several directories have been added to a /node_modules directory. Those are all the dependencies needed for Express. You usually don’t have to interact with node_modules yourself, but it’s good to know that’s where things are saved.

Now look at the package.json file, which will have something like this in it:

{
  "dependencies": {
	"express": "^5.1.0"
  }
}

This is how dependencies are defined in NPM. It says the application needs the express dependency at version 5.1.0 (or greater).

Setting up the Express server in Node

Express is one of the most-deployed pieces of software on the Internet. It can be a minimalist server framework for Node that handles all the essentials of HTTP, and it’s also expandable using “middleware” plugins.

Since we’ve already installed Express, we can jump right into defining a server. Open the example.js file we used previously and replace the contents with this simple Express server:

import express from 'express';

const app = express();
const port = 3000;

app.get('/', (req, res) => {
  res.send('Hello, InfoWorld!');
});

app.listen(port, () => {
  console.log(`Express server at http://localhost:${port}`);
});

This program does the same thing as our earlier http module version. The most important change is that we’ve added routing. Express makes it easy for us to associate a URL path, like the root path (‘/’), with the handler function.

If we wanted to add another path, it could look like this:

app.get('/about', (req, res) => {
  res.send('This is the About page.');
});

Once we have the basic web server set up with one or more paths, we’ll probably need to create a few API endpoints that respond with JSON. Here’s an example of a route that returns a JSON object:

app.get('/api/user', (req, res) => {
  res.json({
	id: 1,
	name: 'John Doe',
	role: 'Admin'
  });
});

That’s a simple example, but it gives you a taste of working with Express in Node.

Conclusion

In this article you’ve seen how to install Node and NPM and how to set up both simple and more advanced web servers in Node. Although we’ve only touched on the basics, these examples demonstrate many elements that are required for all Node applications, including the ability to import modules.

Whenever you need a package to do something in Node, you will more than likely find it available on NPM. Visit the official site and use the search feature to find what you need. For more information about a package, you can use the npms.io tool. Keep in mind that a project’s health depends on its weekly download metric (visible on NPM for the package itself). You can also check a project’s GitHub page to see how many stars it has and how many times it’s been forked; both are good measures of success and stability. Another important metric is how recently and frequently the project is updated and maintained. That information is also visible on a project’s GitHub Insights page.

Node.js is one of the most popular server-side platforms, especially for web applications. It gives you non-blocking JavaScript without a browser, plus an enormous ecosystem. That ecosystem is one of Node’s chief strengths, making it a go-to option for server development.

This article is a quick tour of the most popular web frameworks for server development on Node.js. We’ll look at minimalist tools like Express.js, batteries-included frameworks like Nest.js, and full-stack frameworks like Next.js. You’ll get an overview of the frameworks and a taste of what it’s like to write a simple server application in each one.

Minimalist web frameworks

When it comes to Node web frameworks, minimalist doesn’t mean limited. Instead, these frameworks provide the essential features required to do the job for which they are intended. The frameworks in this list also tend to be highly extensible, so you can customize them as needed. With minimalist frameworks, pluggable extensibility is the name of the game.

Express.js

At over 47 million weekly downloads on npm, Express is one of the most-installed software packages of all time—and for good reason. Express gives you basic web endpoint routing and request-and-response handling inside an extensible framework that is easy to understand. Most other frameworks in this category have adopted the basic style of describing a route from Express. This framework is the obvious choice when you simply need to create some routes for HTTP, and you don’t mind a DIY approach for anything extra.

Despite its simplicity, Express is fully-featured when it comes to things like route parameters and request handling. Here is a simple Express endpoint that returns a dog breed based on an ID:

import express from 'express';

const app = express();
const port = 3000;

// In-memory array of dog breeds
const dogBreeds = [
  "Shih Tzu",
  "Great Pyrenees",
  "Tibetan Mastiff",
  "Australian Shepherd"
];
app.get('/dogs/:id', (req, res) => {
  // Convert the id from a string to an integer
  const id = parseInt(req.params.id, 10);

  // Check if the id is a valid number and within the array bounds
  if (id >= 0 && id  {
  console.log(`Server running at http://localhost:${port}`);
});

You can easily see how the route is defined here: a string representation of a URL, followed by a function that receives a request and response object. The process of creating the server and listening on a port is simple.

If you are coming from a framework like Next, the biggest thing you might notice about Express is that it lacks a file-system based router. On the other hand, it offers a huge range of middleware plugins to help with essential functions like security.

Koa

Koa was created by the original creators of Espress, who took the lessons learned from that project and used them for a fresh take on the JavaScript server. Koa’s focus is providing a minimalist core engine. It uses async/await functions for middleware rather than chaining with next() calls. This can give you a cleaner server, especially when there are many plugins. It also makes the error handling less clunky for middleware.

Koa also differs from Express by exposing a unified context object instead of separate request and response objects, which makes for a somewhat less cluttered API. Here is how Koa manages the same route we created in Express:

router.get('/dogs/:id', (ctx) => {
  const id = parseInt(ctx.params.id, 10);

  if (id >= 0 && id < dogBreeds.length) {
    ctx.status = 200;
    ctx.body = { breed: dogBreeds[id] };
  } else {
    ctx.status = 404;
    ctx.body = { error: 'Dog breed not found' };
  }
});

The only real difference is the combined context object.

Koa’s middleware mechanism is also worth a look. Here’s a simple logging plugin in Koa:

const logger = async (ctx, next) => {
  await next(); // This passes control to the router
  console.log(`${ctx.method} ${ctx.url} - ${ctx.status}`);
};

// Use the logger middleware for all requests
app.use(logger);	

Fastify

Fastify lets you define schemas for your APIs. This is an up-front, formal mechanism for describing what the server supports:

const schema = {
  params: {
    type: 'object',
    properties: {
      id: { type: 'integer' }
    }
  },
  response: {
    200: {
      type: 'object',
      properties: {
        breed: { type: 'string' }
      }
    },
    404: {
      type: 'object',
      properties: {
        error: { type: 'string' }
      }
    }
  }
};

fastify.get('/dogs/:id', { schema }, (request, reply) => {
  const id = request.params.id;

  if (id >= 0 && id  {
  if (err) {
    fastify.log.error(err);
    process.exit(1);
  }
  console.log(`Server running at ${address}`);
});

From this example, you can see the actual endpoint definition is similar to Express and Koa, but we define a schema for the API. The schema is not strictly necessary; it is possible to define endpoints without it. In that case, Fastify behaves much like Express, but with superior performance.

Hono

Hono emphasizes simplicity. You can define a server and endpoint with as little as:

const app = new Hono()
app.get('/', (c) => c.text('Hello, Infoworld!'))  

And here’s how our dog breed example looks:

app.get('/dogs/:id', (c) => {
  // Get the id parameter from the request URL
  const id = parseInt(c.req.param('id'), 10);

  // Check if the id is a valid number and within the array bounds
  if (id >= 0 && id < dogBreeds.length) {
    // Return a JSON response with a 200 OK status (default)
    return c.json({ breed: dogBreeds[id] });
  } else {
    // Set status to 404 and return a JSON error message
    c.status(404);
    return c.json({ error: 'Dog breed not found' });
  }
});

As you can see, Hono provides a unified context object, similar to Koa.

Nitro.js

Nitro is the back end for several full-stack frameworks, including Nuxt.js. As part of the UnJS ecosystem, Nitro goes further than Express in providing cloud-native tooling support. It includes a universal storage adapter and deployment support for serverless and cloud deployment targets.

Also see: Intro to Nitro: The server engine built for modern JavaScript.

Like Next.js, Nitro uses filesystem-based routing, so our Dog Finder API would exist at the following filepath:

/api/dogs/:id

The handler might look like this:

export default defineEventHandler((event) => {
  // Get the dynamic parameter from the event context
  const { id } = getRouterParams(event);
  const parsedId = parseInt(id, 10);

  // Check if the id is a valid number and within the array bounds
  if (parsedId >= 0 && parsedId < dogBreeds.length) {
    // Nitro handles JSON serialization
    return { breed: dogBreeds[parsedId] };
  } else {
    setResponseStatus(event, 404);
    return { error: 'Dog breed not found' };
  }
});

Nitro inhabits the middle ground between a pure tool like Express and a full-blown stack, which is why full-stack front ends often use Nitro on the back end.

Batteries-included frameworks

Although Express and other minimalist frameworks set the standard for simplicity, more opinionated frameworks can be useful if you want additional features out of the box.

Nest.js

Nest is a progressive framework built with TypeScript from the ground up. Nest is actually a layer on top of Express (or Fastify), with additional services. It is inspired by Angular and incorporates the kind of architectural support found there. In particular, it includes dependency injection. Nest also uses annotated controllers for endpoints.

Also see: Intro to Nest.js: Server-side JavaScript development on Node.

Here is an example of injecting a dog finder provider into a controller:

// The provider:
import { Injectable, NotFoundException } from '@nestjs/common';

// The @Injectable() decorator marks this class as a provider.
@Injectable()
export class DogsService {
  private readonly dogBreeds = [
    "Shih Tzu",
    "Great Pyrenees",
    "Tibetan Mastiff",
    "Australian Shepherd"
  ];

  findOne(id: number) {
    if (id >= 0 && id < this.dogBreeds.length) {
      return { breed: this.dogBreeds[id] };
    }
    // NestJS has built-in HTTP exception classes for common errors.
    throw new NotFoundException('Dog breed not found');
  }
}

// The controller

import { Controller, Get, Param, ParseIntPipe } from '@nestjs/common';
import { DogsService } from './dogs.service';

@Controller('dogs')
export class DogsController {
  // NestJS injects the DogsService through the constructor.
  // The 'private readonly' syntax is a TypeScript shorthand
  // to both declare and initialize the dogsService member.
  constructor(private readonly dogsService: DogsService) {}

  @Get(':id')
  findOneDog(@Param('id', ParseIntPipe) id: number) {
    // We can now use the service's methods. The ParseIntPipe
    // automatically converts the string URL parameter to a number.
    return this.dogsService.findOne(id);
  }
}

This style is typical of dependency injection frameworks like Angular, as well as Spring. It allows you to declare components as injectable, then consume them anywhere you need them.

In Nest, we’d just add these as modules to make them live.

Adonis.js

Like Nest, Adonis provides a controller layer that you wire together with routes. Adonis is inspired by the model-view-controller (MVC) pattern, so it also includes a layer for modelling data and accessing stores via an ORM. Finally, it provides a validator layer for ensuring data meets requirements.

Routes in Adonis are very simple:

Route.get('/dogs/:id', [DogsController, 'show'])

In this case, DogsController would be the handler for the route, and might look something like:

import type { HttpContextContract } from '@ioc:Adonis/Core/HttpContext'  // Note, ioc means inversion of control, similar to dependency injection

export default class DogsController {
  // The 'show' method handles the logic for the route
  public async show({ params, response }: HttpContextContract) {
    const id = Number(params.id);

    // Check if the id is a valid number and within the array bounds
    if (!isNaN(id) && id >= 0 && id < this.dogBreeds.length) {
      // Use the response object to send a 200 OK JSON response
      return response.ok({ breed: this.dogBreeds[id] });
    } else {
      // Send a 404 Not Found response
      return response.notFound({ error: 'Dog breed not found' });
    }
  }
}

Of course, in a real application, we could define a model layer to handle the actual data access.

Sails

Sails is another MVC-style framework. It is one of the original one-stop-shopping frameworks for Node and includes an ORM layer (Waterline), API generation (Blueprints), and realtime support, including WebSockets.

Sails strives for conventional operation. For example, here’s how you might define a simple model for dogs:

/**
 * Dog.js
 *
 * @description :: A model definition represents a database table/collection.
 * @docs        :: https://sailsjs.com/docs/concepts/models
 */
module.exports = {
  attributes: {
    breed: { type: 'string', required: true },
  },
};

If you run this in Sails, the framework will generate default routes and wire up a NoSQL or SQL datastore based on your configuration. Sails also provides the option to override these defaults and add in your own custom logic.

Full-stack frameworks

Also known as meta-frameworks, these tools combine a front-end framework with a solid back end and various CLI niceties like build chains.

Next.js

Next is a React-based framework built by Vercel. It is largely responsible for the huge growth in popularity of these types of frameworks. Next was the first framework to bring together back-end API definitions with the front end that consumes them. It also introduced file-system routing. In Next and other full-stack frameworks, you get both parts of your stack in one place and you can run them together during development.

In Next, we could define a route at pages/api/dogs/[id].js like so:

export default function handler(req, res) {
  // `req.query.id` comes from the dynamic filename [id].js
  const { id } = req.query;
  const parsedId = parseInt(id, 10);

  if (parsedId >= 0 && parsedId < dogBreeds.length) {
    // If the ID is valid, return the data
    res.status(200).json({ breed: dogBreeds[parsedId] });
  } else {
    // Otherwise, return a 404 error
    res.status(404).json({ error: 'Dog breed not found' });
  }
}

We’d then define the UI component to interact with this route at pages/dogs/[id].js:

import React from 'react';

// This is the React component that renders the page.
// It receives the `dog` object as a prop from getServerSideProps.
function DogPage({ dog }) {
  // Handle the case where the dog wasn't found
  if (!dog) {
    return 
Dog Breed Not Found
;
  }

  return (
    

      
Dog Breed Profile
      
Breed Name: {dog.breed}
    
  );
}

// This function runs on the server before the page is sent to the browser.
export async function getServerSideProps(context) {
  const { id } = context.params; // Get the ID from the URL

  // Fetch data from our own API route on the server.
  const res = await fetch(`http://localhost:3000/api/dogs/${id}`);
  
  // If the fetch was successful, parse the JSON.
  const dog = res.ok ? await res.json() : null;

  // Pass the fetched data to the DogPage component as props.
  return {
    props: {
      dog,
    },
  };
}

export default DogPage;

Nuxt.js

Nuxt is the same idea as Next, but applied to the Vue front end. The basic pattern is the same, though. First, we’d define a back-end route:

// server/api/dogs/[id].js

// defineEventHandler is Nuxt's helper for creating API handlers.
export default defineEventHandler((event) => {
  // Nuxt automatically parses route parameters.
  const id = getRouterParam(event, 'id');
  const parsedId = parseInt(id, 10);

  if (parsedId >= 0 && parsedId < dogBreeds.length) {
    return { breed: dogBreeds[parsedId] };
  } else {
    // Helper to set the status code and return an error.
    setResponseStatus(event, 404);
    return { error: 'Dog breed not found' };
  }
});

Then, we’d create the UI file in Vue:

// pages/dogs/[id].vue


  

    

      Loading...
    
    

      
{{ error.data.error }}
    
    

      
Dog Breed Profile
      
Breed Name: {{ dog.breed }}
    
  

SvelteKit

SvelteKit is the full-stack framework for the Svelte front end. It’s similar to Next and Nuxt, with the main difference being the front-end technology.

In SvelteKit, a back-end route looks like so:

// src/routes/api/dogs/[id]/+server.js

import { json, error } from '@sveltejs/kit';

// This is our data source for the example.
const dogBreeds = [
  "Shih Tzu",
  "Australian Cattle Dog",
  "Great Pyrenees",
  "Tibetan Mastiff",
];

/** @type {import('./$types').RequestHandler} */
export function GET({ params }) {
  // The 'id' comes from the [id] directory name.
  const id = parseInt(params.id, 10);

  if (id >= 0 && id < dogBreeds.length) {
    // The json() helper creates a valid JSON response.
    return json({ breed: dogBreeds[id] });
  }

  // The error() helper is the idiomatic way to return HTTP errors.
  throw error(404, 'Dog breed not found');
}

SvelteKit usually splits the UI into two components. The first component is for loading the data (which can then be run on the server):

// src/routes/dogs/[id]/+page.js

import { error } from '@sveltejs/kit';

/** @type {import('./$types').PageLoad} */
export async function load({ params, fetch }) {
  // Use the SvelteKit-provided `fetch` to call our API endpoint.
  const response = await fetch(`/api/dogs/${params.id}`);

  if (response.ok) {
    const dog = await response.json();
    // The object returned here is passed as the 'data' prop to the page.
    return {
      dog: dog
    };
  }

  // If the API returns an error, forward it to the user.
  throw error(response.status, 'Dog breed not found');
}

The second component is the UI:

// src/routes/dogs/[id]/+page.svelte




  
Dog Breed Profile
  
Breed Name: {data.dog.breed}

Conclusion

The Node.js ecosystem has moved beyond the “default-to-Express” days. Now, it is worth your time to look for a framework that fits your specific situation.

If you are building microservices or high-performance APIs, where every millisecond counts, you owe it to yourself to look at minimalist frameworks like Fastify or Hono. This class of frameworks gives you raw speed and total control without requiring decisions about infrastructure.

If you are building an enterprise monolith or working with a big team, batteries-included frameworks like Nest or Adonis offer useful structure. The complexity of the initial setup buys you long-term maintainability and makes the codebase more standardized for new developers.

Finally, if your project is a content-rich web application, full-stack meta-frameworks like Next, Nuxt, and SvelteKit offer the best developer experience and the perfect profile of tools.

It’s also worth noting that, while Node remains the standard server-side runtime, alternatives Deno and Bun have both made a name for themselves. Deno has great heritage, is open source with a strong security focus, and has its own framework, Deno Fresh. Bun is respected for its ultra-fast startup and integrated tooling.

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.

For several decades now, the most innovative software has always emerged from the world of open source software. It’s no different with machine learning and large language models. If anything, the open source ecosystem has grown richer and more complex, because now there are open source models to complement the open source code.

For this article, we’ve pulled together some of the most intriguing and useful projects for AI and machine learning. Many of these are foundation projects, nurturing their own niche ecology of open source plugins and extensions. Once you’ve started with the basic project, you can keep adding more parts.

Most of these projects offer demonstration code, so you can start up a running version that already tackles a basic task. Additionally, the companies that build and maintain these projects often sell a service alongside them. In some cases, they’ll deploy the code for you and save you the hassle of keeping it running. In others, they’ll sell custom add-ons and modifications. The code itself is still open, so there’s no vendor lock in. The services simply make it easier to adopt the code by paying someone to help.

Here are 16 open source projects that developers can use to unlock the potential in machine learning and large language models of any size—from small to large, and even extra large.

Agent Skills

AI coding agents are often used to tackle standard tasks like writing React components or reviewing parts of the user interface. If you are writing a coding agent, it makes sense to use vetted solutions that are focused on the task at hand. Agent Skills are pre-coded tools that your AI can deploy as needed. The result is a focused set of vetted operations capable of producing refined, useful code that stays within standard guidelines. License: MIT.

Awesome LLM Apps

If you are looking for good examples of agentic coding, see the Awesome LLM Apps collection. Currently, the project hosts several dozen applications that leverage some combination of RAG databases and LLMs. Some are simple, like a meme generator, while others handle deeper research like the Journalist agent. The most complex examples deploy multi-agent teams to converge upon an answer. Every application comes with working examples for experimentation, so you can learn from what’s been successful in the past. Altogether, the apps in this collection are great inspiration for your own projects. License: Apache 2.0.

Bifrost

If your application requires access to an LLM service, and you don’t have a particular one in mind, check out Bifrost. A fast, unified gateway to more than 15 LLM providers, this OpenAI-compatible API quickly abstracts away the differences between models, including all the major ones. It includes essential features like governance, caching, budget management, load balancing, and it has guardrails to catch problems before they are sent out to service providers, who will just bill you for the time. With dozens of great LLM providers constantly announcing new and better models, why limit yourself? License: Apache 2.0.

Claude Code

If the popularity of AI coding assistants tells us anything, it’s that all developers—and not just the ones building AI apps—appreciate a little help writing and reviewing their code. Claude Code is that pair programmer. Trained on all the major programming languages, Claude Code can help you write code that is better, faster, and cleaner. It digests a codebase and then starts doing your bidding, while also making useful suggestions. Natural language commands plus some vague hand waving are all the Anthropic LLM needs to refactor, document, or even add new features to your existing code. License: Anthropic’s Commercial TOS.

Clawdbot

Many of the tools in this list help developers create code for other people. Clawdbot is the AI assistant for you, the person writing the code. It integrates with your desktop to control built-in tools like the camera and large applications like the browser. A multi-channel inbox accepts your commands through more than a dozen different communication channels including WhatsApp, Telegram, Slack, and Discord. A cron job adds timing. It’s the ultimate assistant for you, the ruler of your data. If AI exists to make our lives easier, why not start by organizing the applications on your desktop? License: MIT.

Dify

For projects that require more than just one call to an LLM, Dify could be the solution you’ve been looking for. Essentially a development environment for building complex agentic workflows, Dify stitches together LLMs, RAG databases, and other sources. It then monitors how they perform under different prompts and parameters and puts it all together in a handy dashboard, so you can iterate on the results. Developing agentic AI requires rapid experimentation, and Dify provides the environment for those experiments. License: Modified version of Apache 2.0 to exclude some commercial uses.

Eigent

The best way to explore the power and limitations of an agentic workflow is to deploy it yourself on your own machine, where it can solve your own problems. Eigent delivers a workforce of specialized agents for handling tasks like writing code, searching the web, and creating documents. You just wave your hands and issue instructions, and Eigent’s LLMs do their best to follow through. Many startups brag about eating their own dogfood. Eigent puts that concept on a platter, making it easy for AI developers to experience directly the abilities and failings of the LLMs they’re building. License: Apache 2.0.

Headroom

Programmers often think like packrats. If the data is good, why not pack in some more? This is a challenge for code that uses an LLM because these services charge by the token, and they also have a limited context window. Headroom tackles this issue with agile compression algorithms that trim away the excess, especially the extra labels and punctuation found in common formats like JSON. A big part of designing working AI applications is cost engineering, and saving tokens means saving money. License: Apache 2.0.

Hugging Face Transformers

When it comes to starting up a brand-new machine learning project, Hugging Face Transformers is one of the best foundations available. Transformers offers a standard format for defining how the model interacts with the world, which makes it easy to drop a new model into your working infrastructure for training or deployment. This means your model will interact nicely with all the already available tools and infrastructure, whether for text, vision, audio, video, or all of the above. Fitting into a standard paradigm makes it much easier to leverage your existing tools while focusing on the cutting edge of your research. License: Apache 2.0.

LangChain

For agentic AI solutions that require endless iteration, LangChain is a way to organize the effort. It harnesses the work of a large collection of models and makes it easier for humans to inspect and curate the answers. When the task requires deeper thinking and planning, LangChain makes it easy to work with agents that can leverage multiple models to converge upon a solution. LangChain’s architecture includes a framework (LangGraph) for organizing easily customizable workflows with long-term memory, and a tool (LangSmith) for evaluating and improving performance. Its Deep Agents library provides teams of sub-agents, which organize problems into subsets then plan and work toward solutions. It is a proven, flexible test bed for agentic experimentation and production deployment. License: MIT.

LlamaIndex

Many of the early applications for LLMs are sorting through large collections of semi-structured data and providing users with useful answers to their questions. One of the fastest ways to customize a standard LLM with private data is to use LlamaIndex to ingest and index the data. This off-the-shelf tool provides data connectors that you can use to unpack and organize a large collection of documents, tables, and other data, often with just a few lines of code. The layers underneath can be tweaked or extended as the job requires, and LlamaIndex works with many of the data formats common in enterprises. License: MIT.

Ollama

For anyone experimenting with LLMs on their laptop, Ollama is one of the simplest ways to download one or more of them and get started. Once it’s installed, your command line becomes a small version of the classic ChatGPT interface, but with the ability to pull a huge collection of models from a growing library of open source options. Just enter: ollama run and the model is ready to go. Some developers are using it as a back-end server for LLM results. The tool provides a stable, trustworthy interface to LLMs, something that once required quite a bit of engineering and fussing. The server simplifies all this work so you can tackle higher level chores with many of the most popular open source LLMs at your fingertips. License: MIT.

OpenWebUI

One of the fastest ways to put up a website with a chat interface and a dedicated RAG database is to spin up an instance of OpenWebUI. This project knits together a feature-rich front end with an open back end, so that starting up a customizable chat interface only requires pulling a few Docker containers. The project, though, is just a beginning, because it offers the opportunity to add plugins and extensions to enhance the data at each stage. Practically every part of the chain from prompt to answer can be tweaked, replaced, or improved. While some teams might be happy to set it up and be done, the advantages come from adding your own code. The project isn’t just open source itself, but a constellation of hundreds of little bits of contributed code and ancillary projects that can be very helpful. Being able to customize the pipeline and leverage the MCP protocol supports the delivery of precision solutions. License: Modified BSD designed to restrict removing OpenWebUI branding without an enterprise license.

Sim

The drag-and-drop canvas for Sim is meant to make it easier to experiment with agentic workflows. The tool handles the details of interacting with the various LLMs and vector databases; you just decide how to fit them together. Interfaces like Sim make the agentic experience accessible to everyone on your team, even those who don’t know how to write code. License: Apache 2.0.

Sloth

One of the most straightforward ways to leverage the power of foundational LLMs is to start with an open source model and fine-tune it with your own data. Unsloth does this, often faster than other solutions do. Most major open source models can be transformed with reinforcement learning. Unsloth is designed to work with most of the standard precisions and some of the largest context windows. The best answers won’t always come directly from RAG databases. Sometimes, adjusting the models is the best solution. License: Apache 2.0.

vLLM

One of the best ways to turn an LLM into a useful service for the rest of your code is to start it up with vLLM. The tool loads many of the available open source models from repositories like Hugging Face and then orchestrates the data flows so they keep running. That means batching the incoming prompts and managing the pipelines so the model will be a continual source of fast answers. It supports not just the CUDA architecture but also AMD CPUs and GPUs, Intel CPUs and GPUs, PowerPC CPUs, Arm CPUs, and TPUs. It’s one thing to experiment with lots of models on a laptop. It’s something else entirely to deploy the model in a production environment. vLLM handles many of the endless chores that deliver better performance. License: Apache-2.0.

Nearly five decades after the launch of VisiCalc, AI is reshaping one of the world’s most familiar productivity tools — the humble spreadsheet.

While a lot of knowledge workers interact with spreadsheets on a regular basis, many lack the skills and confidence to access more advanced functions.

“For a very long time, spreadsheets forced you to learn spreadsheet syntax and spreadsheet ways of working,” said Eric Birnbaum, director of product management for Google Sheets. “But think about how many people need to use spreadsheets at work and don’t have the skill set to create the kinds of spreadsheets that can be really helpful for them.”

The addition of artificial intelligence can help handle that issue, he said, making the software more accessible to a wide range of office workers. “AI is unlocking the power of spreadsheets, taking on a lot of the difficult work that’s required to use them. That can be incredibly empowering for users,” said Birnbaum.

Google has steadily expanded generative AI (genAI) capabilities in Sheets since launching Duet AI — now Gemini — for Workspace in 2023.

Gemini in Sheets is available at no extra cost to Google Workspace subscribers, though a paid AI Expanded Access add-on – costing $30 per user each month – is required to remove certain usage limits.

Features that have rolled out in recent months include the ability for a Gemini agent in Sheets to carry out multi-step actions such as formatting, analysis and data entry, and, more recently, the ability to create entire spreadsheets from a single prompt. A Fill with Gemini feature builds on the existing AI function, enabling users to automatically populate selected cells by detecting intent from information within a spreadsheet as well as from the web.

Another feature, Sheets Canvas (currently available in alpha), lets users generate interactive apps that update in real-time based on changes to spreadsheet data. This could be a kanban board for a sales pipeline, for instance, or an analytics dashboard that uses Sheets as its back-end data source. 

Google claims users already see a range of benefits from Gemini in Sheets. According to an August 2025 survey of 200 Sheets users conducted by the company, the majority of knowledge workers (89%) said AI features in Sheets save them at least an hour a week, and 88% believe AI features have made them more confident in their data analysis skills. 

The most popular AI use cases include creating spreadsheets and charts, analyzing data, and fixing broken formulas. How widely these features are actually used is unclear; Google declined to provide weekly usage statistics for Gemini in Sheets.

As the company embeds Gemini deeper into Sheets, questions remain about just how much businesses can trust AI tools to handle important business data, as well as what increased automation means for those who spend much of their day wrangling data. 

Computerworld recently talked with Birnbaum about the potential benefits and challenges of the latest evolution of spreadsheet software. This interview has been condensed and edited for clarity.

As businesses become more focused on seeing value from AI investments, what measurable benefits are customers seeing from Gemini in Sheets – for example, time saved or other forms of return on investment? “Spreadsheets remain one of the universal languages for businesses, and we don’t anticipate that’s going to change anytime soon. But by bringing AI into the product where people work, we think it can significantly reduce the technical tax of data: the time spent understanding it, sourcing it, analyzing it, visualizing it.

“Historically, data professionals spent — let’s estimate it at 80% of their time — on the mechanical groundwork, data cleaning, crafting formulas, formatting, troubleshooting, and maybe only 20% of their time on actual strategic decision-making.

“We think that by offloading the manual, time-consuming, error-prone data work to Gemini, we can flip that ratio a bit, so humans can focus on the things that really matter: the high-value questions to ask and the judgment calls and decisions that get made from them. We’re starting to see evidence of that in our own user base and customer base.

“The second point to make is that AI can democratize data analysis to some extent, and make it available to many more users. For so many years, the spreadsheet was a gatekeeper; if you couldn’t speak the rigid language of spreadsheet formulas, you couldn’t extract the value from data. But by introducing these natural language interfaces, AI is separating the analytical capability from the technical literacy. 

“If you can ask the right questions, or describe what you want in plain language, Gemini and Sheets can help you achieve your goals in a spreadsheet, even if you have minimal spreadsheet skills yourself.

“What we’ve seen so far from users and customers is that it’s incredibly empowering for people who might have been scared off by data analysis or dreaded opening spreadsheets in the past. You don’t need to go and wait for a data analyst to help you; you can go and do this work yourself in a spreadsheet.”

The flip side is, how confident can businesses be if more junior employees can take on higher-level analysis tasks by relying on AI? Given the propensity for AI models to hallucinate, to what degree can businesses trust that these tools won’t introduce errors into important business data? “It’s something we spent a ton of time thinking about. We’ve gone to great lengths to build these AI tools to collaborate with you, to show their work, explain what they did, and make sure that you can take over where they leave off.

“Our Sheets agent, for example, lays out a really explicit, transparent plan for you to review and approve before any data manipulation happens. It’s designed to do that in plain natural language in a way that the average user could understand, and then it gives you back that final summary, so you know exactly what it did and where it did it.

“The other thing is that the model is great at explaining things. If you inherit a spreadsheet that has some complex formula that you don’t understand, for example, the model does an amazing job of explaining how it works and what it’s doing.

“In many ways AI is not only making these features more accessible, but helping users feel more confident in the output. Human error is an inherent risk in manual data management, with or without AI. One misplaced comma or broken cell reference can completely corrupt an entire financial model, and it can be completely undetected. 

“Our approach with AI in Sheets is to create this deliberate verification loop. You now have another spreadsheet expert working along with you, reducing the likelihood of these mistakes.”

Even if humans produce errors too, does it ultimately come down to accountability when AI is involved? “Our point of view here is that AI should be partnering with the knowledge worker who’s doing the work here. And everything that we’ve built is designed to be that partner. You might be able to offload tasks to the model, but we’re citing sources, we’re providing plans and explanations. We’re ultimately relying on the user to do that final verification.

“We spend a humongous amount of time focused on quality. We know that for AI to be useful in spreadsheets, it has to be reliable. When we launched Sheets Gemini Agent, for example, we were really proud that we set a state-of-the-art benchmark on the full SpreadsheetBench data set, which at the time exceeded competitors and near-human expert ability. 

“But we know quality is never ‘good enough’ or done. We’re constantly working to improve quality for our users and customers, and for the use cases where they’re relying on AI most.”

What potential do you see for more agentic functionality in Gemini Sheets — for example, bringing in data from other sources, creating recurring reports, or taking more actions independently? “We’re listening closely to customers and users and building what they’re telling us they need. The agent is already capable of doing very complex multistep workflows, and we see users discover that the agent is extremely capable of doing end-to-end spreadsheet tasks. In terms of connectors, in an alpha we have connections available to HubSpot, Salesforce, and Mailchimp. We hope to expand that over time.

“There’s no path to have AI replacing analysts. I think AI is giving analysts more time back to actually do the more valuable parts of their job. Analysts that I work with are way more productive and impactful than they ever were before, because they can push that uninteresting spreadsheet grunt work off to the model, freeing up time for more interesting and impactful work.

“A great example: the visualizations I’m getting back from analysts nowadays are canvases instead of static charts that I can explore myself. It’s way more informative and useful than what I was accustomed to before.”

Looking ahead, do you expect a larger share of spreadsheet work to be carried out by agents, with humans setting goals and reviewing results? What will be the biggest change in how people use spreadsheets with AI? “The tasks are likely to stay similar and the use cases for spreadsheets are likely to continue to be relevant. The biggest change will be the ability to push the uninteresting spreadsheet grunt work off to a model and free up time for the user to do things that are more impactful, more interesting, more meaningful to the business.

‘Spreadsheets have historically been these like static containers where data goes to rest. I think AI can turn spreadsheets into these dynamic, localized software applications. And I do actually think this sort of changes the game for how people might use spreadsheets moving forward. 

“It’s not just a passive grid full of numbers; spreadsheets are evolving to become these live, long-lived, collaborative applications. Employees can build these on the fly, like a basic CRM or supply chain dashboard in seconds. This is an area of investment for us moving forward, and we’re really excited to see how this evolves.”

AI assistants and agents, such as ChatGPT or Claude, might be able to analyze spreadsheet files and business data without users working inside a spreadsheet application. What do you think will keep Sheets central to the workflow, rather than simply making it one part of a wider AI-driven process?“We’re in constant touch with customers and users; it’s clear work is still happening in spreadsheets. I think spreadsheets remain incredibly popular tools. If we can bring the AI capabilities users need directly into the product where they already are, we’ll transform the way they work.  

“I think we can be the front-end for some of this great AI innovation and the products that users are accustomed to today. Everything we build is guided by user feedback: users are telling us right now they want AI to help them do their everyday or more complex tasks, and they’re starting in Sheets today.”

Chatting with readers and regular folks in the real world these days, I can’t help but notice a common theme anytime the topic of AI comes up.

It’s an almost amusingly extreme contrast: While the myopic world of tech people (and the type of mostly AI-powered “thought leaders” you see posting in turbo-speed on LinkedIn) are waxing endlessly about AI’s amazing impact on society and all the ways it’s, like, totally revolutionizing workflow, bruh, the average human’s take on AI can best be summed up with a single word:

Exasperation.

With shockingly little exception, almost every non-tech-obsessed organism I interact with reacts with something between an eye-rolling sigh and a fed-up facepalm whenever the prevalence of AI arises. It’s almost like having an on-demand in-person GIF gallery of “frustration” available at your fingertips — just mention AI, and you’ll get a meme-worthy reaction from anyone around you.

It’s such a dramatic divergence from the glowingly excited hype we hear left and right from the tech industry itself and the seemingly small but vocal group of overly enthusiastic evangelists who create an echo chamber around it. And that very contrast and the disparity between what tech companies are giving us and what tech users actually want these days led me to a bit of an epiphany this week:

AI may well be creating a killer feature that people will be willing to pay to possess. It’s just not the one most AI-fixated entities are focused on creating — quite the opposite, in fact.

[Get level-headed knowledge in your inbox with my free Android Intelligence newsletter — practical tech talk by humans, for humans.]

The AI availability irony

I’ve said it before, and I’ll say it again: In many ways, Gemini — Google’s generative AI chatbot and overall AI layer — is the new Google+.

It’s a solution in search of a problem. No one is asking for it and most typical tech users increasingly seem to find its presence actively irksome and invasive — and yet Google continues to insist on shoving it into our faces at every possible opportunity. More and more with every passing week, the company’s adding AI elements into almost every app and service regardless of whether they’re actually helpful in that context. In many cases, in fact, they’re unnecessary, useless, even outright creepy and creating very real problems and liabilities for businesses and individuals alike.

It’s not just Google, of course. The same tale is taking place with practically every tech provider big and small right now. Everyone is cramming AI into every nook and cranny and thinking more about the idea of integrating artificial intelligence — mostly just for the sake of having it there — than creating an optimal experience for the people who actually use said services.

That, in turn, is creating a whole new category of productivity experience that people are actually lining up to pay for — a premium feature of sorts, related to AI and its presence in our lives.

Ready for the most delicious irony of all? The killer AI feature of which we speak is a lack of AI — or at least the ability to disable and avoid it and use it only if and when you want.

It’s not just an anecdotal feeling, either. It’s a measurable trend that may still be in its infancy but is absolutely taking shape around us.

Take, for instance, Kagi — an ad-free, privacy-centric search service that’s been quietly building a viable alternative to Google Search for several years already. The proposition is simple: You pay a monthly fee — five bucks a month for limited use or $10 for unlimited searching — and you get a search engine that’s designed to serve you instead of revolving around the interest of both advertisers and corporate AI initiatives.

The Kagi search experience is clean, simple, and effective — and, most notably for our current conversation, free from all the often accuracy-challenged AI-generated “answers” that are now plastered atop most Google searches. You just get the results you want, without any experience-harming interruptions or distractions — because you’re paying for the service. Those five or 10 smackeroos you send over each month restructure the entire relationship and ultimately change everything about the service’s trajectory.

When I wrote a profile piece about Kagi last February, the service boasted 38,000 paying subscribers. Today, according to Kagi’s public stats page, its subscriber base has nearly doubled — to 72,847 users, as of this writing.

It may still be a drop in the bucket — and it may always be a niche demand, in the grand scheme of the global tech picture — but it represents a rapidly growing demand. And Kagi isn’t the only player seeing both the demand and the resulting opportunity. Practically every time Google pushes AI further into its search setup, the privacy-focused (and AI-optional) search provider DuckDuckGo reports a surge in its adoption as well.

And search isn’t the only arena where this same sentiment is starting to boil over. I hear constantly from folks who are growing ever-more frustrated with all the unavoidable AI integration in other productivity tools, ranging from email to notes and even just plain ol’ document writing. Heck, I created my own custom interface for Google Docs on the desktop (with the help of Gemini, in another delightfully ironically twist) just to escape from all the over-the-top noise Google keeps adding into that environment. It’s a nerdy hack, to be sure — and it’s an opportunity for someone crafty to come in and create an actual solution, in the style of what Kagi has done with search, to more effectively address that same underlying desire.

More and more research is starting to reflect that yearning for practical, useful tech tools that aren’t larded down with AI for the sake of AI. A recent study by Automattic (the behind WordPress) found 60% of people say AI in a brand’s messaging is more of a turnoff than a feature. My own smaller (and much less scientific, though also more specifically focused) poll of folks who read my Android Intelligence newsletter found that only 9% of Android-owning animals said they generally loved the presence of AI results in regular web searches — with 26% outright hating it and 64% saying it depends on the situation but that they at least sometimes find it to be more annoying than useful.

So as company after company crams AI into everything and startup after startup jumps on that same steamy bandwagon, the question in my mind is less about what the next big advancement in AI will bring into our lives and more about what interesting opportunities the lack of AI — or at least the ability to limit its influence on a productivity experience and decide for yourself how and when you actually want to use it — will create.

It’s easy to imagine a scenario in which services like Kagi and DuckDuckGo start to offer AI-free or even just AI-optional alternatives to apps that are being overrun with irritating and countereffective AI integrations — things like Docs, Notion, Slack, and any number of design tools. And it’s equally easy to imagine plenty of people and places being enticed by that lack of AI as a premium feature worth paying to experience.

It may inevitably remain a relatively niche market compared to the more mainstream tech solutions. But for people and organizations woefully underwhelmed with the current direction tech’s taking and willing to shell out cash for quality, it’s an intriguing notion — and an area well worth watching as the AI invasion continues crashing into every last corner of our virtual lives.

Sick of AI for the sake of AI? Check out my free weekly Android Intelligence newsletter for original human thinking and actually-helpful ways to make the most of your devices.

It has been a year or so since Microsoft announced its plans to move TypeScript to a new, native runtime based on the Go language. Those first releases were unfinished (you had to compile them yourself) but showed promise, getting close to the expected 10x speed-up. That year has been one of steady progress, with Microsoft recently announcing the delivery of a release candidate build.

This release candidate is ready for use. It installs from npm like previous versions, and like earlier builds it works in much the same way as previous versions of TypeScript, checking types in your code, compiling it to run on ECMAScript-compliant JavaScript engines, and running just about anywhere. In addition, a native preview of the TypeScript language server for Visual Studio Code is available to help you write new TypeScript code and guide you through updating existing applications to the new language features.

All you need to do is enable the TypeScript 7 extension through the Visual Studio command palette and start coding. There’s a lot of work going on to get the new tooling ready for the final release of TypeScript 7, and new versions of the language server are being released almost daily. It’s certainly popular, too, with nearly half a million downloads at the time of writing.

What makes TypeScript 7 so much faster?

So how is this new TypeScript so much faster? Key to the improvements is a shift to a new native compiler built in Go. This has allowed the team to change how it operates, adding parallelization where possible. In some cases, this isn’t easy, such as when type checking large codebases split across many files.

Here TypeScript spawns a small number of checker workers that run across your codebase. They work independently, so can duplicate the work — though the output will be the same. You can choose your own number of checkers, but the more you use, the more memory and CPU will be required.

Large monorepos with many projects require a similar approach with independent builder workers. You’ll need to balance this with the number of checkers in use, as this can cause significant resource issues.

There are some significant language and configuration changes from TypeScript 5 (TypeScript 6 has the same changes, which makes it a useful tool for experimenting with migrations). It’s well worth reading the release candidate documentation to understand how these will affect your code, as well as using the TypeScript 7 extension for Visual Studio Code to identify where you need to make changes.

Working with users to build language tools

One important aspect to the development of TypeScript 7 has been collaboration with existing users of the language and its tooling, as well as using the existing suite of TypeScript test tools that have been used to evaluate other versions. As this update is primarily a port of existing code, rather than a bottom-up rewrite, the underlying language semantics and structure are the same as those used in the original JavaScript codebase, ensuring that code will quickly port from old to new versions.

A major internal collaborator was the Visual Studio Code team, who have been using TypeScript to develop the familiar cross-platform development tool. It’s an important partnership between tool and language, as VS Code is a key TypeScript development tool, hosting TypeScript’s language server and using its compiler to provide debugging and code completion features.

The VS Code team published a long blog post detailing how it has been working with the Go-based TypeScript. The team is both helping to develop the language and beginning the process of moving its codebase to the newer, faster, native platform.

How the VS Code team migrated is a useful case study, one that can help you move your TypeScript development more efficiently and with minimal risk. The team began working with extensions, using daily builds of TypeScript to ensure that bugs and issues could be reported as they occurred and would only have a limited impact as fixes could be rolled out quickly. At the same time, the VS Code team began using a preview version of the TypeScript 7 extension for VS Code, which was being built around the new compiler in parallel with its development.

Bridging development with TypeScript 6

The development of TypeScript 6 as a bridge between TypeScript 5 and TypeScript 7 allowed the VS Code team to transition to code that targeted a newer version of ECMAScript and provided more powerful checks. By moving code from TypeScript 5 to TypeScript 6, developers could validate it with what would become TypeScript 7 language features and get speed and performance boosts while doing so (though nowhere near what TypeScript 7 promised). By completing this first migration of the VS Code codebase, it was possible for developers to be confident that they were ready to shift to the Go-based version when it shipped.

The parallel development of the new language server and extension ensured that by late 2025 it was possible for VS Code development to shift to TypeScript 7, with TypeScript 6 used as a fallback if there were any issues. Those cases could then be reported back to the TypeScript team and used to prioritize development.

As the platform evolved, the use cases for the VS Code team changed. By early 2026 TypeScript 7 was stable and nearly feature-complete, so the team began to use it to build all of their own built-in extensions. This allowed them to rethink their toolchain, changing the bundler from webpack to the one built into esbuild, giving them another speed up. Once that process was tested and working, they could switch all development to TypeScript 7.

Having such a big project take on TypeScript 7 early reaped big rewards, as the resulting virtuous cycle allowed both VS Code and TypeScript to move forward together, fixing issues as they arose and providing valuable feedback. The results speak for themselves. Type checking the entire VS Code codebase is now 7x faster, with most extensions checked in under a second. The only exception was GitHub Copilot, which is almost as big as the editor itself, which type checked in 2.5 seconds.

Compilation has been sped up, dropping from 80 seconds to around 20 seconds. This may not seem a lot, but when you’re compiling and rebuilding and debugging, each change in your code now takes a lot less time. That improves developer productivity and ensures they stay in flow, rather than switching away to check email or Teams each time they start a new build. The same goes for using the language server, where loading the entire project (necessary for error detection and refactoring) now takes 10 seconds rather than a minute.

Lots of little time savings like this add up across a big project and a large team, helping developers stay focused and able to solve problems more effectively. The VS Code blog post notes that it cuts down on coffee runs, which take longer than the load or build that inspire a quick cuppa!

Getting ready for TypeScript 7 in your build pipeline

Microsoft is quick to point out that, while the TypeScript 7.0 release will be production ready, TypeScript 7 won’t have a full programmatic API until the release of TypeScript 7.1. As this won’t be for some time, Microsoft is providing a way to run TypeScript 7 side-by-side with TypeScript 6.

Installing the @typescript/typescript6 compatibility package alongside TypeScript 7 adds a new executable, tsc6, that allows you to modify code that uses the TypeScript 5 API to run using TypeScript 6, by renaming the calls to tsc in your scripts to tsc6. This should allow you to keep building to the latest releases at the same time as starting to experiment with using the new runtime.

It’s not a perfect fix. You do need to do some work to implement npm aliases that allow linters and other low-level tools to work with both versions. You can also provide two different dependencies in your package.json to allow TypeScript 6 (tsc6) and TypeScript 7 (tsc) to run side-by-side. The result is a way to help migrate TypeScript code to the newer platform, delivering more efficient code that runs on a more modern ECMAScript in the meantime.

TypeScript 7 will be a big upgrade, though it has taken surprisingly little time to deliver. With users like the Visual Studio Code team already building on the new release, it’s clear that beginning your own migration should be easier than you might have thought.

The final release is due sometime in July 2026. If you haven’t started looking at TypeScript 7, now is the time to start.