I use coding agents every day. I haven’t written a line of code for any of my side projects in many weeks. I don’t use coding agents in my day job yet, but only because the work requires a deeper knowledge of a huge code base than most large language models can deal with. I expect that will change.

Like everyone else in the software development business, I have been thinking a lot about agentic coding. All that thinking has left me with six thoughts about the advantages of using coding agents now, and how agentic coding will change developer jobs in the future.

Coding agents are tireless

If I said to a junior programmer, “Go and fix all 428 hints in this code base, and when you are done, fix all 434 warnings,” they would probably say, “Sure!,” and then complain about the tediousness of the task to all of their friends at the lunch table.

But if I were to ask a coding agent to do it, it would do it without a single complaint. Not one. And it would certainly complete the task a hundred times faster than that junior programmer would. Now, that’s nothing against humans, but we aren’t tireless. We get bored, and our brains turn fuzzy with endless repetitive work. 

Coding agents will grind away endlessly, tirelessly, and diligently at even the most mind-numbingly boring task that you throw at them. 

Coding agents are slavishly devoted

Along those same lines, coding agents will do what you ask. Not that people won’t, but coding agents will do pretty much exactly what you ask them to do. Now, this does mean that we need to be exacting about what we ask for. A high level of fastidious prompting is the next real skill that developers will need. It’s probably both a blessing and a curse, but if you ask for a self-referential sprocket with cascading thingamabobs, a coding agent will build one for you.

Coding agents ask questions you didn’t think to ask

One thing I always do when I prompt a coding agent is to tell it to ask me any questions that it might have about what I’ve asked it to do. (I need to add this to my default system prompt…) And, holy mackerel, if it doesn’t ask good questions. It almost always asks me things that I should have thought of myself. 

Coding agents mean 10x more great ideas 

If you can get a coding agent to code your idea in two hours, then you could undoubtedly produce many more ideas over the course of a month or a year. If you can add a major feature to your existing app in a day, then you could add many more major features to your app in a month than you could before. When coding is no longer the bottleneck, you will be limited not by your ability to code but by your ability to come up with ideas for software.

Ultimately, this last point is the real kicker. We no longer have to ask, “Can I code this?” Instead, we can ask ourselves, “What can I build?” If you can add a dozen features a month, or build six new applications a week, the real question becomes, “Do I have enough good ideas to fill out my work day?”

Coding agents make junior developers better

A common fear is that inexperienced developers won’t be employable because they can’t be trusted to monitor the output of coding agents. I’m not sure that is something to worry about. 

Instead of mentoring juniors to be better coders, we’ll mentor them to be better prompt writers. Instead of saying, “Code this,” we’ll be saying, “Understand this problem and get the coding agent to implement it.”

Junior developers can learn what they need to know in the world of agentic coding just like they learn what they need to know in the world of human coding. With coding agents, juniors will spend more time learning key concepts and less time grinding out boilerplate code.

Everyone has to start somewhere. Junior developers will start from scratch and head to a new and different place. 

Coding agents will not take your job

A lot of keyboards have been pounded over concerns that coding agents are coming for developer jobs. However, I’m not the least bit worried that software developers will end up selling apples on street corners. I am worried that some developers will struggle to adapt to the changing nature of the job. 

Power tools didn’t take carpentry jobs away; they made carpenters more productive and precise. Developers might find themselves writing a lot less code, but we will be doing the work of accurately describing what needs implementing, monitoring those implementations, and making sure that our inputs to the coding agents are producing the correct outputs.

We may even end up not dealing with code at all. Ultimately, software development jobs will be more about ideas than syntax. And that’s good, right?

It’s easy to see why anxiety around AI is growing—especially in engineering circles. If you’re a software engineer, you’ve probably seen the headlines: AI is coming for your job.

That fear, while understandable, does not reflect how these systems actually work today, or where they’re realistically heading in the near term.

Despite the noise, agentic AI is still confined to deterministic systems. It can write, refactor, and validate code. It can reason through patterns. But the moment ambiguity enters the equation—where human priorities shift, where trade-offs aren’t binary, where empathy and interpretation are required—it falls short.

Real engineering isn’t just deterministic. And building products isn’t just about code. It’s about context—strategic, human, and situational—and right now, AI doesn’t carry that.

Agentic AI as it exists today

Today’s agentic AI is highly capable within a narrow frame. It excels in environments where expectations are clearly defined, rules are prescriptive, and goals are structurally consistent. If you need code analyzed, a test written, or a bug flagged based on past patterns, it delivers.

These systems operate like trains on fixed tracks: fast, efficient, and capable of navigating anywhere tracks are laid. But when the business shifts direction—or strategic bias changes—AI agents stay on course, unaware the destination has moved.

Sure, they will produce output, but their contribution will either be sideways or negative instead of progressing forward, in sync with where the company is going.

Strategy is not a closed system

Engineering doesn’t happen in isolation. It happens in response to business strategy—which informs product direction, which informs technical priorities. Each of these layers introduces new bias, interpretation, and human decision-making.

And those decisions aren’t fixed. They shift with urgency, with leadership, with customer needs. A strategy change doesn’t cascade neatly through the organization as a deterministic update. It arrives in fragments: a leadership announcement here, a customer call there, a hallway chat, a Slack thread, a one-on-one meeting.

That’s where interpretation happens. One engineer might ask, “What does this shift mean for what’s on my plate this week?” Faced with the same question, another engineer might answer it differently. That kind of local, interpretive decision-making is how strategic bias actually takes effect across teams. And it doesn’t scale cleanly.

Agentic AI simply isn’t built to work that way—at least not yet.

Strategic context is missing from agentic systems

To evolve, agentic AI needs to operate on more than static logic. It must carry context—strategic, directional, and evolving.

That means not just answering what a function does, but asking whether it still matters. Whether the initiative it belongs to is still prioritized. Whether this piece of work reflects the latest shift in customer urgency or product positioning.

Today’s AI tools are disconnected from that layer. They don’t ingest the cues that product managers, designers, or tech leads act on instinctively. They don’t absorb the cascade of a realignment and respond accordingly.

Until they do, these systems will remain deterministic helpers—not true collaborators.

What we should be building toward

To be clear, the opportunity isn’t to replace humans. It’s to elevate them—not just by offloading execution, but by respecting the human perspective at the core of every product that matters.

The more agentic AI can handle the undifferentiated heavy lifting—the tedious, mechanical, repeatable parts of engineering—the more space we create for humans to focus on what matters: building beautiful things, solving hard problems, and designing for impact.

Let AI scaffold, surface, validate. Let humans interpret, steer, and create—with intent, urgency, and care.

To get there, we need agentic systems that don’t just operate in code bases, but operate in context. We need systems that understand not just what’s written, but what’s changing. We need systems that update their perspective as priorities evolve.

Because the goal isn’t just automation. It’s better alignment, better use of our time, and better outcomes for the people who use what we build.

And that means building tools that don’t just read code, but that understand what we’re building, who it’s for, what’s at stake, and why it matters.

—

New Tech Forum provides a venue for technology leaders—including vendors and other outside contributors—to explore and discuss emerging enterprise technology in unprecedented depth and breadth. The selection is subjective, based on our pick of the technologies we believe to be important and of greatest interest to InfoWorld readers. InfoWorld does not accept marketing collateral for publication and reserves the right to edit all contributed content. Send all inquiries to doug_dineley@foundryco.com.

For any application that works with a lot of data, the obvious approach is to store it in some kind of database. Depending on your ambitions, that can be something as modest as SQLite, or as upscale as PostgreSQL.

What often complicates things is not which database to use, but how to use it. Enterprise-scale databases like PostgreSQL give you great power but impose an infrastructure tax: Setting up and configuring a database server is nobody’s idea of fun. Docker containers are an option, but if you’re not already invested in Docker as a solution, moving everything to containers is an outsized project.

One reaction to all this has been the rise of self-contained database solutions. Everything is packed into a single executable or living in a single directory, with no external dependencies and no formal installation. SQLite is the obvious example of this style, but it’s not always the most robust solution. There are more powerful databases that do the same thing—including some familiar A-list options. Even better, some come as drop-in application libraries for popular languages.

MariaDB

If you want a fully self-contained instance of MariaDB, you have three choices: Create one yourself with a little work; use a third-party pre-packaged version; or use a portable full-stack solution that includes a web server and other tools along with the database.

Nathaniel Sabanski has outlined the steps required to manually set up MariaDB in a standalone edition. Download and unpack the binaries, create a basic configuration file, then start the server and any management tools you’d need along with it. Any upgrades or maintenance are entirely on you, but the gist describes how to get it done without too much sweat. Note that if you’re using Microsoft Windows, get the .ZIP file to make it easier to extract, and use the mysql_install_db.exe application to set things up (the defaults should be fine).

For even more convenient downloading and unpacking, Andy Targino provides self-contained versions of the MariaDB binaries.

If you need to stand up a web server along with the database, and maybe a few other components, too, look to the XAMPP stack. This all-in-one solution contains MariaDB plus the Apache web server, the PHP runtime, the Mercury SMTP mail server, web-based controls for all the components, and a service manager for the desktop. It even includes OpenSSL for proper https support.

PostgreSQL

Various repackagings of PostgreSQL as a standalone application have come and gone over the years (see this project, for instance), but it takes relatively little work to set up your own standalone PostgreSQL application. Obtain the binaries minus the setup tools, unpack them into a directory, and run initdb to configure the basic setup. You can then use pg_ctl to start and stop the database as needed.

Python developers have a truly slick option for adding a self-contained PostgreSQL instance to an application: pgserver, a pip install-able library that contains a fully standalone instance of PostgreSQL. The entire app, binaries and all, lives in your Python program’s virtual environment. It does add about 30MB to the base footprint of the venv, but the resulting convenience is hard to match.

MongoDB

MongoDB binaries are available without an installer, so in theory they can be run from any directory. But if you want tighter integration with a given application without a formal install, that’s possible.

What the pgserver library does for PostgreSQL and Python, portable-mongodb does for MongoDB and Node.js. Add it to a Node project and you’ll have a private, automatically deployed instance of MongoDB for that project, or for other project environments if you so choose.

If you want to do this yourself, and want more granular control over the deployment, Atikur Rahman has published step-by-step instructions for creating a self-contained MongoDB instance. It’s less complex than you might think.

Redis

On Linux, Windows, and macOS, a common way to run Redis is to simply use a Docker container, or to install by way of a package manager (APT, RPM, Snap, Homebrew). But for a fully portable experience without Docker on Windows, a third-party build of Redis provides standalone Windows binaries. These are built directly from source and kept in synchrony with recent releases.

Centered on vibe coding, AI-powered Vercel’s v0 development platform has been fitted with security and integrations geared to shipping real software instead of just making demos, the company said. The platform has been rebuilt from the ground up to close the prototype-to-production gap for vibe coding in the enterprise, according to the company.

Called the “new v0” and detailed in a February 3 blog post, the update evolves the vibe coding platform for building production apps and agents. Developers can log in to v0.app to give the release a try. For security, v0 is built on the Vercel core cloud platform, where security is configurable for common compliance needs, Vercel said. Users can set deployment protection requirements, connect securely to enterprise systems, and set proper access controls for each app. Also featured are secure integrations with Snowflake and AWS databases, enabling the building of custom reporting, adding rich context to internal tools, and automating data-triggered processes. All code generated by v0 is designed to plug into Vercel’s standard Git-based workflows and its preview and production deployment infrastructure on the Vercel cloud platform.

The new v0 release also has a new sandbox-based runtime that can import any GitHub repo and automatically pull environment variables and configurations from Vercel. Every prompt generates production-ready code in a real environment, and it lives in the user’s repo, Vercel said. A new Git panel lets developers create a new branch for each chat, open pull requests against a project’s main branch in the connected GitHub repository, and deploy on merge. Anyone on a team, not just engineers, can ship production code through proper Git workflows, according to Vercel. Future plans call for enabling developers to build end-to-end agentic workflows in v0, AI models included, and deploy them on Vercel self-driving infrastructure.

Snowflake (NYSE:SNOW) has rapidly become a staple for data professionals and has arguably changed how cloud developers, data managers and data scientists interact with data. Its architecture is designed to decouple storage and compute, allowing organizations to scale resources independently to optimize costs and performance.

For cloud developers, Snowflake’s platform is built to be scalable and secure, allowing them to build data-intensive applications without needing to manage underlying infrastructure. Data managers benefit from its data-sharing capabilities, which are designed to break down traditional data silos and enable secure, real-time collaboration across departments and with partners.

Data scientists have gravitated to Snowflake’s capability to handle large, diverse datasets and its integration with machine learning tools. Snowflake is designed to rapidly prepare raw data, build, train, and deploy models directly within the platform to achieve actionable insights.

Watch this page for the latest on Snowflake.

Snowflake latest news and analysis

Snowflake debuts Cortex Code, an AI agent that understands enterprise data context

February 3, 2026: Snowflake has launched Cortex Code, an AI-based coding agent that aims to extend AI assistance beyond SQL generation and conversational analytics into data and app development tasks.

Snowflake to acquire Observe to boost observability in AIops

January 9, 2026: Snowflake plans to acquire AI-based SRE platform provider Observe to strengthen observability capabilities across its offerings and help enterprises with AIOps as they accelerate AI pilots into production.

Snowflake software update caused 13-hour outage across 10 regions

December 19, 2025: A software update knocked out Snowflake’s cloud data platform in 10 of its 23 global regions for 13 hours on December 16, leaving customers unable to execute queries or ingest data.

Snowflake to acquire Select Star to enhance its Horizon Catalog

November 21, 2025: Snowflake has signed an agreement to acquire startup Select Star’s team and context metadata platform to enhance its Horizon Catalog offering, the company said in a statement. Horizon Catalog is a unified data discovery, management, and governance suite inside the cloud-based data warehouse provider’s Data Cloud offering.

Databricks fires back at Snowflake with SQL-based AI document parsing

November 13, 2025: Databricks and Snowflake are at it again, and the battleground is now SQL-based document parsing. In an intensifying race to dominate enterprise AI workloads with agent-driven automation, Databricks has added SQL-based AI parsing capabilities to its Agent Bricks framework, just days after Snowflake introduced a similar ability inside its Intelligence platform.

Snowflake to acquire Datometry to bolster its automated migration tools

November 11, 2025: Snowflake will acquire San Francisco-headquartered startup Datometry, for an undisclosed sum, to bolster SnowConvert AI, one of its existing set of migration tools.

Snowflake brings analytics workloads into its cloud with Snowpark Connect for Apache Spark

July 29, 2025: Snowflake plans to run Apache Spark analytics workloads directly on its infrastructure, saving enterprises the trouble of hosting an Apache Spark instance elsewhere, and eliminating data transfer delays between it and the Snowflake Data Cloud.

Snowflake customers must choose between performance and flexibility

June 4, 2025: Snowflake is boosting the performance of its data warehouses and introducing a new adaptive technology to help enterprises optimize compute costs. Adaptive Warehouses, built atop Snowflake’s Adaptive Compute, is designed to lower the burden of compute resource management by maximizing efficiency through resource sizing and sharing,

Snowflake takes aim at legacy data workloads with SnowConvert AI migration tools

June 3, 2025: Snowflake is hoping to win business with a new tool for migrating old workloads. SnowConvert AI is designed to help enterprises move their data, data warehouses, business intelligence (BI) reports, and code to its platform without increasing complexity.

Snowflake launches Openflow to tackle AI-era data ingestion challenges

June 3, 2025: Snowflake introduced a multi-modal data ingestion service — Openflow — designed to help enterprises solve challenges around data integration and engineering in the wake of demand for generative AI and agentic AI use cases.

Snowflake acquires Crunchy Data to counter Databricks’ Neon buy

June 3, 2025: Snowflake plans to buy Crunchy Data,a cloud-based PostgreSQL database provider, for an undisclosed sum. The move is an effort to offer developers an easier way to build AI-based applications by offering a PostgreSQL database in its AI Data Cloud. The deal, according to the Everest Group ,is an answer to rival Databricks’ acquisition of open source serverless Postgres company Neon.

Snowflake’s Cortex AISQL aims to simplify unstructured data analysis

June 3, 2025: Snowflake is adding generative AI-powered SQL functions to help organizations analyze unstructured data with SQL. The new AISQL functions will be part of Snowflake’s Cortex, managed service inside its Data Cloud providing the building blocks for using LLMs without the need to manage complex GPU-based infrastructure.

Snowflake announces preview of Cortex Agent APIs to power enterprise data intelligence

February 12, 2025: Snowflake announced the public preview of Cortex Agents, a set of APIs built on top of the Snowflake Intelligence platform, a low-code offering that was first launched in November at Build, the company’s annual developer conference.

Snowflake open sources SwiftKV to reduce inference workload costs

January 16, 2025: Cloud-based data warehouse company Snowflake has open-sourced a new proprietary approach — SwiftKV — designed to reduce the cost of inference workloads for enterprises running generative AI-based applications. SwiftKV was launched in December.

OpenAI has launched a standalone Codex app to manage multiple AI coding agents across projects, pushing beyond chat-based code generation as enterprises weigh the impact of more autonomous tools on development workflows and governance.

The move comes as OpenAI faces intensifying competition from rivals such as Anthropic and GitHub. Last month, Anthropic introduced Cowork, a research-preview feature that extends Claude Code beyond programming into broader enterprise workflows.

“The Codex app provides a focused space for multi-tasking with agents,” OpenAI said in a statement, noting that agents “run in separate threads organized by projects,” allowing developers to switch between tasks without losing context.

The Codex app is currently available on macOS for users on OpenAI’s paid ChatGPT plans. OpenAI said it plans to make it available on Windows.

Codex is also moving beyond code generation, with “skills” that allow agents to gather information, solve problems, and carry out broader tasks on a developer’s computer, the company added.

Implications for developers

Agentic AI-based coding is gaining interest in more enterprise development teams, pushing workflows beyond traditional IDE-centric models.

“These agent-driven development shells can speed up coding, debugging, and deployment, although they introduce higher enterprise risks,” said Neil Shah, VP for research at Counterpoint Research.

Based on early indications, OpenAI has taken a meaningful but incremental step with Codex in AI-assisted development, rather than a radical change, said Tulika Sheel, senior vice president at Kadence International.

“It doesn’t change the fundamentals of how code is written or reviewed, but it does streamline workflows by letting developers manage longer, more complex coding tasks in one place rather than through scattered IDE prompts,” Sheel said.  “Over time, this could subtly reshape how developers plan, review, and maintain code by treating AI as a continuous collaborator rather than a helper used on a moment-to-moment basis.”

A standalone app also signals a shift from AI assisting with individual lines of code to handling larger blocks of work, said Abhivyakti Sengar, practice director at Everest Group. “Developers spend less time typing and more time reviewing and directing, closer to managing a junior engineer than using an autocomplete tool,” Sengar said.

Risks and challenges

The risks of using AI remain a topic of debate among enterprises. Concerns are likely to increase as multi-agent systems take on a larger role in the software development lifecycle.

“Autonomous AI coders need the same levels of oversight as human ones,” Sheel added. “This includes review, accountability, and clear ownership of the code they produce.”

Companies would also need clarity on intellectual property ownership and licensing to avoid surprises when AI-generated code is reused or shipped.

“Also important is maintaining control over the workflow layer,” Shah added. “Enterprises should opt for tools that support open integration with existing systems such as GitHub to avoid being locked into vertically integrated AI IDEs.”

Vendor lock‑in could also become a real concern as models and agents learn deeply from an enterprise’s code and workflows, analysts say.

“Prioritizing tools that embrace open standards for agentic protocols and workflow while promising transparency around data and IP handling should be non-negotiable,” Shah said. “This, coupled with a stronger governance framework from token usage monitoring, policy enforcement, and auditable controls, will be key to ensuring these tools do not compromise on enterprise sovereignty or security.”

Snowflake has launched Cortex Code, an AI-based coding agent that aims to extend AI assistance beyond SQL generation and conversational analytics into data and app development tasks.

Cortex Code is designed to understand enterprise data context, including schemas, governance rules, compute constraints, and production workflows, Christian Kleinerman, EVP of Product at Snowflake, said during a press briefing.

[ Related: More Snowflake news and insights ]

As a result, developers and data teams can use natural language to build, optimize, and deploy data pipelines, analytics, machine learning (ML) workloads, and AI agents, Kleinerman added.

Snowflake’s existing AI features, such as Cortex AISQL and Snowflake Intelligence, help users query and analyze data.

Analysts say the native coding agent can enable enterprise teams to move from experimentation to scalable data and app deployments faster, as the agent, unlike generic coding agents, understands critical contexts such as which tables are sensitive, which transformations are expensive, which pipelines are production-critical, and how analytics, ML, and agents are supposed to work together.

That contextual understanding, according to HyperFRAME Research’s practice leader of AI stack Stephanie Walter, can reduce the manual effort required to move from an experimental idea to a reliable, governed solution that is ready to run at enterprise scale.

More so because the real risk for enterprises isn’t bad code but code that breaks governance, is expensive, or can’t scale, Walter added.

Cortex Code as a CLI tool in code editors

In order to further help enterprises scale production-grade data and AI applications, Cortex Code, apart from being made available in Snowsight, is also being made available as a command-line interface (CLI) tool via code editors like VS Code and Cursor.

The deployment as a CLI tool, according to Moor Insights and Strategy principal analyst Robert Kramer, will help developers retain their enterprise’s data context, specifically data stored in Snowflake, while still being available in the code editor of their choice, locally on their machines.

The retention of context is important at the code editor level as most development work starts there, Kramer said.

Additionally, since the enterprise context is built in at the pilot stage locally, there are fewer chances of it failing in production or when it hits the warehouse, Kramer noted.

“The same Snowflake-aware agent that helps you prototype in local development workflows can follow the work into Snowflake Workspaces, Notebooks, and production pipelines. That continuity reduces the rewrite and revalidation steps where many AI pilots stall.”

Rival data warehouse and data cloud providers are pursuing comparable strategies to embed AI assistance deeper into data and application development workflows.

While Databricks is focusing more on notebook-centric development and in-platform assistants rather than local-first workflows, Google Cloud is leaning toward analyst-driven discovery through BigQuery, Looker, and Gemini, with a stronger emphasis on in-platform experiences than on local-first, Snowflake-style continuity across environments, Kramer pointed out.

Teradata, on the other hand, is prioritizing agent orchestration, governance, and control over developer ergonomics.

“The right choice depends on whether an organization’s biggest bottleneck is experimentation, governance, or operationalizing AI at scale,” Kramer said.

Cortex Code in Snowsight, which is Snowflake’s web interface, will be made generally available soon, the company said, adding that the CLI version has been made available.

The pace of innovation in cloud computing continues unabated, with AWS recently unveiling durable functions for AWS Lambda. This move could have significant implications for how enterprises design and orchestrate complex serverless workflows. As someone who has tracked and analyzed cloud evolution for decades, I view Amazon’s new offering as both a testament to the maturation of serverless practices and an opportunity for organizations to reassess the fit and risks of deeper integration with AWS’s serverless ecosystem.

A common criticism of serverless computing is its limited ability to orchestrate multistep or long-running workflows. AWS Lambda, arguably the most well-known serverless compute service, excels at handling single, stateless, short-lived tasks such as image processing, data transformation, or lightweight back-end APIs. However, for complex operations like order processing, multistage onboarding, or AI-driven decisions that span hours or weeks, the existing Lambda model requires substantial custom code or external orchestration tools, such as AWS Step Functions or even third-party platforms.

AWS Lambda’s new durable functions directly address this pain point with native state management, automatic checkpointing, and workflow orchestration. Developers can now define a sequence of steps and introduce waits of up to a year without incurring charges during pauses, improving efficiency for workflows with delays or dependencies. This is a significant economic benefit for workflows subject to lengthy delays or external dependencies.

This type of orchestration differentiates proof-of-concept serverless apps from resilient, production-grade systems that withstand partial failures, recover from interruptions, and remain cost-effective throughout their life cycle. Durable functions provide templated state management, built-in error handling, and robust failure recovery, all of which reduce the engineering burden. Consequently, serverless becomes better suited to enterprise-level, workflow-centric applications where reliability and agility are essential.

A meaningful step, but not a panacea

So, should every enterprise jump to refactor their applications around Lambda’s durable functions? The answer, as always, depends on the circumstances.

On the positive side, durable functions extend the serverless model for organizations already using Lambda, offering first-class support for Python (3.13, 3.14) and Node.js (22, 24), and integration with AWS’s CLI, SDK, and orchestration tools. They lower entry barriers for teams already familiar with AWS, simplifying app development that previously relied on container-based or traditional VM-driven architectures. Teams that prioritize agility, business logic, and rapid experimentation will likely realize significant value from durable functions’ abstraction of infrastructure and orchestration.

However, organizations must weigh the trade-offs of deepening serverless adoption, especially with proprietary abstractions like durable functions. Serverless models promote agility and efficiency, but can also increase vendor dependence. For example, migrating complex workflows from AWS Lambda durable functions to another cloud platform (or back to on-premises infrastructure) will be costly and complex because the code relies on AWS-specific APIs and orchestration that don’t translate directly to Microsoft Azure, Google Cloud, or open source options.

There’s also a broader architectural consideration. Serverless, by its very nature, expects statelessness and composability, but it also introduces new patterns for observability, testing, and operational troubleshooting. While AWS Lambda durable functions make workflow orchestration less burdensome, they also increase the “magic” that must happen behind the curtain, sometimes making debugging and understanding cross-step failures more challenging. Enterprisewide visibility, compliance, and cost control require investments in new monitoring practices and possibly some third-party or proprietary tools.

Pros and cons of serverless lock-in

Some in the cloud community have taken a myopic approach to vendor lock-in, sounding alarms at any whiff of proprietary technology adoption. In reality, completely avoiding lock-in isn’t practical, and seeking absolute portability can undermine access to genuine innovation, such as Lambda durable functions. The calculus should focus on risk management and exit strategies: Does the value delivered by automation, embedded error recovery, and operational efficiency justify the increased dependency on a specific cloud provider at this stage of your evolution?

For enterprises aggressively pursuing digital transformation, serverless and Lambda durable functions may align with near-term and medium-term goals, offering agility, lower overhead, and a better developer experience. However, investments in cloud-native features should balance current benefits with long-term flexibility. For extensive multicloud or future-proofing needs, consider encapsulating some application logic outside these proprietary serverless constructs or adopting architectures that decouple workflows from the cloud runtime.

Looking past the hype cycle

AWS Lambda durable functions are a significant innovation. For the right workloads, they dramatically raise the ceiling on what’s achievable with serverless. They help realize the original vision of serverless and enable developers to focus on business logic rather than distributed state management or infrastructure plumbing. However, they’re not a blanket prescription for all workloads, and they’re not exempt from the strategic concerns that have always accompanied rapid platform innovation.

Enterprise architects and leaders now face a familiar balancing act. The key is to recognize where Llambda durable functions deliver transformative value and where they risk pulling your architecture into a pattern that is hard to unwind later. As always, the best approach is a clear-eyed, strategic assessment guided by organizational priorities—never fad-driven adoption for its own sake.

To that end, enterprises considering AWS Lambda durable functions should weigh the following:

• The degree of vendor lock-in
• Migration costs
• The fit with existing skill sets and development workflows
• The maturity of monitoring and observability solutions
• Regulatory and compliance implications
• Total cost of ownership versus more portable or traditional alternatives

Wise adoption requires more than technical enthusiasm—it demands business and architectural discipline. AWS Lambda durable functions are a meaningful evolution for serverless, but they become truly transformative only in the context of an informed, balanced enterprise strategy.

GitHub Copilot is one of the more mature AI assistants in use, having begun life as a way to use AI tools for code completion. Since then, Copilot has added features, becoming a resource for coordinating and orchestrating a wide variety of development-focused agents and services. Part of that development has been making Copilot available everywhere developers are: inside the browser, in your code editor, and now, with the Copilot CLI, in your terminal.

GitHub Copilot is especially useful when combined with Microsoft services like the Work IQ MCP server, enabling you to build prompts that combine code with specifications, and more importantly, with the discussions that take place outside traditional development environments. A missed email may hold a key feature request or an important user story. Using the Copilot CLI and Work IQ to surface the requirement and convert it into code helps reduce the risk of later rework and ensures that a project is still aligned to business needs.

Having GitHub Copilot at your fingertips is surprisingly helpful, but it does require switching context from application to terminal and back again. With it embedded in Visual Studio and Visual Studio Code, that isn’t too much of a problem, but what if you wanted to take that model and implement it inside your own applications? Building an agent command-and-control loop isn’t easy, even if you’re using platforms like Semantic Kernel.

Introducing the GitHub Copilot SDK

This is where the new GitHub Copilot SDK offers a solution. If you’ve got the Copilot CLI binaries installed on your device, whether it’s Windows, macOS, or Linux, then you can use the SDK (and the CLI’s own JSON APIs) to embed the Copilot CLI in your code, giving you access to its orchestration features and to GitHub’s Model Context Protocol (MCP) registry. Having an integrated registry simplifies the process of discovery and installation for MCP servers, quickly bringing new features into your agent applications.

When your code uses the GitHub Copilot SDK with the CLI, it’s using it as a server. This lets it run headless, so you won’t see the interactions between your code and the underlying agents. You don’t need to run the CLI on devices running GitHub Copilot SDK applications; thanks to remote access, you can install it on a central server. Users will still need a GitHub Copilot license to use GitHub Copilot SDK applications though, even if they’re working against a remote instance.

The SDK lets you treat the Copilot CLI server as a tool for executing and managing models and MCP servers instead of having to build your own, which simplifies development significantly. Running the CLI in server mode is a simple matter of launching it as a server and defining the port used for prompting. You can then use the fully qualified domain name of the machine running the server and the defined port as a connection string.

Once the CLI is installed, add the appropriate SDK dialect. Official support is provided for JavaScript and TypeScript via Node.js, .NET, Python, and Go. Node support is hosted in npm, .NET in NuGet, and Python in pip. For now, the Go SDK can be found in the project’s GitHub repository and can be installed using Go’s get command. It’s a fast-moving project, so be sure to regularly check for updates.

Using the GitHub Copilot SDK

Calling the SDK is simple enough. In .NET you start by creating a new CopilotClient and adding a session with a support model before sending an asynchronous session message to the Copilot CLI containing a prompt. The response has the agent’s answer and can then be managed by your code.

This is one of the simplest ways to interact with a large language model (LLM) from your code, with similar approaches used in other languages and platforms. You’ll need to write code to display or parse the data returned from the SDK, so it’s useful to build base prompts in your code that can force the underlying GitHub Copilot LLM to return formats that can be parsed easily.

The default is to wait for Copilot CLI to return a complete response, but there’s support for displaying response data as it’s returned by adding a streaming directive to the session definition. This approach can be helpful if you’re building an interactive user experience or where LLM responses can take time to generate.

Like Semantic Kernel and other agent development frameworks, the GitHub Copilot SDK is designed to use tools that link your code to LLMs, which can structure calls to data that Copilot will convert to natural language. For example, you could build a tool that links to a foreign exchange platform to return the exchange rate between two currencies on a specific date, which can then be used in a Copilot SDK call, adding the tool name as part of the session definition.

Using tools and MCP servers

Tools are built as handlers linked to either local code or a remote API. Working with API calls allows you to quickly ground the LLM and reduce the risks associated with token exhaustion. Once you have a tool, you can have an interactive session allow users to build their own prompts and deliver them to the grounded LLM as part of a larger application or as a task-specific chatbot in Teams or another familiar application.

You don’t have to write your own tool; if you’re working with existing platforms and data, your SDK code can call an MCP server, like the one offered by Microsoft 365, to provide quick access to larger data sources. As the GitHub Copilot SDK builds on the capabilities of the Copilot CLI, you can start by defining a link to the relevant MCP endpoint URLs and then allow the tool to call the necessary servers as needed. An application can include links to more than one MCP server, so linking Work IQ to your GitHub repositories bridges the gap between code and the email chains that inspired it.

MCP servers can be local or remote, using HTTP for remote connections and stdio for local. You may need to include authorization tokens in your MCP server definition, as well as accepting all its tools or choosing specific tools for your GitHub Copilot SDK agent to use.

Other options for the SDK agent session include defining a base prompt for all queries to help avoid inconsistencies and to provide some context for interactions outside of the user prompt. Different agents in the same application can be given different base prompts and separate names for separate functions. A local MCP server might give your application access to a PC’s file system, while a remote server might be GitHub’s own one, giving your application access to code and repositories.

You’re not limited to the official language support. There are community releases of the SDK for Java, Rust, C++, and Clojure, so you can work with familiar languages and frameworks. As they’re not official releases, they may not be coordinated with GitHub’s own SDKs and won’t have the same level of support.

Working in the Microsoft Agent Framework

Usefully, the Microsoft Agent Framework now supports the GitHub Copilot SDK, so you can integrate and orchestrate its agents with ones built from other tools and frameworks, such as Fabric or Azure OpenAI. This lets you build complex AI-powered applications from proven components, using Agent Framework to orchestrate workflow across multiple agents. You’re not limited to a single LLM, either. It’s possible to work with ChatGPT in one agent and Claude in another.

Tools like the GitHub Copilot SDK are a useful way to experiment with agent development, taking the workflows you’ve built inside GitHub and Visual Studio Code and turning them into their own MCP-powered applications. Once you’ve built a fleet of different single-purpose agents, you can chain them together using higher-level orchestration frameworks, thereby automating workflows that bring in information from across your business and your application development life cycle.

The impacts of AI are mostly viewed through the lens of improving business processes, but AI is poised to have long-term impacts on engineering too. Not only can AI make it easier for engineers to bring their ideas to life, but it can also remove the burden of manual toil that keeps them from focusing on more business-critical issues. The growing integration of AI into engineering workflows will drive both engineering efficiencies and business advantages as teams continue to unlock valuable use cases.

Here are three ways AI will bring long-lasting change to engineering practices.

AI will accelerate prototype building and idea validation

For teams assessing their current architectures and gauging where they want to be in the next few years, AI can help identify the changes they would need to make and the prototypes they would need to build. An engineer may compile bullet points to map out their thought process, which can then serve as the initial AI prompt to assist in building out the plan. The feedback generated from the AI prompts can enable teams to make decisions faster and get into the proof-of-concept stage at an accelerated pace.

AI can also help engineers become more efficient by directing them where to begin research. For example, when building a chat UI, AI can identify various factors the engineer needs to think through, such as performance and network considerations, and create a list of recommended actions. As a result, teams can get a head start on their projects and ultimately get to solutions faster.

AI will increase the importance and quality of documentation

It’s important to remember that AI tools need direction, and they’re only as good as the data they’re trained on. If the AI doesn’t have good input, it can’t create good output.

The industry will move toward stronger documentation practices because of how AI works. In order for the AI to perform as desired, organizations need proper, up-to-date documentation to prevent the AI from making incorrect assumptions. Well-formed prompts that are focused on an outcome, and that give the AI easier ways to discover the documentation, make a significant difference in performance because these prompts can give the AI stronger context and direction to work with.

Plus, AI can be leveraged to ensure that technical documentation is kept up-to-date and relevant. Similar to prototyping, engineers can automate the initial stages of documentation to help reduce the amount of time they spend on it. The engineer can then use their expertise to review and refine the AI-produced documentation, further guiding the AI toward the correct results.

AI will increase the focus on compliance

Compliance remains an ongoing challenge for organizations as they navigate data and privacy regulations around the world, including GDPR and SOC 2. Maintaining compliance is crucial to avoiding costly fines and penalties from regulatory bodies, but also to protect the organization from potential reputational damage. AI use exposes a new liability as organizations are now challenged with managing the data it can access.

As organizations feed sensitive company and customer data into their AI tools, they need to ensure that the data stays within these systems. Teams need to maintain visibility into how accessible the AI data is internally, as well as what other tools may be exposed to it. Additionally, strong guardrails and security permissions must be established to prevent any unauthorized access or use of customer data. While every organization is eager to deploy AI, they need to be vigilant around the level of data access they grant these tools.

The future of engineering

The ongoing integration of AI will transform the ways engineers work. They can kick off their projects faster and offload their more boring and tedious tasks, freeing them to focus on the higher-impact issues that require human expertise. Between speeding up prototype building and increasing productivity, engineers will be empowered to find more ways to leverage AI as they continue to guide their organizations toward innovation. 

—

New Tech Forum provides a venue for technology leaders—including vendors and other outside contributors—to explore and discuss emerging enterprise technology in unprecedented depth and breadth. The selection is subjective, based on our pick of the technologies we believe to be important and of greatest interest to InfoWorld readers. InfoWorld does not accept marketing collateral for publication and reserves the right to edit all contributed content. Send all inquiries to doug_dineley@foundryco.com.

Wasmer has released Wasmer 7, an upgrade of its WebAssembly runtime that introduces an experimental async API that enables full async support in Python. The update also brings support for dynamic linking to WASIX, broadening the platform’s support for Python packages.

Introduced January 30, Wasmer 7 introduces an experimental async API that offers first-class support for async functions in Python, unlocking powerful libraries such as SQLAlchemy and other Python packages that previously could not run, Wasmer said. The async API currently is available across the Singlepass, Cranelift, and LLVM back ends.

Wasmer 7 also enables support for dynamic linking in WASIX, the platform’s extension to WASI (WebAssembly System Interface), which unlocks support for a much broader ecosystem of Python packages and native modules, Wasmer said. Support for dynamic linking in WASIX removes a situation in which Python support in Wasmer was limited to the core interpreter, with many native libraries, such as Numpy or Pydantic, remaining unsupported. Wasmer 7 removes this limitation.

Wasmer 7 also upgrades the Cranelift compiler to the latest release and adds full support for WebAssembly exceptions using Cranelift’s new exception-handling APIs. To enable this, Wasmer’s builders integrated with the standard libunwind library, filling in missing pieces as the Cranelift compiler relies on its own unwinding implementation. By doing this, Wasmer uses the same unwinding mechanism for all compilers using WebAssembly exceptions.

Also in Wasmer 7, Wasmer now displays a compilation progress bar when building a module for the first time using the more heavy-duty LLVM compiler. In addition, when building large packages such as Python or PHP, optimizations are selectively disabled for extremely large functions, resulting in significantly faster compile times. For example, Python builds drop from ~90s to ~10s.

And Wasmer 7 bolsters RISC-V support with the addition of support for Singlepass. Previous Wasmer releases have supported RISC-V through LLVM and Cranelift. Wasmer 7 also introduces the LLVM RV32gc target.

The software industry is collectively hallucinating a familiar fantasy. We visited versions of it in the 2000s with offshoring and again in the 2010s with microservices. Each time, the dream was identical: a silver bullet for developer productivity, a lever managers can pull to make delivery faster, cheaper, and better. Today, that lever is generative AI, and the pitch is seductively simple: If shipping is bottlenecked by writing code, and large language models can write code instantly, then using an LLM means velocity should explode.

But software development has rarely been constrained by typing speed. The bottleneck is almost always everything except typing: deciding what to build, aligning on an approach, integrating it into an ecosystem that already exists, getting it through security and compliance, and then operating what you shipped.

AI can help with syntax, scaffolding, and the drudgery of boilerplate. It can also make a different problem much worse: It makes complexity cheap. So how do we tackle that problem? The answer is platforms. Or paved roads. Or golden paths. Whatever the term, the impact is the same: By giving developers guardrails, we can dramatically improve their productivity across the enterprise.

Production versus productivity

The evidence so far is useful precisely because it refuses to tell a single comforting story. A randomized controlled trial from METR, for example, found that experienced open source developers, working in complex repositories they already knew, took about 19% longer to complete tasks when using AI tools, even while believing they would be faster. In a very different setting, GitHub reported that developers using GitHub Copilot completed a specific, isolated programming task substantially faster in a controlled experiment and also felt better about the experience.

So which is it? Is AI a turbocharger or an anchor? The answer is yes, and that ambiguity is the point. Put AI into a healthy system and it can compound speed. Put AI into a fragmented system and it can compound chaos. The outcome depends less on which model you pick and more on the environment you allow that model to operate in. “AI makes developers productive” is not a tool claim—or it shouldn’t be. It is a systems claim.

That environment problem is not new. Years before prompt engineering became a job title, I argued that unfettered developer freedom was already colliding with enterprise reality. Freedom feels like agility until it becomes sprawl, fragmentation, and an integration tax nobody budgeted for. Generative AI does not reverse that dynamic. It accelerates it because it removes the friction that used to slow down bad decisions.

This is where leadership teams keep making the same fundamental error: They confuse production with productivity. If you define productivity as “shipping more code,” AI is the greatest invention in our lifetime. But in production, code is not an asset in isolation. Code is a liability you must secure, observe, maintain, and integrate. Every new service, dependency, framework, and clever abstraction adds surface area, and surface area turns speed into fragility.

AI lowers the cost of creating that surface area to near zero. In the past, bad architectural decisions were limited by how long it took to implement them. Now a junior engineer can generate a sprawling set of services and glue them together with plausible code they do not fully understand because the assistant handled the implementation details. The team will be proud of their speed right up until the first time the system has to be audited, patched, scaled, or handed to a different team.

At that point, the supposed productivity win shows up as an operating cost.

If you want to talk about developer productivity in the AI era, you have to talk about delivery performance. The DORA metrics remain a stubborn reality check because they measure throughput and stability rather than volume: lead time for changes, deployment frequency, change failure rate, and time to restore. The SPACE framework is also useful because it reminds us that productivity is multidimensional, and “feels faster” is not the same as “is faster.” AI often boosts satisfaction early because it removes drudgery. That matters. But satisfaction can coexist with worse performance if teams spend their time validating, debugging, and reworking AI-generated code that is verbose, subtly wrong, or inconsistent with internal standards. If you want one manager-friendly measure that forces honesty, track the time to compliant deployment: the elapsed time from work being “ready” to actual software running in production with the required security controls, observability, and policy checks.

This is the part the industry still tries to dance around: AI makes the freedom problem worse. Gergely Orosz argues that as AI writes more of the code, engineers move up the abstraction ladder. The job shifts from writing to reviewing, integrating, and making architectural choices. That sounds like a promotion. Hurray, right? Maybe. In practice, it can be a burden because it assumes a level of systems understanding that is unevenly distributed across a team.

Compounding the problem, when creation becomes cheap, coordination becomes expensive. If you let every team use AI to generate bespoke solutions, you end up with a patchwork quilt of stacks, frameworks, and operational assumptions. It can all look fine in pull requests and unit tests, but what happens when someone has to integrate, secure, and operate it? At that point, the organization slows down, not because developers cannot type, but because the system cannot cohere.

Paved roads and platforms

Forrester’s recent research hits this nail on the head. They argue that architecture communities are the “hidden engine of enterprise agility.” This isn’t about re-establishing the ivory tower architects of the service-oriented architecture era who drew diagrams nobody read. It is about preventing the massive tax of integration workarounds. Forrester suggests that without coordination, architects spend up to 60% of their time just trying to glue disparate systems together rather than innovating. AI, left unchecked, will push that number to 90%.

The solution is not to ban AI, nor is it to let it run wild. The solution is to pave the road. I have written extensively about the need for golden paths. A golden path, or “paved road” in Netflix parlance, is an opinionated, supported route to production. It is a set of composable services, templates, and guardrails that make the right way of building software also the easiest way.

In the AI era, the golden path is non-negotiable. The cognitive load on developers is already too high; asking them to choose libraries, models, prompting strategies, and RAG architectures is a recipe for burnout. Your platform team must standardize the boring parts.

Imagine two scenarios. In the first, a developer asks an AI to build a microservice. The AI scans the internet, picks a random framework, and writes code that complies with zero of your company’s security policies. The developer feels fast for 10 minutes, then spends a week fighting the security review.

In the second scenario, the developer is on a golden path. The AI is constrained to use the internal templates. It generates a service that comes pre-wired with the company’s authentication, logging sidecars, and deployment manifests. The code it writes is boring. It is compliant. And it deploys in 10 minutes. In this model, the productivity win didn’t come from the AI’s ability to write code. It came from the platform’s ability to constrain the AI within useful boundaries.

The most productive developers of the next decade won’t be the ones with the most freedom. They will be the ones with the best constraints, so they can stop worrying about the plumbing and focus on the problem. If you’re a development lead, your job is to help create constraints that enable, rather than stifle, productivity.

AI agent development is off to the races. A 2025 survey from PwC found that AI agents are already being adopted at nearly 80% of companies. And, these agents have an insatiable lust for data: 42% of enterprises need access to eight or more data sources to deploy AI agents successfully, according to a 2024 Tray.ai study.

“AI relies on data, and since 90% of data today is unstructured, it is important to create an effective interface for AI agents to get the right enterprise data,” says Or Lenchner, CEO of Bright Data, a web data collection platform.

We’ve seen large language models (LLMs) become more informed with retrieval-augmented generation (RAG) techniques, in which AI systems pull in external sources before generating a response. More recently, a new class of scraping and browser automation tools has emerged that can mirror human-like behavior on the web.

Web MCP, for instance, is a Model Context Protocol (MCP) server that can enable AI agents to circumvent CAPTCHAs, perform on-screen browser automation, and scrape real-time data from public web sources. Other tools, including MCP servers, browser automation frameworks, and scraping APIs, offer similar capabilities. These include Browser Use, Playwright, Puppeteer, ScrapingBee, and Apify, among others.

ChatGPT, Gemini, and Claude were trained in part on publicly available web content, and they can retrieve current web information at run time using retrieval or browsing tools. Official APIs, on the other hand, are often pricey, are rate-limited, and require onboarding time. So, why shouldn’t agents scrape whatever’s online as their primary data source?

Well, anyone acquainted with social media knows that public data is riddled with inaccuracy, bias, and harmful content. Although scraping offers quick, free, and universal access, it’s highly problematic. After all, it’s contingent on public pages or applications that were designed for human consumption, not machine readability.

APIs, on the other hand, guarantee more structure and stability via authenticated access to internal and private integration points.

So, an age-old conundrum resurfaces for AI agent builders: to scrape or integrate. And like most technical dichotomies, it depends—both come at a cost. Below, we’ll weigh the pros and cons of each, taking a pragmatic approach to determine which is the best course of action, and when.

Why agents need external data

AI agents often need to perform tasks that require access to data. For this, an AI knowledge base can provide internal institutional context. But an internal knowledge base is rarely enough, and external data is often necessary to deliver real value.

“Agents without live external data are frozen at training time,” says Bright Data’s Lenchner. “They can’t reason about today’s prices, inventory, policies, research, or breaking events.”

Agents benefit from real-time information ranging from publicly accessible web data to integrated partner data. Useful external data might include product and inventory data, shipping status, customer behavior and history, job postings, scientific publications, news and opinions, competitive analysis, industry signals, or compliance updates, say the experts.

With high-quality external data in hand, agents become far more actionable, more capable of complex decision-making and of engaging in complex, multi-party flows. “This unlocks autonomous operations,” says Deepak Singh, CEO and co-founder of AvairAI, creators of an AI agent for sales teams.

Real-time external data connections can open up a wide range of autonomous actions that produce tangible outcomes, including:

• Approving loans with real-time credit verification
• Verifying compliance documents
• Validating customer information across systems
• Incorporating market sentiment into financial reviews
• Coordinating delivery based on real-time traffic or warehouse capacity
• Personalizing responses based on individual user preferences

“It’s not just about giving agents more data,” says Neeraj Abhyankar, VP of data and AI at R Systems, a digital product engineering company. “It’s about giving them the right data at the right time to provide the best possible outcomes.” 

When to scrape website data for AI agents

So, how should agents retrieve external data? One approach is scraping public web sources, such as social media feeds or product catalogs. This typically involves scraping tools, browser automation, or proxy networks that extract data from the HTML of public websites.

According to Lenchner, the advantages of scraping are breadth, freshness, and independence. “You can reach the long tail of the public web, update continuously, and avoid single‑vendor dependencies,” he says. 

Today’s scraping tools grant agents impressive control, too. “Agents connected to the live web can navigate dynamic sites, render JavaScript, scroll, click, paginate, and complete multi-step tasks with human‑like behavior,” adds Lenchner.

Scraping enables fast access to public data without negotiating partnership agreements or waiting for API approvals. It avoids the high per-call pricing models that often come with API integration, and sometimes it’s the only option, when formal integration points don’t exist.

“Many vendors are locking down access to user-generated data behind expensive APIs, and scraping allows alternate paths,” says Gaurav Pathak, vice president of AI and metadata at Informatica, a cloud data management provider.

However, scraping has plenty of drawbacks, starting with data quality. “Preprocessing scraped data can be messy and inexact,” says Keith Pijanowski, AI and ML solutions engineer at MinIO, a data infrastructure company for AI.

“It’s building on quicksand,” says AvairAI’s Singh. “Websites change layouts without notice, breaking your scrapers. You’re violating the terms of service, risking legal action. Rate limiting and CAPTCHAs create constant technical battles.”

The lack of schema, context, and data validation also increases the risk of agents collecting the wrong public data, leading to wasted engineering effort. “We’ve seen enterprises spend more money maintaining scrapers than they would on proper integrations,” adds Singh.

Others highlight the legal exposure as well. “Enterprises are hesitant to use AI produced via scraping because of the liability they could end up inheriting through derivative works,” says Krishna Subramanian, co-founder and COO of Komprise, provider of an intelligent data management platform.

Because of its fragility, scraping is often a poor fit for core production-grade agentic systems that require consistent, compliant results. Instead, it’s best reserved for use in peripheral areas like:

• Proof-of-concepts
• Non-critical data
• Competitive market research
• Legal aggregation of clearly public data
• Side projects
• When no integration points exist

When to integrate data for AI agents through APIs

Another option is for agents to retrieve external data through official integration points. This includes structured responses via REST, GraphQL, or SOAP-based APIs, event-driven updates through webhooks, or via official MCP servers.

While integrations incur more upfront setup than scraping, they generally deliver higher data quality and avoid legal troubles. They’re also more predictable: APIs are typically specification-driven, backed by service-level agreements (SLAs), and versioned to minimize breaking changes.

“Relying on official integrations can be positive because it offers high-quality, reliable data that is clean, structured, and predictable data through a stable API contract,” says Informatica’s Pathak. “There is also legal protection, as they operate under clear terms of service, providing legal clarity and mitigating risk.” 

“Official integrations via APIs, webhooks, or secure file transfers offer stability, traceability, and compliance,” adds R Systems’ Abhyankar, noting that reliable data exchange is especially important for auditability in health care and financial services.

Others underline the importance of stability for enterprise-grade agent experiences. “When your agent makes a million-dollar decision, you want data you can trust and vendors you can hold accountable,” says AvairAI’s Singh. “Official integrations provide the stability enterprises need.”

On the flip side, official integrations carry some drawbacks that limit their usefulness for broader AI use cases. Platform owners might constrain API access with rigid data models or bespoke rate limits. “APIs may omit fields that are publicly visible on the web, deliver delayed data, and can revoke access at any time,” says Lenchner.

On top of that, time and politics can be a drawback, particularly for deep partner integrations. “Getting API access can take months of partnership negotiations,” adds Singh.

Even when access is granted, it’s not set in stone. Over the years, developers have witnessed API restrictions or closures from public platforms such as Instagram, Slack, Salesforce, Bing, Reddit, Spotify, Marvel, and plenty of others. Some data providers don’t offer real-time APIs at all, relying instead on batch-based SFTP file transfers.

Cost is another concern. “Cost is the biggest drawback, as quality data will almost certainly come with a high price tag,” says MinIO’s Pijanowski. To his point, sudden API price hikes by platforms like X or Google Maps have historically driven developers toward workarounds.

Official integrations also require custom development and maintenance per API, along with additional authentication and authorization configuration. Still, most experts can stomach the trade-offs in exchange for better reliability, governance, and compliance.

Compared to scraping, official integrations are a more mature and controlled form of data acquisition, making them a better fit for agentic scenarios that span:

• Mission-critical operations
• Partner ecosystems
• Situations that need long-term consistency
• Transactional workflows that don’t require public data
• Governed enterprise applications that require SLAs
• Financial and health care data
• Personally identifiable information (PII)

Choosing between scraping and API integration for agents

AI agents now cover a wide array of use cases, from customer help desks to business workflows and coding assistants. Likely due to this diversity, nearly half of organizations deploy between six and 20 types of AI agents, according to Salt Security’s 2025 AI Agents Report.

Furthermore, the use of agents is spread quite evenly by sector. A 2025 McKinsey study found that AI agents are most commonly used in IT and knowledge management. By industry, agentic AI adoption is highest among professionals in technology, media and telecommunications, and health care.

Because AI agents span different purposes, domains, and industries, it’s hard to pin down a single data strategy that fits every scenario. That said, experts point to clear cases where one approach makes more sense than the other.

If you’re operating in a partner’s ecosystem, using non-public sources, and working with financial data or health care data, official integrations are the clear choice, hands down. But if you’re a startup that relies on ingesting current news, market signals, or social media, it’s a different story.

That’s not to say that scraping is the only—or even the best—way to access public data. For instance, as The Register reports, major AI companies consume Wikipedia’s public data corpus via the Wikimedia Foundation’s enterprise-grade APIs. At the same time, Cloudflare’s announcement to block AI crawlers by default suggests a broader industry shift toward controlled access, and away from unrestricted scraping.

Another way to frame the dichotomy is risk tolerance. “If errors could cost money, reputation, or compliance, use official channels,” says Singh. “If you’re enhancing decisions with supplementary data, scraping might suffice.”

Viewed this way, web scraping becomes more of a tag-along enhancement for AI agents—a way to add contextual, hard-to-integrate public data when legally permissible. Whereas traditional integrations represent the core, trustworthy source of truth that guides real-world actions and autonomous decision-making.

Hybrid approaches and middleware are also emerging to manage both paths. “We’ve built agentic layers that dynamically switch between scraping and integrations depending on context,” says Abhyankar, noting that agents may use public data for visibility while relying on APIs for internal synchronization.

Where will you build your house?

As agentic AI proliferates, the data strategy behind it is coming more into focus. How developers hardwire data access into agents will directly affect accuracy, reliability, and compliance for the long term.

“When collecting external data, it’s not about choosing one method over another,” says Abhyankar. “It’s about aligning the data strategy with business goals, operational realities, and compliance requirements.”

Official integrations are purpose-built for enterprise use and provide better support for governance, auditing, and enforcement. “This is a better long-term strategy because it is well-architected for enterprise consumption,” says Komprise’s Subramanian.

Others agree, arguing that the structured approach affords better foundations than the quicksand of scraping. As Singh puts it, “Betting your operations on scraping is like building your house on someone else’s land without permission.” 

“Access isn’t enough,” he stresses. “You need trusted, accurate, real-time data.” 

There’s a lot of hype about AI coding tools and the gains developers are seeing when it comes to speed and accuracy. But are developers also offloading some of their thinking to AI when they use them as copilots?

Anthropic researchers recently put this to the test, examining how quickly software developers picked up a new skill (learning a new Python library) with and without AI assistance, and, more importantly, determining whether using AI made them less likely to actually understand the code they’d just written.

What they found: AI-assisted developers were successfully performing new tasks, but, paradoxically, they weren’t learning new skills.

This isn’t particularly surprising, according to real-world software engineers. “AI coding assistants are not a shortcut to competence, but a powerful tool that requires a new level of discipline,” said Wyatt Mayham of Northwest AI Consulting.

AI users scored two letter grades lower on coding concepts

In a randomized, controlled trial, a group of 52 “mostly junior” developers were split into two groups: One was encouraged to use AI, one denied its use, performing a short exercise interacting with the relatively new asynchronous Python Trio library that involved new concepts beyond just Python fluency. The chosen engineers were familiar with both Python and AI coding assistants, and had never used the Trio library.

Researchers then quizzed them on their mastery of debugging and code reading and writing, as well as their ability to understand core tool and library principles to help them assess whether AI-generated code follows appropriate software design patterns.

The results: The AI-using group scored 17 percentage points lower on the quiz than a control group who coded by hand — that is, 50% compared to 67%, or the equivalent of nearly two letter grades. This was despite the quiz having covered concepts they’d used just a few minutes before.

Notably, the biggest gaps in mastery were around code debugging and comprehension of when code is incorrect and why it fails. This is troubling, because it means that humans may not possess the necessary skills to validate and debug AI-written code “if their skill formation was inhibited by using AI in the first place,” the researchers pointed out.

The experiment in depth

The 70-minute experiment was set up like a self-guided tutorial: Participants received a description of a problem, starter code, and a quick explainer of the Trio concepts required to solve it. They had 10 minutes to get familiar with the tool and 35 minutes to perform the task of coding two different features with Trio. The remaining 25 minutes was devoted to the quiz.

They were encouraged to work as quickly as possible using an online coding platform; the AI group could access a sidebar-embedded AI assistant that could touch code at any point and produce correct code if asked. The researchers took screen recordings to see how much time participants spent coding or composing queries, the types of questions they asked, and the errors they made.

Interestingly, using AI didn’t automatically guarantee a lower score; rather, it was how the developers used AI that influenced what skills and concepts they retained.

Developers in the AI group spent up to 30% of their allotted time (11 minutes) writing up to 15 queries. Meanwhile, those in the non-AI group ran into more errors, mostly around syntax and Trio concepts, than the AI-assisted group. However, the researchers posited that they “likely improved their debugging skills” by resolving errors on their own.

AI group participants were ranked based on their level and method of AI use. Those with quiz scores of less than 40% relied heavily on AI, showing “less independent thinking and more cognitive offloading.” This group was further split into:

• AI delegators: These developers “wholly relied” on AI, completing the task the fastest and encountering few or no errors;
• ‘Progressive’ AI users: They started out proactively by asking a few questions, then devolved into full reliance on AI;
• Iterative AI debuggers: They also asked more questions initially, but ultimately trusted AI to debug and verify their code, rather than clarifying their understanding of it.

The other category of users, who had quiz scores of 65% or higher, used AI for code generation as well as conceptual queries, and were further split into these groups:

• Participants who generated code, manually copied and pasted it into their workflows, then asked follow-up questions. They ultimately showed a “higher level of understanding” on the quiz.
• Participants who composed “hybrid queries” asking for both code and explanations around it. This often took more time, but improved their comprehension.
• Participants who asked conceptual questions, then relied on their understanding to complete the task. They encountered “many errors” along the way, but also independently resolved them.

“The key isn’t whether a developer uses AI, but how,” Mayham emphasized, saying these findings align with his own experience. “The developers who avoided skill degradation were those who actively engaged their minds instead of passively accepting the AI’s output.”

Interestingly, developers in the experiment were aware of their own habits. While the non-AI-using participants found the task “fun” and said they had developed an understanding of Trio, AI-using participants said they wished they had paid more attention to the details of the Trio library, either by reading the generated code or prompting for more in-depth explanations.

“Specifically, [AI using] participants reported feeling ‘lazy’ and that ‘there are still a lot of gaps in (their) understanding,’” the researchers explained.

How developers can keep honing their skills

Many studies, including Anthropic’s own, have found that AI can speed up some tasks by as much as 80%, however, this new research seems to indicate that sometimes speed is just speed — not quality. Junior developers who feel they have to move as quickly as possible are risking their skill development, the researchers noted.

“AI-enhanced productivity is not a shortcut to competence,” they said, and the “aggressive” incorporation of AI into the workplace can have negative impacts on workers who don’t remain cognitively engaged. Humans still need the skills to catch AI’s errors, guide output, and provide oversight, the researchers emphasized.

“Cognitive effort — and even getting painfully stuck — is important for fostering mastery,” they said.

Managers should think “intentionally” when they deploy AI tools to ensure engineers continue to learn as they work, the researchers advised. Major LLM providers provide learning environments, such as Anthropic’s Claude Code Learning and Explanatory modes, or OpenAI’s ChatGPT Study Mode, to assist.

From Mayham’s perspective, developers can mitigate skill atrophy by:

• Treating AI as a learning tool: Ask for code and explanations. Prompt it with conceptual questions. “Use it to understand the ‘why’ behind the code, not just the ‘what,’” he advised.
• Verifying and refactoring: “Never trust AI-generated code implicitly.” Always take the time to read, understand, and test it. Oftentimes, the best learning comes from debugging or improving AI-provided code.
• Maintaining independent thought: Use AI to augment workflow, not replace the thinking process. “The goal is to remain the architect of the solution, with the AI acting as a highly-efficient assistant,” said Mayham.

AI-driven productivity is not a substitute for “genuine competence,” especially in high-stakes, safety-critical systems, he noted. Developers must be intentional and disciplined in how they adopt tools to ensure they’re continually building skills, “not eroding them”. The successful ones won’t just offload their work to AI, they’ll use it to ask better questions, explore new concepts, and challenge their own understanding.

“The risk of skill atrophy is real, but it’s not inevitable. It’s a choice,” said Mayham. “The developers who will thrive are those who treat AI as a Socratic partner for learning, not a black box for delegation.”

Google has added Conversational Analytics to its BigQuery data warehouse, which it says will allow enterprise data teams and business users to ask questions about data in natural language, in turn speeding up data analytics for AI use cases.

The agent, currently in preview, can be found under the Conversations tab in the new Agents Hub inside BigQuery and activated by pointing to data tables. It expands the data warehouse’s current text-to-SQL capabilities, analysts say.

“BigQuery already offers features like data canvas to make query generation and visual exploration easier. What changes with the agent is not the ability to ask questions in simple language, but the ability to carry a contextual conversation with the data over multiple steps, which can be defined as conversational analytics,” said Abhisekh Satapathy, principal analyst at Avasant.

“Instead of treating each prompt as a one-off request, the new agent remembers what was asked earlier, including datasets, filters, time ranges, and assumptions, and uses that context when answering follow-up questions. This lets users refine an analysis progressively rather than starting from scratch each time,” Satapathy added.

Satapathy pointed out that this eases the pressure on developers to prebuild dashboards or predefined business logic for every possible question that a data analyst or business user could ask.

“Rather than encoding every scenario upfront, teams can let the agent interpret user intent dynamically, while still enforcing access controls, metric definitions, and governance rules already defined in BigQuery,” he said.

Ability to build and deploy custom agents via API endpoints

In addition to the agent, Google has also added tools to build, deploy, and manage custom agents across applications and operational workflows via API endpoints to the Agent Hub.

These tools, according to Satapathy, address three practical enterprise needs: “It reduces duplication of analytics logic across tools, ensures consistent definitions and policies across all analytics users, and centralizes access control and auditing rather than implementing them separately in each application.”

The reduction in duplication also frees up developers as they no longer have to rebuild logic to interpret user questions, map them to datasets, apply security rules, or explain results, Satapathy added.

Custom agents can also be deployed via Looker, which has a built-in conversational analytics feature.

Continued Text-to-SQL improvements

Over the past few months, Google has been adding natural language and SQL abilities to BigQuery to help developers and data analysts with SQL querying.

Earlier this month, it previewed a Comments to SQL feature that is aimed at enabling developers and data analysts to write natural-language instructions in SQL comments and have them translated into executable queries inside BigQuery Studio via Gemini.

Last November, Google added three new managed AI-based SQL functions — AI.IF, AI.CLASSIFY, and AI.SCORE — to help enterprise users reduce the complexity of running large-scale analytics, especially on unstructured data. In August, Google made incremental updates to the data engineering and data science agents in BigQuery.

Rivals, such as Snowflake and Databricks, have also been prepping natural language to SQL capabilities for their offerings.

While Databricks already offers AI Functions that can be used to apply generative-AI or LLM inference directly from SQL or Python, Snowflake provides AI_PARSE_DOCUMENT, AISQL, and Cortex functions for document parsing, semantic search, and AI-driven analytics. Other warehouses, such as Oracle’s Autonomous Data Warehouse, also support AI workflows alongside SQL.

I am loath to inform you that the first month of 2026 has expired. We have now entered the second quarter of the 21st century. These are the opening acts of the millennium.

Fortunately, it looks like AI 2027 may not pan out and we may, as yet, avoid LLM doom. We almost definitely won’t have a superintelligence that absorbs the power grid for its own purposes. And furthermore, we will probably still have human programmers at the end of this year.

All good news. Also, it’s comforting to see that some things never change. This month’s report brings all kinds of interesting developments unfolding in the world of JavaScript, including TypeScript’s new type stripping feature, Angular’s more modern reactive workflow, and Hotwire, the HTMX-powered JSON alternative on the rise.

Top picks for JavaScript readers on InfoWorld

TypeScript levels up with type stripping
This is the biggest thing to hit TypeScript since its inception. No more source maps, and no more waiting to compile. By treating types as white space, modern runtimes like Node are unlocking a no-build TypeScript that keeps stack traces accurate and workflows clean.

Get started with Angular: Introducing the modern reactive workflow
Combining a more community-engaged development approach with impressive technical updates, Angular has quickly become one of the most interesting JavaScript projects to watch. Here’s a hands-on guide to modern JavaScript development with Angular.

Intro to Hotwire: HTML over the wire
Reclaim your developer experience by keeping the logic in one place, on the server. HTML-based Hotwire offers an articulate counterpoint to the complexity of modern SPAs, proving that sometimes the best way forward lies with the technologies of the past.

React tutorial: Get started with the React library
Despite the endless churn of new frameworks, React remains the quintessential reactive engine. This updated guide walks you through the fundamentals of React development, including a This is Spinal Tap variant on the canonical counter application. Sometimes, your components just need to go to 11.

More good reads and JavaScript updates elsewhere

jQuery 4. 0. 0: The library that refuses to die
Almost 20 years to the day since its debut, jQuery 4. 0 has landed. It’s not just a legacy patch; it’s a full migration to the ES modules, and a goodbye to IE 10. For those who remember when $ was the only way to keep the DOM under control, it’s comforting to see this fresh start for the web’s standard library.

Introducing the HTML element
Instead of a script-triggered action, is a declarative element. This is designed to be a UX and security improvement and it is available now, in the latest Chrome (144) release. Similar updates are planned for camera and microphone.

ChatGPT containers can now run bash, pip/npm install packages, and download files
Some way or another, the LLM and the IDE are going to merge. In fact, it seems like every purpose-built app is going to be Borged by AI, even if exactly how is yet to be discovered. These latest upgrades to ChatGPT’s sandboxed runtime container might raise a question or two.

The cloud isn’t new, but the way enterprises use it keeps evolving. AI workloads, new platform services, and tighter governance mean teams can’t rely on outdated knowledge. The real issue isn’t ignorance but drift. Assumptions once valid are now proven wrong through outages, security rework, or surprise bills.

That’s why free, on-demand courses have become strategically advantageous. They’re frictionless to start, easy to standardize across teams, and effective at establishing a shared vocabulary. If you can align hundreds of people on core concepts in a month without budget approvals, you can remove an enormous amount of organizational drag.

What to look for in free cloud courses

Most free training fails in one of two ways. It either turns into marketing content with a few diagrams or becomes a click-through tour of a console and doesn’t teach decision-making. When I evaluate a free course for enterprise use, I’m looking for content that changes how someone thinks, not just tells them what buttons to push. Here’s my criteria:

First, it must teach durable concepts that transfer across providers, topics such as regions and resiliency, identity boundaries, networking fundamentals, observability, and cost mechanics. A course that can’t explain why architectures break or why bills rise is not foundational training. It’s vendor orientation.

Second, it needs to be truly on-demand and modular. Enterprises don’t learn on a schedule; they learn between sprints and incidents. The most useful free training lets teams move quickly through familiar sections and slow down on unfamiliar material without losing coherence.

Third, I want a clear scope anchored to something recognizable, such as a blueprint for fundamentals certification or a well-structured learning path. This matters because “free content sprawl” is real; people watch a few random videos and think they’re trained. A structured path reduces gaps and makes completion measurable, which is why I like how Microsoft Learn organizes fundamentals content into a formal training path.

Fourth, the course should connect concepts to operations. Hands-on labs are great, but I’d rather see practical framing. If a course never addresses governance, identity, or shared responsibility in ways that align with real-world enterprise practices, it will foster false confidence.

Finally, freshness matters. Cloud platforms evolve continuously, and the best provider-run free training tends to stay current with the latest terminology and service direction. AWS, for example, positions AWS Skill Builder as a central portal for digital training, which is partly why its free catalog remains a common baseline in enterprises.

Are free courses better than paid?

Free courses tend to win on a time-to-value metric. You can enroll a whole team today, establish baseline literacy this week, and stop having unproductive debates about terminology in the next sprint. That is a real operational benefit. Fewer misunderstandings mean fewer design errors and fewer late-stage corrections.

Free courses are also scaled well for standardization. If your organization is rolling out a cloud center of excellence, a platform team, or a finops initiative, you need a common language. Paid training often trains individuals; free training can train the organization.

There’s another subtle advantage: Provider-authored fundamentals courses teach the provider’s “intended mental model.” That’s not the same as neutral truth, but it’s extremely useful when you’re building on that platform. It helps teams understand how the provider expects identity, networking, and service boundaries to be used, thereby reducing troubleshooting time and architectural friction.

Where paid courses still win

Paid training tends to outperform in depth and context. A good instructor-led course can compress months of trial and error into a week, especially in content areas such as architecture trade-offs, incident response, or security design. Also, paid programs frequently include curated labs, graded assessments, and real-time feedback. Free courses rarely provide those at the same level.

Paid courses can be especially valuable when you need a capability quickly for a high-stakes delivery. If you’re building a regulated workload, redesigning an identity model, or implementing a platform engineering program, the cost of getting it wrong dwarfs the cost of training. That’s when paying for course expertise can be the cheaper option.

But paying isn’t a guarantee of quality. Some paid offerings are simply extended versions of free material with better packaging. The most effective enterprise pattern is to use free, on-demand courses to establish a universal baseline, then spend the budget surgically on advanced topics where hands-on coaching and scenario work produce clear ROI.

Five free courses worth your time

In alphabetical order:

• AWS Cloud Practitioner Essentials via AWS Skill Builder is a reliable entry point to AWS fundamentals. It’s designed to build a baseline understanding of cloud concepts and explain how AWS frames core services and responsibility boundaries. Even in multicloud organizations, AWS fluency reduces confusion because AWS terminology often leaks into broader enterprise discussions.
• Google’s Cloud Computing Fundamentals course template on Google Skills offers a provider-specific fundamentals view, emphasizing compute options and how Google frames the platform. I like this course as either a primary path for Google Cloud shops or a secondary perspective for multicloud teams seeking to avoid provider tunnel vision.
• The Linux Foundation’s Introduction to Cloud Infrastructure Technologies is valuable because it grounds cloud learning in open source infrastructure concepts rather than a single hyperscaler’s service catalog. That matters when your enterprise includes Kubernetes, containers, and portability debates, because those issues live in the open source layer more than in the provider layer.
• Microsoft Learn’s Azure Fundamentals, particularly the training path focused on cloud concepts, is a strong option for teams in Microsoft-heavy environments. The material is self-paced and structured to support standardization across large groups. It also integrates governance themes early, which aligns with how Azure is adopted in many enterprises.
• Oracle’s “Learn Oracle for Free” path to becoming an OCI Foundations Associate belongs on the list because Oracle Cloud Infrastructure appears in real enterprise portfolios, particularly when Oracle workloads, commercial agreements, or specific performance needs influence platform choices. Oracle explicitly positions the path as free training aligned with foundational OCI knowledge. Even if you don’t standardize on OCI, understanding it helps when you inherit it through acquisitions or packaged enterprise systems.

Using courses in the enterprise

If you’re training one person, you can optimize for their learning style. If you’re training an enterprise, you should optimize for consistency and outcomes. The goal is not to create a population of hobbyists; it’s to reduce avoidable production errors and accelerate sound decision-making.

A practical approach is to select one primary provider course aligned with your dominant cloud, assign one alternate-provider fundamentals course to broaden thinking, and add the Linux Foundation option to anchor the team in portable concepts. You then reinforce the material internally with a short set of standards specific to your situation: What does good identity hygiene mean in your company? What do approved network patterns look like? What cost and resiliency checks must occur before production? Training creates the language; internal standards create the behavior.

Findings from a new study by Epoch AI, a non-profit research institute, appear to poke major holes in the notion that AI firms, and specifically OpenAI, will eventually become profitable.

The research paper  written by Jaime Sevilla, Hannah Petrovic and Anson Ho, suggests that while running an AI model may generate enough revenue to cover its own operating costs, any profit is outweighed by the cost of developing the next big model. So, it said, “despite making money on each model, companies can lose money each year.”

The paper seeks to answer three questions: How profitable is running AI models? Are models profitable over their lifecycle? Will AI models become profitable?

To answer question one, researchers created a case study they called the GPT-5 bundle, which they said included all of OpenAI’s offerings available during GPT-5’s lifetime as the flagship model, including GPT-5 and GPT-5.1, GPT-4o, ChatGPT, and the API, and estimated the revenue from and costs of running the bundle. All numbers gathered were based on sources of information that included claims by OpenAI and its staff, and reporting by media outlets, primarily The Information, CNBC, and the Wall Street Journal.

The revenue estimate, they said, “is relatively straightforward”. Since the bundle included all of OpenAI’s models, it was the company’s total revenue over GPT-5’s lifetime from August to December last year: $6.1 billion.

And, they pointed out, “at first glance, $6.1 billion sounds healthy, until you juxtapose it with the costs of running the GPT-5 bundle.” These costs come from four main sources, the report said, the first of which is inference compute at a cost of $3.2 billion. That number is based on public estimates of OpenAI’s total inference compute spend in 2025, and assumes that the allocation of compute during GPT-5’s tenure was proportional to the fraction of the year’s revenue generated in that period.

The other costs are staff compensation ($1.2 billion), sales and marketing ($2.2 billion) and legal, office, and administrative costs: $0.2 billion.

It’s all in the calculation

As for options for calculating profit, the paper stated, “one option is to look at gross profits. This only counts the direct cost of running a model, which in this case is just the inference compute cost of $3.2 billion. Since the revenue was $6.1 billion, this leads to a profit of $2.9 billion, or gross profit margin of 48%, and in line with other estimates. This is lower than other software businesses, but high enough to eventually build a business on.”

In short, they stated, “running AI models is likely profitable in the sense of having decent gross margins.”

However, that’s not the full story.

The paper stated that by buying the argument that gross margins only should be considered when looking at profitability, “on those terms, it was profitable to run the GPT-5 bundle. But was it profitable enough to recoup the costs of developing it? In theory, yes — you just have to keep running them, and sooner or later you’ll earn enough revenue to recoup these costs. But in practice, models might have too short a lifetime to make enough revenue. For example, they could be outcompeted by products from rival labs, forcing them to be replaced.”

The trick, the authors stated, revolves around comparing gross profits and comparing the nearly $3 billion to the firm’s R&D costs: “To evaluate AI products, we need to look at both profit margins in inference as well as the time it takes for users to migrate to something better. In the case of the GPT-5 bundle, we find that it’s decidedly unprofitable over its full lifecycle, even from a gross margin perspective.”

As for the big question of whether AI models will become profitable, the paper stated, “the most crucial point is that these model lifecycle losses aren’t necessarily cause for alarm. AI models don’t need to be profitable today, as long as companies can convince investors that they will be in the future. That’s standard for fast-growing tech companies.”

The bottom line, said the trio of authors, is that profitability is very possible because “compute margins are falling, enterprise deals are stickier, and models can stay relevant longer than the GPT-5 cycle suggests.”

Asked whether the markets will stay irrational for long enough for OpenAI to become solvent, Jason Andersen, VP and principal analyst at Moor Insights & Strategy, said, “it’s possible, but there is no guarantee. I believe in 2026 you will see refinements in strategy from these firms. In my brain, there are three levers that OpenAI and other general-purpose AIs can use to improve their financial position (or at least slow the burn).” 

The first, he said, is pacing, “and I think that is happening already. We saw major model drops at a slower pace last year. So, by slowing down a bit, they can reduce some of their costs or at the very least spread them out better. Frankly, customers need to catch up anyway, so they can plausibly slow down, so the market can catch up to what they already have.”

The second, said Andersen, is to diversify their offerings, and the third involves capturing revenue from other software vendors.

As to whether OpenAI and others can keep going long enough for AI to become truly effective, he said, “OpenAI and Anthropic have the best chance of going long and staying independent. But, that said, I also want to be cautious about what ‘truly effective’ means. If you mean truly effective means achieving AGI, it’s theoretical, so probably not without major breakthroughs in hardware and energy. But if ‘effective’ means reaching profitability over a period of years, then yes, those two have a shot.”

The trick on the road to profits, he said, “will be finding a way to compete and win against companies that have welded their future to AI. Notably, Google, Microsoft, and X have now made their models inextricable to their other products and offerings. So, is there enough time and diversification opportunities to compete with them? My guess is that a couple pure plays will do well and maybe even disrupt the market, but many others won’t make it.”

Describing the paper’s findings as “very linear” and based on short-term analysis,  Scott Bickley, advisory fellow at Info-Tech Research Group, said that OpenAI has been “pretty open about the fact they are not profitable currently. What they pivot to is this staggering chart of how revenues are going to grow exponentially over the next three plus years, and that’s why they are trying to raise $200 billion now to build up infrastructure that’s going to support hundreds of billions of dollars of business a year.”

Many fortunes tied to OpenAI

He estimated that OpenAI’s overall financial commitments, as a result of agreements with Nvidia and hyperscalers as well as data center buildouts, now total $1.4 trillion, and said, “They’re trying to make themselves too big to fail, to buy the long runway they’re going to need for these investments to hopefully pay off over the course of years, or even decades.”

Right now, he said, the company is “shoring up the balance sheet. They’re trying to build everything they can to buy runway ahead. But either they wildly succeed beyond any of our imagination, and they come up with applications that I can’t envision are realistic today, or they fail miserably, and they’re guaranteed that everyone can buy a chunk of the empire for pennies on the dollar or something to that effect. But I think it’s either boom or bust. I don’t see a middle road.”

As it currently stands, said Bickley, all major vendors have “tied their fortunes to OpenAI, which is exactly what Sam Altman wanted to have happen. He’s going to force the biggest players in the space to help him be successful.”

In the event the company did end up failing, he predicted the impact on companies buying AI initiatives developed by it will be minimal. “Regardless of what happens to the commercial entity of OpenAI, the intellectual property that’s been developed, the models that are there, are going to be there. They’ll fall under someone’s control and continue to be used. They’re not in any danger of not being available.”

The article originally appeared on Computerworld.

Microsoft has launched a public preview of GitHub Copilot app modernization for C++. The company had previewed C++ code editing tools for GitHub Copilot in December. Both previews are available via the Visual Studio 2026 Insiders channel.

GitHub Copilot app modernization for C++ helps developers upgrade C++ projects to newer MSVC Build Tools versions. The public preview was announced January 27. App modernization for C++ previously became available in a private preview in November, with the launch of the Visual Studio 2026 IDE. After receiving feedback from private preview participants, Microsoft has added support for CMake projects, reduced hallucinations, removed several critical failures, and improved Copilot’s behavior when encountering an internal compiler error. Microsoft also reinforced Copilot’s understanding of when project files need to be modified to do the upgrade.

With app modernization for C++, GitHub Copilot can reduce toil incurred when adopting newer versions of MSVC, Microsoft said. GitHub Copilot will first examine a project to determine whether it can update its settings to use the latest MSVC version. Microsoft described a three-step process of assessment, planning, and execution that GitHub Copilot follows for app modernization. After updating the project settings, Copilot will do an initial build to assess if there are any issues blocking the upgrade. After confirming the accuracy of the assessment with the user, Copilot will propose solutions to any issues that need to be addressed. Once the user approves the plan, the agent completes a sequence of tasks and validates that its changes resolved the identified problems. If there remains work to be done, the agent continues iterating until the problems are resolved or the conversation is discontinued.