Apple continues work to get White House go-ahead to source memory from Chinese supplier CXMT, which the US government has placed restrictions on.

For Apple, the issue comes down to simple math. With the cost of making iPhones up 38% because of eye-watering memory price increases — up almost 7-fold since the beginning of 2025 — it makes sense to make pragmatic choices when it comes to sourcing supply, particularly when other computer companies (including HP and Acer) already obtain memory from CXMT.

US resistance to the plan is that because of the way Apple packages memory on chip, the use of that memory might partly contravene the technology transfer restrictions the US has in place. Note: use of off-the-shelf components is fine.

Apple has been lobbying to use memory from the supplier only on devices made and sold in China and would likely argue this is reasonable given that both HP and Acer already use CXMT memory in products sold outside the US. 

Why it’s really about supply

The iPhone maker’s dilemma isn’t just about memory price, it’s also about ensuring it has enough component supply to satisfy demand for its products. This is plausibly a bigger challenge for the company, which is already warning of constrained supply because of lack of available memory. Samsung, Micron, and SK Hynix have allegedly already sold through all their DRAM production for 2027, which only sharpens Apple’s case to secure alternate sources.

With that in mind, it matters that China consumes around 20% of all Apple hardware sold globally. All the company needs is the go-ahead to use RAM from CXMT in those Chinese-made, China-sold devices.

That alone would effectively grow its usable memory supply by the same amount, because the non-restricted memory it currently has to use in Chinese-market products could be freed up for devices sold elsewhere, with CXMT covering the China-sold units instead.

With demand for its products accelerating —even amid a broad industry downturn — Apple really wants to make sure it has enough of the component to meet demand. Those powerful, on-premises 1.5TB RAM-equipped M7 Ultra Mac Studio AI clusters won’t exist unless it’s possible to find memory to put inside them.

The timeline challenge

The proposed arrangement with CXMT might not be a quick fix. Recent reporting indicated the company has already reached its production capacity for 2026, though it is working to double capacity by 2028. Apple has already tested memory chips from the company across products including iPhones and MacBooks.

While Apple this year has applied steep price increases across all its products (except for iPhones), it is now expected to increase the cost of the current iPhone 17 models perhaps as soon as this week. 

Market reports already warn that Apple will raise prices on its soon-to-debut iPhone 18 Pro and iPhone Ultra devices next month, and we expect availability to be constrained, once again as a result of RAM shortages. Even if Apple gets the go-ahead to work with CXMT to close the gap, the positive impact of that arrangement is unlikely to kick in before next year.

Enjoy the pain

Elsewhere, big memory manufacturers, including SK Hynix, have announced plans to invest in new DRAM manufacturing capacity. But this will not be operational until 2029, at the earliest.

This suggests constrained product availability and higher prices for the coming months — and the only way Apple, or anyone else, will be able to limit the impact of those price increases across the entire electronics industry will be if they can obtain additional stocks of memory from vendors outside the big three. If they cannot, you can kiss the age of abundance goodbye.

You can follow me on social media! Join me on BlueSky,  LinkedIn, Mastodon and subscribe to The Core.

It used to be that the value and reputation of coding contest winners was very high. That’s no longer the case. Who cares how fast you can produce code that implements an algorithm or solves a problem? Your competition is no longer other people, at least not by themselves, but AI combined with insightful prompting and good taste.

Historically we wrote all our code ourselves and then we tested it ourselves. Yes, there was a period when we outsourced punching our cards to what was essentially a secretarial pool, but we were still writing out the code and doing all the thinking involved in the programming. Over the years we outsourced some of the testing to a QA department, allowed software to guess at what we were typing and complete it, and allowed code-checking software to run in the background as we typed.

Allowing software to help us by guessing what we mean advanced from word completion to line completion to function completion to program generation over a matter of about a decade. Currently a good model running in a good agent harness or IDE can look at your code, suggest improvements, compile and test the improved code, iterate on that, and then come up with something better, faster, more efficient, and more solid.

That shifts the burden from actually programming to reviewing and testing the code. If you don’t even review and test the code, then what you’re doing is vibe coding. Vibe coding doesn’t give you a lot of control over the end product. It is only really efficient at generating quick prototypes and creating technical debt. It’s just not enough structure.

One attempt to add more structure and to control what the model actually generates is specification-driven development (SDD). SDD works, because a spec grounds the model in a single source of truth. However, SDD often comes at the expense of taking too much effort and really being overkill for what you usually need.

Developers are still floundering, wondering how to strike a balance between vibe coding and spec-driven development. One possible approach is behavior-driven development. Another is a variation on test-driven development, sometimes called “facts first.” A fact in this context is an executable invariant tested by a machine. Finally, there’s intent-driven software development (IDSD), which is a new take on the old craft of intent, context, and expectations (ICE).

Meanwhile, we have perhaps a dozen options for IDEs and another dozen options for agent harnesses and many dozens of models that do a good job of generating code. Here I’ll provide a brief tour of six of them: GitHub Copilot, Google Antigravity, JetBrains Air, Kiro, Zed, and Zenflow.

GitHub Copilot

First offered as a plug-in to Visual Studio Code in 2021, GitHub Copilot was one of the first AI plug-ins for coding assistance. Today, you can use GitHub Copilot in a slew of IDEs for code completion, generation, explanation, and debugging. In addition to VS Code, GitHub Copilot is available for Visual Studio, Vim, Neovim, and the JetBrains suite of IDEs. You can also use Copilot on the command line, both through the GitHub Copilot CLI and as an extension to the GitHub CLI. You can also use it directly on the GitHub website.

Currently there are about two dozen supported AI models in GitHub Copilot, including models from OpenAI, Anthropic, and Google. In Visual Studio Code you can add more models than the ones available by default with your Copilot subscription. For example, if you open the Manage Language Models panel in VS Code, you can select models from Foundry Local via AI Toolkit, GitHub Models via AI Toolkit, Microsoft Foundry via AI Toolkit, and, at least in my case, local models via Ollama. Local Ollama models don’t count against your Copilot plan, but they do occupy GPU or unified memory, depending on your hardware configuration.

GitHub Copilot currently has three default operating modes: Plan, Ask, and Agent. Plan mode researches and outlines multi-step plans. Ask mode chats with you without making changes. And Agent mode edits files in your workspace. You may also have custom modes, some of which are supplied by plug-ins; I have 16 of these. You can create your own custom modes if you wish.

GitHub Copilot currently has nine categories of default tools used by agents; each category may have many actual tools listed. Additional tools come from connected Model Context Protocol (MCP) servers and installed plug-ins. My installation currently has 346 tools available, which is nuts. At one point VS Code would warn you if you had too many tools active, but that doesn’t seem to be happening anymore.

AI agents are autonomous helpers that perceive their environment, decide on a course of action, and execute it. They break large tasks into smaller steps, draw on available tools and resources, reason about approach, and adjust their plans on the fly, all while following user directives until the goal is met. While most agentic code edits complete in seconds or minutes, some can run for hours with only a few requests for permission.

In light of that, it’s not surprising that GitHub switched to usage-based billing for GitHub Copilot. Effective June 1, 2026, GitHub tracks your token consumption rather than your Premium Request Units. Code completions and next edit suggestions are exempt from token limits.

Google Antigravity

The original Google Antigravity (from way back in November 2025) was built as an agentic development platform, essentially a version of the VS Code “Code – OSS” IDE that Google developers use internally, which was repurposed for the sorts of repositories that mere mortals work with on normal-sized products. (Google’s internal software mono-repository is so large and complex that ordinary software tools can’t work with it; Googlers use Piper, an internal tool for version control, rather than Git.)

On May 19, 2026, Antigravity became the basis for a new ecosystem. Google Antigravity 2.0 is a standalone desktop application that is an independent, agent-focused surface, evolved from Antigravity’s Agent Manager. The new Google Antigravity IDE is a separate download that looks similar to the previous Antigravity. The Google Antigravity CLI is a way to invoke, monitor, and interact with Antigravity agents from your terminal. In addition, the Google Antigravity SDK is available to build custom agents.

Google Gemini 3.6 Flash is the default model on Google Antigravity. According to Google it’s their strongest agentic and coding model yet, as well as being faster than other frontier models on Antigravity. Gemini 3.6 Flash can be selected at three effort levels: low, medium, and high. Antigravity also supports Gemini 3.5 at low, medium, and high levels; Gemini 3.1 Pro at two effort levels; Anthropic’s Claude Sonnet 4.6 and Opus 4.6 with thinking enabled; and GPT-OSS-120B at medium effort. The general guidance is to use the lowest level of effort that will successfully execute your task to minimize token use.

The “+” dropdown in the prompt box allows you to add context to the prompt. Both Antigravity 2.0 and Antigravity IDE allow you to add media, mentions, and actions. Antigravity 2.0 also allows you to enable the browser from the “+” dropdown; it simply adds the /browser slash command to the prompt.

The Antigravity browser subagent is the rough equivalent of Playwright or the Microsoft Foundry Browser Automation tool. It can click, scroll, type, read console logs, capture the DOM, take screenshots, and record video. The browser subagent also integrates natively with the Chrome DevTools MCP.

The other internal slash commands for both SKUs are /goal, which means to run until the specified task is completely finished, not asking for intermediate input from the user; /grill-me, which means to ask questions back to align on the specific details of the plan before implementing it; and /schedule, which means to run an instruction as a one-time timer in the future or on some recurring schedule (via Scheduled Tasks). Any skills provided by plug-ins or by installed Model Context Protocol servers can also be selected by typing a slash into the prompt box.

Antigravity 2.0 and Antigravity IDE support skills both at the workspace and global levels. A skill requires a SKILL.md file with YAML frontmatter at the top, and supports optional scripts, examples, and resources. The YAML description field is key to allowing an agent to recognize when the skill is relevant. Skills that come with MCPs or plug-ins take no effort to install. Creating custom skills requires you to add a named skill directory and the SKILL.md file.

JetBrains Air

JetBrains Air is an agentic development environment that allows you to delegate coding tasks to AI agents. It supports four agent providers: OpenAI Codex, Anthropic Claude, Google Gemini, and JetBrains’ own Junie. You can provide your own subscriptions or API keys for OpenAI, Anthropic, and Google to Air, or rely on JetBrains’ hosting via a subscription.

When you create a new task for JetBrains Air, it can run in a local workspace, a Git worktree, or an isolated Docker container. Once you have set it up properly, you can also run a new task in the cloud, starting either from your local machine or from a browser.

You can select an agent provider and model at this time. You can switch the agent only when you create a new task; you can change models within an agent at any time. There are four levels of permissions ranging from plan first to full access. For some agents you can select an effort level. You can provide context to the chat from a number of sources, including files and folders, documentation, Git branches, and several others.

To test Air, I gave it the prompt “try to improve on the performance of this pi calculator. Do your work in a new directory called air.” I used Claude Sonnet 4.6 (1M context window) and high effort with Ask permissions, running the task locally. It did a rather good job, although I got further optimizations later on with other environments.

Kiro

Developed by “a small, opinionated team within AWS” and described as an autonomous agent or virtual developer that learns over time while working independently, Kiro is available both as an IDE (based on Code OSS) and as a CLI tool. Kiro CLI (kiro-cli) doesn’t deal with specs at this point, although it does have a planner agent and agent steering. Kiro IDE (kiro) explicitly supports both vibe coding and spec-driven development (SDD). (See screenshot below.)

Kiro SDD generates three markdown files that together comprise the specification: requirements.md, which captures user stories and acceptance criteria in structured EARS (Easy Approach to Requirements Syntax) notation; design.md, which documents technical architecture, sequence diagrams, and implementation considerations; and tasks.md, which provides a detailed implementation plan with discrete, trackable tasks.

You can also import specs from other systems and iterate on your specs. You can even generate specs based on a vibe-coding session. Ideally, you would create a spec for each project feature.

EARS notation captures user stories and follows the pattern:

WHEN [condition/event]
THE SYSTEM SHALL [expected behavior]

This format is clear and testable. Kiro can generate property-based tests (PBT) based on your EARS-formatted requirements. These are more comprehensive than the usual unit tests.

In addition, Kiro SDD can generate three markdown files that together define the steering for the agents. Steering gives Kiro persistent knowledge about your workspace and its conventions.

A product overview file (product.md) defines the purpose, target users, key features, and business objectives of your project. A technology stack file (tech.md) specifies your chosen frameworks, libraries, development tools, and technical constraints. And a project structure file (structure.md) documents your file organization, naming conventions, import patterns, and architectural decisions.

With my free plan, Kiro IDE currently supports two Anthropic Claude models, Sonnet 4.5 and Sonnet 4.0, plus five open-weight models. It can automatically select models if you wish. The documentation also lists OpenAI’s GPT-5.6 Sol, Terra, and Luna, Claude Opus 4.5, 4.6, 4.7, 4.8, and 5.0, and Claude Haiku 4.5, all of which can be activated with a Pro ($20/month) or better plan.

Kiro IDE supports over a dozen context providers for chat requests, including generic context such as #codebase and #spec and specific context such as #code (snippets). It supports skills that follow the open Agent Skills standard, and Model Context Protocol servers that follow the MCP standard.

Zed

Over the last few years my colleague Serdar Yegulalp and I have both reviewed Zed favorably, citing both its raw speed (it was written in Rust) and its integration with a flock of language models, mostly using a “bring your own key” paradigm. You need to subscribe if you want to use a Zed-hosted model.

The team behind Zed previously created the hackable text editor, Atom, and the software platform for building JavaScript-based desktop apps, Electron, both for GitHub. They also built Tree-sitter, an advanced syntax parsing framework that has become the standard mechanism for code analysis and syntax highlighting across modern code editors. While Atom has been discontinued, both Electron and Tree-sitter are still active.

It’s Wednesday so there’s a new release of Zed out; the current version (as I write) is v1.13.2. Recent milestones include support for Anthropic’s Claude Opus 5, OpenAI’s GPT-5.6, llama.cpp as a model provider, and automatic agent context compaction. Some older major features include support for skills, collaboration, and remote development. If you’re interested in particular features, read the Zed documentation or the Zed GitHub Repository.

To test Zed’s agentic capabilities, I pointed it at the C++ π calculation program I’ve been using to test agentic development tools, then used Zed’s new code-review skill to evaluate the program. After thoroughly reviewing Zed’s proposed changes, I gave it the go-ahead to implement and test them. I used the recommended model at the time, Claude Sonnet 4.6.

Zenflow

Zenflow is a free platform that coordinates AI agents to build software using spec-driven development (SDD) workflows. Another term for coordination is orchestration, hence Zenflow is also described as an orchestration layer.

Zenflow was developed by the Zencoder team. Thus Zencoder plug-ins work in Zenflow, and features from Zenflow (such as guided workflows) have been added to Zencoder. The CEO of Zencoder, Andrew Filev, told me that his team of experienced engineers had been using Zenflow for their own product development for over a year when I questioned whether it is ready for production code.

The high-level description of the relationship between Zencoder and Zenflow is that Zenflow is the workflow brain and Zencoder executes the work. You may have noticed some naming confusion: Zencoder is not only the name of the company and of its AI plug-in for IDEs, but it is also the name of its in-house coding agent, which is one of four options for Zenflow (the others are Claude Code, Codex, and Gemini) and one of about nine models available to the Zencoder plug-in.

When you start a Zenflow project, you’re offered a choice of standard workflows: Quick Change, Fix Bug, Spec and Build, or Full SDD Workflow, depending on scope. The wider the scope, the more structure you need in the workflow to keep the implementation from drifting away from the requirements. You can also define your own custom workflows, perhaps to conform to your shop’s standards.

Zenflow can run multiple tasks in parallel in isolated environments. The agents coordinate within workflows without corrupting your codebase.

Zenflow also automates verification of its changes. Every workflow runs automated tests and cross-agent code review. Failed tests trigger automatic fixes. Your code ships only after passing all the verification gates.

Zenflow projects are broken down into tasks, and those are divided into subtasks and chats. Each task runs inside its own isolated Git worktree. You can view the status of all tasks in Kanban boards or stacked list views.

Choosing an AI coding environment

Which AI-supported development environment should you choose? As we’ve seen, there are plenty of good options.

GitHub Copilot is one of the most mature AI coding plug-ins for VS Code, and it supports a wide range of AI models.

Google Antigravity 2.0 is a standalone desktop application that is an independent, agent-focused surface. Antigravity IDE is a separate download that looks and feels similar to the original Antigravity. Antigravity CLI is a way to invoke, monitor, and interact with Antigravity agents from your terminal. These tools are among the best ways to take advantage of Gemini models.

JetBrains Air is a relatively new agentic development environment that allows you to provide your own subscriptions or API keys for OpenAI, Anthropic, and Google models.

Kiro IDE supports both vibe-coding and spec-driven development flows. With my free plan, Kiro IDE currently supports two Claude models.

Zed is about the fastest IDE I have used, and it integrates with a flock of language models, mostly using a “bring your own key” paradigm. Its advanced features include collaborative coding and remote development.

Zenflow supports multiple workflows, from quick changes all the way up to full spec-driven development. You can also define custom workflows. Zenflow works with the Zencoder coding agent as well as Claude Code, Codex, and Gemini.

There is no winner: It’s really a matter of which tool fits your use case and makes you happy. If I could have everything I wanted in one tool, I would take the speed and power of Zed, the spec-driven development capabilities of Kiro and Zenflow, and the agentic capabilities of GitHub Copilot, Google Antigravity 2.0, and JetBrains Air.

OpenAI said its upcoming model Astra is showing cybersecurity capabilities that could reach its highest risk category, where a system can autonomously find and exploit vulnerabilities or carry out end-to-end cyberattacks against hardened targets.

The company disclosed the assessment following recent internal testing and expert reviews.

“Our latest internal evaluations of Astra, one of our upcoming models, over the past few days indicate significant advancements in agentic coding and cybersecurity,” OpenAI said in a statement. “These results, in addition to expert assessments, have led us to conclude last night that we cannot rule out critical cyber capabilities under our Preparedness Framework⁠.

What has changed

To explain the shift, OpenAI pointed to its internal Preparedness Framework, which tracks how far AI models advance in sensitive areas such as cybersecurity.

At the top end of that framework are systems that no longer just assist humans but can act on their own, the company said.

“A model reaches the Critical cybersecurity threshold if it can identify and develop functional zero-day exploits of all severity levels in many hardened real-world critical systems without human intervention, or can devise and execute end-to-end novel strategies for cyberattacks against hardened targets given only a high-level desired goal,” the statement added.

The company said Astra has not yet been definitively classified at that level, but its early performance is “strong enough” that such a designation cannot be ruled out. Its earlier models, including GPT 5.6 Sol, “have been evaluated for frontier cyber capabilities and assessed at the High (rather than Critical) threshold.”

“This is a substantial inflection point,” said Apeksha Kaushik, senior principal analyst at Gartner. “An AI system could autonomously discover vulnerabilities, develop exploits, and execute end-to-end attacks with minimal human guidance.”

Why this matters for enterprises

For security teams, the change is not just technical — it affects how attacks may unfold, analysts feel.

Kaushik said the pace of progress suggests “practical, real-world exploitation is becoming increasingly feasible,” meaning attackers could automate large parts of the attack process. That reduces the time defenders have to react.

“The implication is clear: enterprise security must evolve from reactive to preemptive,” she said, adding that organizations should move toward continuous, AI-driven exposure assessment and predictive analysis.

Sanchit Vir Gogia, chief analyst at Greyhound Research, said companies should not wait for a formal label before acting.

“OpenAI has said it cannot rule out critical cybersecurity capability in Astra and is treating the model accordingly. That is a precautionary trigger rather than a finished finding,” he said.

He added that the focus should shift beyond patching speed. “The measure that matters is defensive response latency. A flat vulnerability queue is no longer a security posture.”

What OpenAI is doing now

Based on the development, OpenAI said it is tightening controls around Astra’s development.

“We are implementing stricter security controls for higher-capability models,” the company said, including “isolated testing environments, restricted network and tool access, enhanced model weight protections and encryption, additional monitoring and detection capabilities, and sandboxed execution,” OpenAI added I n the statement.

It is also “pausing internal activities involving Astra that do not yet meet these strengthened security control requirements.”

The company said it has expanded monitoring across how the model is used. “We have implemented universal monitoring for risky actions and misalignment,” it said, adding that systems can “trigger a security response to review and interrupt high-risk activity.”

Are the safeguards enough?

Analysts said these steps are necessary, but may not fully address the risks as capabilities improve.

“Current safeguards such as restricted environments, continuous monitoring, and external red-teaming are necessary, but the gap between safeguards and emerging threats is increasing,” Kaushik said. She pointed to risks such as prompt injection and weak access controls in AI systems.

Gogia said safeguards need to be viewed in the context of the broader system.

“A capable model does not operate inside a framework document. It operates inside a system, and systems leak authority through their exceptions,” he said. “Gated access buys defenders time. It does not repeal a capability.”

OpenAI said it will work with governments and external safety groups to further test Astra.

“We will work with relevant government agencies and select AI safety organizations to test the capabilities for this model,” the company said, adding that it will also share guidance with third-party testing partners. The company said it is disclosing the findings to be transparent about what it called a “potential shift in capabilities.”

Die Warnung, dass Künstliche Intelligenz unsere Arbeit übernimmt, ist allgegenwärtig. KI-gestützte Coding-Tools übernehmen Aufgaben von Junior-Entwicklern, leistungsfähige Sprachmodelle verändern die Arbeit von Wissensarbeitern – und mit den Fortschritten bei Physical AI geraten zunehmend auch körperliche Tätigkeiten in der Industrie und im Haushalt in den Fokus der Automatisierung.

Doch der technologische Wandel bedeutet nicht zwangsläufig, dass dem Menschen die Arbeit ausgeht. Besonders gefragt bleiben Tätigkeiten, die zwischenmenschliche Interaktion, Empathie, komplexes Denken oder Kreativität erfordern.

In diesen Bereichen steige die Nachfrage weiter an und das oft sogar stärker als in Berufen, die durch Automatisierung gefährdet sind, so die Karriereberater von Livecareer.

Technische Expertise und menschliche Fähigkeiten

Als Beispiele für solche Tätigkeiten, in denen technologische Expertise allein nicht ausreicht, sondern häufig mit menschlichen Fähigkeiten kombiniert wird, nennen sie unter anderem:  

• Gesundheits- und Pflegeberufe,
• Bildung & Training,
• Management, Recht & Unternehmensberatung, und
• Technologie & Datenanalyse.

Zukunftsfähige Berufe lassen sich laut LiveCareer oft an folgenden Anforderungen erkennen:

• Hohe soziale und kommunikative Anforderungen, etwa Empathie und Teamarbeit;
• Komplexe Problemlösung und kreative Aufgaben, die nicht standardisierbar sind;
• Fachwissen und Spezialisierung, die kontinuierlich weiterentwickelt werden müssen;
• Menschliche Verantwortung und Entscheidungsfreiheit;
• Anpassungsfähigkeit in einer digitalen und vernetzten Arbeitswelt.

Gefährdet sind aus Sicht von Livecareer dagegen Jobs mit stark repetitiven Tätigkeiten. So ließen sich etwa einfachere Verwaltungsaufgaben, Routine-Datenerfassung oder bestimmte manuelle Tätigkeiten leicht durch KI und Automatisierung ersetzen. In den meisten Fällen fallen die Berufe selbst dabei nicht (komplett) weg, so die Experten, vielmehr verändern sich die Aufgaben.

Wer diese Jobs weiter ausführen möchte, muss sich vor allem anpassen, also weiterbilden, neue Fähigkeiten lernen oder sich breiter aufstellen, um auch bessere Chancen auf dem Arbeitsmarkt zu haben.

KI und Arbeit: 4 Szenarien

Wie stark solche Anpassungsstrategien tatsächlich greifen, hängt allerdings davon ab, wie schnell sich KI entwickelt – und ob die Arbeitswelt mit diesem Tempo Schritt halten kann. Genau diese beiden Faktoren stellt das World Economic Forum ins Zentrum von vier Szenarien für die Arbeitswelt bis 2030.

• Im Szenario „Supercharged Progress“ treffen laut WEF rasante technologische Fortschritte auf eine hohe Bereitschaft der Arbeitswelt, sich auf KI einzustellen. Das Resultat: KI-Systeme übernehmen immer mehr Aufgaben, während sich viele menschliche Tätigkeiten in Richtung Steuerung, Kontrolle und Zusammenarbeit mit intelligenten Systemen verschieben. Daraus kann eine stark KI-geprägte Wirtschaft mit erheblichen Produktivitätsgewinnen entstehen.
• Bei „The Age of Displacement“ entwickelt sich KI ebenfalls exponentiell, doch Unternehmen, Beschäftigte und Bildungssysteme können nicht mithalten. Automatisierung ersetzt zahlreiche Tätigkeiten, ohne dass in gleichem Tempo neue Job-Perspektiven entstehen. Die Folge könnten großflächige Arbeitsplatzverluste, stärkere wirtschaftliche Schwankungen und gesellschaftliche Spannungen sein.
• Das Szenario „Co-Pilot Economy“ zeichnet ein wesentlich kooperativeres Bild. Die technologische Entwicklung verläuft weniger explosionsartig, gleichzeitig ist die Arbeitswelt gut auf KI vorbereitet. Statt Menschen in großem Umfang zu ersetzen, werden KI-Systeme vor allem eingesetzt, um Beschäftigte bei ihrer Arbeit zu unterstützen und ihre Fähigkeiten zu erweitern.
• „Stalled Progress“ beschreibt schließlich eine Welt, in der sowohl die KI-Entwicklung als auch die Anpassung der Arbeitswelt stocken. Die Konsequenz: Fehleranfällige KI-Anwendungen und mangelnde Kompetenzen verhindern die erhofften Produktivitätsgewinne.

Was Arbeitnehmer jetzt tun können

Unabhängig davon, welches Szenario Realität wird, können Beschäftigte schon heute ihre Ausgangsposition verbessern. Livecareer empfiehlt vor allem, digitale Kompetenzen auszubauen und den sicheren Umgang mit KI-Tools zu lernen. Gleichzeitig gewinnen Fähigkeiten an Bedeutung, die sich nur schwer automatisieren lassen: Kommunikation, Kreativität, Teamarbeit und komplexe Problemlösung. Wer zudem flexibel bleibt, praktische Erfahrungen sammelt und Weiterbildungsangebote nutzt, kann sich leichter auf neue Berufsbilder einstellen. Auch ein belastbares berufliches Netzwerk kann helfen, neue Chancen frühzeitig zu erkennen.

Each year the CIO 100 Awards showcase outstanding IT initiatives, and every year they illustrate the power and potential of technology to transform how people work, how organizations perform, and the value they offer to customers.

The 2026 cohort of winners is no different. Each one demonstrates how IT executives and their teams successfully move from ideation to deployment to scaling a solution for the future, overcoming challenges and driving adoption along the way to ensure their organization gets a return on its investment.

[ Interested in meeting and learning from all CIO 100 winners? Join us next week at CIO 100 Awards & Conference in Frisco, TX. Limited seats remain! Register here ]

The winning initiatives come from a range of industries and utilize a host of technologies to achieve their goals, as is the case annually. A growing proportion of these stand-out projects leverage artificial intelligence, raising the bar on the art of the possible for all IT departments.

The following 10 award-winning projects serve as representatives for the outstanding work done by all the 2026 honorees.

ABB democratizes AI agent creation and deployment

Organization: ABB

Project: ABBY — AI Agentic Platform for Workforce Transformation

IT leader: Vikke Kandell, CIO

IT leaders at ABB, a manufacturer, had some big hurdles to clear when it came to building an AI strategy.

They had to overcome employee fears that AI would take away jobs, the potentially high cost of AI vendor licenses, and pressure from investors, customers, and executives to advance the use of AI in the enterprise.

“We looked at this and asked, ‘How do we address all this?’ and build something that the company is proud of,” says Babu Kuttala, vice president of data analytics and AI.

The answer is ABBY, an AI agentic platform that enables employees to create and deploy specialized AI agents for specific business tasks.

To build ABBY, Kuttala and his team used best-of-breed LLMs (about 25 in total). They built a centralized orchestration layer using generative AI that integrates internal knowledge bases with external ecosystems, creating a unified platform where agents can access enterprise data, understand required actions, and execute tasks across multiple systems. And they created preconfigured skills so that employees could build agents tailored to their workflows without having to code.

ABBY was rolled out in 2025 to 100 users but is now used by 63,000 (more than 75% of the company’s workforce, Kuttala notes) with an average of 10,000-plus workers using it daily. IT continues to add LLMs and capabilities to expand use of ABBY even further, Kuttala says.

Belcorp modernizes manufacturing with Smart Factory

Organization: Belcorp

Project: QPlant — Smart Factory

IT leader: Venkat Gopalan, Chief Digital, Data, and Technology Officer

Legacy processes were limiting Belcorp’s ability to scale and compete. Its manufacturing relied on ERP-driven processes with limited shop-floor automation and weak connectivity across production, packaging, quality, and maintenance. The company depended heavily on manual records and post-process reconciliation, resulting in fragmented data, limited real-time insight, inefficiencies, and higher risks for errors.

Smart Factory changed all that. The IT initiative reimagined how manufacturing teams work “by creating a connected, data-driven environment where production, quality, maintenance, and operations are aligned around real-time information and standardized execution,” says Venkat Gopalan, chief digital, data, and technology officer.

At Smart Factory’s core is a manufacturing execution system that orchestrates production workflows, quality processes, and operational execution, he explains. IoT-enabled equipment integration and a centralized SCADA platform provide real-time visibility into shop-floor operations, while electronic batch records digitize production execution, strengthen traceability, and reinforce compliance by design.

Integrating those operational technologies with the company’s enterprise platforms was another critical component of success, Gopalan says, creating a trusted flow of real-time data across manufacturing, quality, maintenance, and business systems. “This connected architecture transformed isolated data into actionable insights, enabling faster decision-making, greater operational visibility, and continuous improvement across the manufacturing lifecycle,” he adds.

The initiative generated more than $1 million in financial benefits in its first year alone.

“Most importantly, Smart Factory established the digital foundation for the future of manufacturing at Belcorp,” Gopalan says. “With real-time operational data and connected systems now in place, we’re well positioned to accelerate advanced analytics, AI-driven optimization, predictive maintenance, and other Industry 4.0 capabilities that will continue delivering value for years to come.”

Cohesity replatforms post-acquisition for commercial growth

Organization: Cohesity

Project: Lead to Cash Replatforming Program (Veritas Integration)

IT leader: Brian Spanswick, CIO

Cohesity set an ambitious objective: Complete an enterprise-scale lead-to-cash replatform in under six months.

That’s a tight timeline for any replatforming initiative, but Cohesity’s project had another layer of complexity. It followed Cohesity’s December 2024 acquisition of Veritas, a company twice its size in revenue, leaving Cohesity to integrate the majority of a global enterprise revenue engine into its own operating model without disrupting customers, partners, or sellers.

“We had to bring the two companies together, merge the workforces together, and create an overall harmonized organization and operating infrastructure platform,” says Eric Brown, who as CFO and COO led the project.

The program migrated heavily customized CRM, CPQ, PRM, ERP, and subscription platforms (some of which were “very brittle, very bespoke,” Brown says) to a unified SaaS CRM, CPQ, and ERP environment with uninterrupted selling, billing, and partner operations.

This was no lift-and shift, Brown stresses. “It was a business process optimization project as well. We want to run very efficiently, so we questioned everything and used the migration process to simplify and streamline the business in every possible respect.”

The initiative enabled continuity for 13,000-plus customers, protected revenue during integration, and established a scalable commercial foundation for future growth.

Brown cites several factors that contributed to success. First, leadership was upfront about what it would take to meet the deadline, a process that involved carefully prioritizing the capabilities that would appear in the first iteration. Leadership also streamlined decision-making, establishing office hours that “ran with military precision” to handle issues. And the company selected a specialized partner, requiring its top talent be assigned to Cohesity.

Dairyland Power goes agentic to protect field crews

Organization: Dairyland Power Cooperative

Project: ODIN — Organizational Effectiveness Agentic AI

IT leader: Nate Melby, VP and CIO

Dairyland Power Cooperative had amassed a large collection of field observations, incident reports, near-misses, safety rules, and work methods that could yield insights into processes and practices that could help protect its workers.

But the insights were essentially out of reach, trapped in siloes.

Dairyland’s organizational effectiveness team turned to CIO Nate Melby for help unlocking those insights. Melby then turned to agentic AI, recognizing that the technology could address the team’s need to make better use of its data.

“This was about finding insights on how to work more safely,” Melby says. “It’s about preventing incidents.”

The collaboration between the two teams created ODIN, the first agentic AI implementation of its kind in the electric utility industry.

Focused on worker safety, ODIN autonomously connects the collective safety knowledge of the organization and delivers actionable insights directly to field crews at the moment work is planned.

ODIN was developed through a hybrid approach that combined an agentic AI platform and Dairyland’s internal private generative AI platform called VoltWrite. ODIN leverages LLMs, retrieval-augmented generation, and a coordinated swarm of autonomous agents.

Agents work together to analyze internal safety data, performance history, work practices, and safety rules and then synthesize the information into clear guidance on the safest way to perform specific tasks.

ODIN has produced results, including a reduction in OSHA recordable injuries and improvements in the quality and consistency of pre-job safety briefings.

ODIN was deployed in early 2025 for use by Dairyland’s workers in transmission construction and electrical maintenance, which are the highest-risk work areas. Dairyland is looking to expand ODIN’s use to other teams.

Dow’s digital sustainability ledger drives low-carbon sales

Organization: Dow

Project: Carbon Footprint Ledger

IT leader: Deb Bauler, Chief Information and Digital Officer

Executives at Dow consider the Carbon Footprint Ledger (CFL) as more than a technology or innovative carbon accounting methodology. According to Senior Global IT Director Jeremy Preston, CFL is “a digital business capability that enables Dow to translate sustainability investments into customer value.”

CFL transformed how Dow uses greenhouse gas emissions data. It combines a methodology aligned to international standards with an enterprise-scale digital platform. It also integrates manufacturing, supply chain, commercial, and sustainability data to generate product carbon footprints under enterprise-level governance and management at scale.

In doing so, Preston says it creates “a trusted, traceable link between low-carbon processes and raw materials implemented across its manufacturing network and the lower-carbon products customers seek.”

The technology team worked closely with sustainability and business teams, collaboratively developing the capabilities needed to reconstruct product genealogy, maintain end-to-end data lineage, track low-carbon attributes across interconnected manufacturing processes, and generate product carbon footprints that can support customer offerings and commercial transactions.

CFL was built on Dow’s Integrated Data Hub and in partnership with Boston Consulting Group and Databricks.

The core CFL platform is fully deployed and supports commercial transactions today.

Preston says CFL “enables Dow to turn sustainability investments into customer value, commercial differentiation, and new growth opportunities.” Dow reports that it has driven hundreds of millions of dollars in low-carbon product sales in 2025 and 2026.

The company is now expanding its use. “We are extending adoption across additional products, manufacturing networks, business segments, and customer use cases while continuing to enhance automation, analytics, and integration with commercial processes,” Preston says.

J&J transforms quality management with AI

Organization: Johnson & Johnson

Project: Q&C Strategy

IT leader: Michael Comprelli, Vice President, Head of Technology, Technical Operations, and Risk; Joel O’Connor, Head of Technology, Medtech Quality, and Compliance

Johnson & Johnson is using AI to transform quality management through its Q&C Strategy.

QuIn is an AI-powered digital assistant that fuses human expertise with machine learning, automation, and data-driven insights to boost efficiency, reliability, and worker impact. By embedding gen AI into core quality management systems processes, QuIn proactively gathers actionable insights, increases operational efficiency, and allows teams to focus on high-value, patient-centric work.

Cora is an innovative generative AI platform that provides regulatory intelligence monitoring, impact analysis, and augmented content revision. Cora assists with document analysis, compliance comparison, stakeholder analysis, policy/standard creation, procedural/document updates, and document comparison. Cora is purpose-built for regulated environments, validating outputs against source material and offering a user experience that instills trust in the outcome.

QuIn and Cora, which automate time-intensive tasks and democratize information access, are on track to deliver significant value, with J&J reporting more than $62 million in documented true cost savings by 2028 from QuIn alone. Cora delivered $2 million in cost efficiency in 2025 and will deliver a documented cost savings of $25 million by 2028.

“Our teams proved responsible AI can be applied meaningfully in a highly regulated environment without compromising the rigor, accountability, or human judgment that quality requires,” says Michael Comprelli, vice president, head of technology, technical operations, and risk.

He continues, saying that J&J “moved these ideas beyond experimentation and into products that employees use in their daily work. We did that by bringing together Quality expertise, product management, data engineering, architecture, cybersecurity, user-experience design and AI engineering around a common purpose.”

JLL brings intelligent automation to business services

Organization: JLL

Project: Business Service Digitization

IT leader: Pinak Dash, Global Head of JLL Business Services and Legal Technologies

JLL launched its digitization initiative to drive process redesign as well as systematic AI and RPA deployment across JLL Business Services (JBS).

The initiative was designed to address inefficiencies that hampered scalability and competitive positioning. It was also designed to eliminate manual processes that consumed thousands of hours across finance, HR, legal, procurement, marketing, research, IT, and lease administration.

Pinak Dash, global head of JBS and legal technologies, says the digitization initiative had a dual-strategy combining traditional digitization with generative AI innovation to hundreds of processes.

JLL lists three innovations critical to the program’s success.

First is a hybrid platform that integrates RPA with JLL’s proprietary AI platform called Falcon, which created intelligent automation that adapts and learns. It enables real-time process automation, intelligent document processing with automated extraction/validation, and smart decision-making for continuously optimizing workflows.

The second innovation is its use of ProHance for real-time process monitoring and enabling of data-driven optimization. Sensors capture granular productivity metrics, identify bottlenecks, and provide actionable insights for continuous improvement across automated and manual processes.

Third is its custom AI assistants and transaction agents. Falcon-powered assistants provide intelligent knowledge search while specialized agents execute complex transactions across enterprise SaaS platforms. These handle multisystem workflows, reducing human touchpoints while maintaining accuracy and compliance.

Dash says the initiative has delivered quantifiable benefits through improved efficiency, accuracy, and quality of services provided to clients.

“The initiative delivers on our business goals, makes us more efficient, provides customers better service, and it opens up the capabilities and bandwidth of our people to do what they like to do and to find innovative ways to serve our business,” he adds.

Nationwide partnership platform delivers efficiencies, business growth

Organization: Nationwide

Project: Enterprise Digital Platform (EDP)

IT leader: Michael Carrel, EVP and CTO

Nationwide’s new Enterprise Digital Platform (EDP) gives the company “a scalable way to connect with external partners quickly, securely, and consistently across all areas of our business,” says company EVP and CTO Michael Carrel.

He explains that “instead of treating every integration as a custom effort, EDP creates a common front door for digital products, documentation, onboarding and governance.”

That innovation has produced better experiences for the company’s partners. It saves time for Nationwide teams, partners, and customers. And it supports faster launch times for new products and enables growth across the business.

“EDP changed the model from fragmented, point-to-point integrations into an enterprise platform built around reusable digital products. That shift lets us support a range of integration options in one governed environment, meet partners at different stages of technical maturity, and add new capabilities over time without redesigning every relationship from scratch,” Carrel explains.

EDP uses cloud-native microservices, role-based access control, and advanced analytics. Nationwide IT created modular microservices to make EDP more scalable, resilient, and adaptable. And IT decoupled it from infrastructure-specific dependencies so that it would be a platform-agnostic developer portal. That, Carrel says, reduced operational constraints across environments.

Additionally, IT shifted from a user-specific model to role-based access, which improved security, simplified administration, and better served the needs of different audiences.

Meanwhile, robust analytics delivers visibility into platform usage and performance, which Carrel says helps ensure Nationwide continuously evolves the platform based on measurable outcomes.

The core platform is fully deployed, with Nationwide planning to expand it.

“Our Enterprise Digital Platform is more than a piece of technology,” Carrel notes, “it represents a strategic enabler to support growth objectives across Nationwide’s businesses.”

PITT Ohio fast-tracks shipment requests with AI assist

Organization: PITT Ohio

Project: No Touch Email (N@TE AI)

IT leader: Scott Sullivan, President and CEO (formerly CIO)

As PITT Ohio started its AI journey in 2024, the mandate was clear: Use the technology to solve “real problems,” says Ryan Carner, director of enterprise IT solutions.

“We wanted to hit the ground running and find a problem that was solvable,” Carner says, noting that the company also wanted to use the experience to build in-house AI skills. “The idea was to find a business case for AI that would be our first but not the only one.”

PITT Ohio leaders decided to tackle what Carner describes as a “mundane but very important task for how our business operates”: handling emails to the customer service team.

The need was significant. Customer service representatives were manually processing hundreds of pickup request emails daily, each requiring five to 15 minutes to interpret and re-enter shipment details into the company’s transportation management system (TMS). The emails were complicated, containing a lot of information submitted in nonstandardized ways and varying formats. This repetitive task consumed valuable time, introduced errors, and delayed customer response.

N@TE uses generative AI and natural language processing to transform unstructured email content into structured pickup orders automatically and in real-time. N@TE scans incoming emails, extracts key shipment data, and creates orders directly in the TMS via API integration. It operates seamlessly within existing workflows, requiring no change in customer behavior or retraining of staff.

PITT Ohio deployed N@TE in 2025, and the company also secured a patent for the product that year. N@TE has produced a 30-60X increase in processing speed, 99% accuracy in extracting and populating order data, and a 70% reduction in handling costs per pickup order.

SMU builds AI adoption through grassroots ambassador program

Organization: Southern Methodist University

Project: Scaling AI Without Scaling AI: Organizational AI Scaling Through Willingness

IT leader: Jason Warner, Associate CIO

Like executives in most organizations, leaders at Southern Methodist University encountered mixed attitudes about AI. Some workers had little interest in using the tech, others were afraid it would take jobs, still others were curious about what it could do.

Associate CIO Jason Warner and other leaders decided to leverage that last group, believing the best way to get SMU faculty and staff to embrace AI was to use enthusiasts to help smooth the way.

So, instead of treating AI as a conventional technology rollout, Warner and his colleagues built opt-in communities of practice known as the AI Coalition of the Willing and Operation Copilot.

The goal, Warner says, was to build institutional capability, reduce risk, and generate momentum.

“We knew the fastest way to scale AI was to scale the willingness of people to use the technology, and not talking to people about cost savings and the like,” Warner says, adding that willing users as great ambassadors and evangelists who showcase in formal and informal ways the technology’s potential for hesitant or skeptical colleagues.

Participating faculty members have access to a licensed ChatGPT account as long as they use it. Staff members have access to Copilot accounts after taking a self-paced training course and likewise must use it to keep that access.

Warner says these willing workers are demonstrating the benefits of AI (significant time reclamation, reduced cognitive load, improved quality of outputs, expanded professional capacity).

SMU is now moving to a single solution and scaling AI, confident that its use will deliver returns following in the footsteps of the early adopters.

Interested in meeting and learning from all CIO 100 winners? Join us next week at CIO 100 Awards & Conference in Frisco, TX. Limited seats remain! Register here 

Apple continues work to get White House go-ahead to source memory from Chinese supplier CXMT, which the US government has placed restrictions on.

For Apple, the issue comes down to simple math. With the cost of making iPhones up 38% because of eye-watering memory price increases — up almost 7-fold since the beginning of 2025 — it makes sense to make pragmatic choices when it comes to sourcing supply, particularly when other computer companies (including HP and Acer) already obtain memory from CXMT.

US resistance to the plan is that because of the way Apple packages memory on chip, the use of that memory might partly contravene the technology transfer restrictions the US has in place. Note: use of off-the-shelf components is fine.

Apple has been lobbying to use memory from the supplier only on devices made and sold in China and would likely argue this is reasonable given that both HP and Acer already use CXMT memory in products sold outside the US. 

Why it’s really about supply

The iPhone maker’s dilemma isn’t just about memory price, it’s also about ensuring it has enough component supply to satisfy demand for its products. This is plausibly a bigger challenge for the company, which is already warning of constrained supply because of lack of available memory. Samsung, Micron, and SK Hynix have allegedly already sold through all their DRAM production for 2027, which only sharpens Apple’s case to secure alternate sources.

With that in mind, it matters that China consumes around 20% of all Apple hardware sold globally. All the company needs is the go-ahead to use RAM from CXMT in those Chinese-made, China-sold devices.

That alone would effectively grow its usable memory supply by the same amount, because the non-restricted memory it currently has to use in Chinese-market products could be freed up for devices sold elsewhere, with CXMT covering the China-sold units instead.

With demand for its products accelerating —even amid a broad industry downturn — Apple really wants to make sure it has enough of the component to meet demand. Those powerful, on-premises 1.5TB RAM-equipped M7 Ultra Mac Studio AI clusters won’t exist unless it’s possible to find memory to put inside them.

The timeline challenge

The proposed arrangement with CXMT might not be a quick fix. Recent reporting indicated the company has already reached its production capacity for 2026, though it is working to double capacity by 2028. Apple has already tested memory chips from the company across products including iPhones and MacBooks.

While Apple this year has applied steep price increases across all its products (except for iPhones), it is now expected to increase the cost of the current iPhone 17 models perhaps as soon as this week. 

Market reports already warn that Apple will raise prices on its soon-to-debut iPhone 18 Pro and iPhone Ultra devices next month, and we expect availability to be constrained, once again as a result of RAM shortages. Even if Apple gets the go-ahead to work with CXMT to close the gap, the positive impact of that arrangement is unlikely to kick in before next year.

Enjoy the pain

Elsewhere, big memory manufacturers, including SK Hynix, have announced plans to invest in new DRAM manufacturing capacity. But this will not be operational until 2029, at the earliest.

This suggests constrained product availability and higher prices for the coming months — and the only way Apple, or anyone else, will be able to limit the impact of those price increases across the entire electronics industry will be if they can obtain additional stocks of memory from vendors outside the big three. If they cannot, you can kiss the age of abundance goodbye.

You can follow me on social media! Join me on BlueSky,  LinkedIn, Mastodon and subscribe to The Core.

Each year the CIO 100 Awards showcase outstanding IT initiatives, and every year they illustrate the power and potential of technology to transform how people work, how organizations perform, and the value they offer to customers.

The 2026 cohort of winners is no different. Each one demonstrates how IT executives and their teams successfully move from ideation to deployment to scaling a solution for the future, overcoming challenges and driving adoption along the way to ensure their organization gets a return on its investment.

[ Interested in meeting and learning from all CIO 100 winners? Join us next week at CIO 100 Awards & Conference in Frisco, TX. Limited seats remain! Register here ]

The winning initiatives come from a range of industries and utilize a host of technologies to achieve their goals, as is the case annually. A growing proportion of these stand-out projects leverage artificial intelligence, raising the bar on the art of the possible for all IT departments.

The following 10 award-winning projects serve as representatives for the outstanding work done by all the 2026 honorees.

ABB democratizes AI agent creation and deployment

Organization: ABB

Project: ABBY — AI Agentic Platform for Workforce Transformation

IT leader: Vikke Kandell, CIO

IT leaders at ABB, a manufacturer, had some big hurdles to clear when it came to building an AI strategy.

They had to overcome employee fears that AI would take away jobs, the potentially high cost of AI vendor licenses, and pressure from investors, customers, and executives to advance the use of AI in the enterprise.

“We looked at this and asked, ‘How do we address all this?’ and build something that the company is proud of,” says Babu Kuttala, vice president of data analytics and AI.

The answer is ABBY, an AI agentic platform that enables employees to create and deploy specialized AI agents for specific business tasks.

To build ABBY, Kuttala and his team used best-of-breed LLMs (about 25 in total). They built a centralized orchestration layer using generative AI that integrates internal knowledge bases with external ecosystems, creating a unified platform where agents can access enterprise data, understand required actions, and execute tasks across multiple systems. And they created preconfigured skills so that employees could build agents tailored to their workflows without having to code.

ABBY was rolled out in 2025 to 100 users but is now used by 63,000 (more than 75% of the company’s workforce, Kuttala notes) with an average of 10,000-plus workers using it daily. IT continues to add LLMs and capabilities to expand use of ABBY even further, Kuttala says.

Belcorp modernizes manufacturing with Smart Factory

Organization: Belcorp

Project: QPlant — Smart Factory

IT leader: Venkat Gopalan, Chief Digital, Data, and Technology Officer

Legacy processes were limiting Belcorp’s ability to scale and compete. Its manufacturing relied on ERP-driven processes with limited shop-floor automation and weak connectivity across production, packaging, quality, and maintenance. The company depended heavily on manual records and post-process reconciliation, resulting in fragmented data, limited real-time insight, inefficiencies, and higher risks for errors.

Smart Factory changed all that. The IT initiative reimagined how manufacturing teams work “by creating a connected, data-driven environment where production, quality, maintenance, and operations are aligned around real-time information and standardized execution,” says Venkat Gopalan, chief digital, data, and technology officer.

At Smart Factory’s core is a manufacturing execution system that orchestrates production workflows, quality processes, and operational execution, he explains. IoT-enabled equipment integration and a centralized SCADA platform provide real-time visibility into shop-floor operations, while electronic batch records digitize production execution, strengthen traceability, and reinforce compliance by design.

Integrating those operational technologies with the company’s enterprise platforms was another critical component of success, Gopalan says, creating a trusted flow of real-time data across manufacturing, quality, maintenance, and business systems. “This connected architecture transformed isolated data into actionable insights, enabling faster decision-making, greater operational visibility, and continuous improvement across the manufacturing lifecycle,” he adds.

The initiative generated more than $1 million in financial benefits in its first year alone.

“Most importantly, Smart Factory established the digital foundation for the future of manufacturing at Belcorp,” Gopalan says. “With real-time operational data and connected systems now in place, we’re well positioned to accelerate advanced analytics, AI-driven optimization, predictive maintenance, and other Industry 4.0 capabilities that will continue delivering value for years to come.”

Cohesity replatforms post-acquisition for commercial growth

Organization: Cohesity

Project: Lead to Cash Replatforming Program (Veritas Integration)

IT leader: Brian Spanswick, CIO

Cohesity set an ambitious objective: Complete an enterprise-scale lead-to-cash replatform in under six months.

That’s a tight timeline for any replatforming initiative, but Cohesity’s project had another layer of complexity. It followed Cohesity’s December 2024 acquisition of Veritas, a company twice its size in revenue, leaving Cohesity to integrate the majority of a global enterprise revenue engine into its own operating model without disrupting customers, partners, or sellers.

“We had to bring the two companies together, merge the workforces together, and create an overall harmonized organization and operating infrastructure platform,” says Eric Brown, who as CFO and COO led the project.

The program migrated heavily customized CRM, CPQ, PRM, ERP, and subscription platforms (some of which were “very brittle, very bespoke,” Brown says) to a unified SaaS CRM, CPQ, and ERP environment with uninterrupted selling, billing, and partner operations.

This was no lift-and shift, Brown stresses. “It was a business process optimization project as well. We want to run very efficiently, so we questioned everything and used the migration process to simplify and streamline the business in every possible respect.”

The initiative enabled continuity for 13,000-plus customers, protected revenue during integration, and established a scalable commercial foundation for future growth.

Brown cites several factors that contributed to success. First, leadership was upfront about what it would take to meet the deadline, a process that involved carefully prioritizing the capabilities that would appear in the first iteration. Leadership also streamlined decision-making, establishing office hours that “ran with military precision” to handle issues. And the company selected a specialized partner, requiring its top talent be assigned to Cohesity.

Dairyland Power goes agentic to protect field crews

Organization: Dairyland Power Cooperative

Project: ODIN — Organizational Effectiveness Agentic AI

IT leader: Nate Melby, VP and CIO

Dairyland Power Cooperative had amassed a large collection of field observations, incident reports, near-misses, safety rules, and work methods that could yield insights into processes and practices that could help protect its workers.

But the insights were essentially out of reach, trapped in siloes.

Dairyland’s organizational effectiveness team turned to CIO Nate Melby for help unlocking those insights. Melby then turned to agentic AI, recognizing that the technology could address the team’s need to make better use of its data.

“This was about finding insights on how to work more safely,” Melby says. “It’s about preventing incidents.”

The collaboration between the two teams created ODIN, the first agentic AI implementation of its kind in the electric utility industry.

Focused on worker safety, ODIN autonomously connects the collective safety knowledge of the organization and delivers actionable insights directly to field crews at the moment work is planned.

ODIN was developed through a hybrid approach that combined an agentic AI platform and Dairyland’s internal private generative AI platform called VoltWrite. ODIN leverages LLMs, retrieval-augmented generation, and a coordinated swarm of autonomous agents.

Agents work together to analyze internal safety data, performance history, work practices, and safety rules and then synthesize the information into clear guidance on the safest way to perform specific tasks.

ODIN has produced results, including a reduction in OSHA recordable injuries and improvements in the quality and consistency of pre-job safety briefings.

ODIN was deployed in early 2025 for use by Dairyland’s workers in transmission construction and electrical maintenance, which are the highest-risk work areas. Dairyland is looking to expand ODIN’s use to other teams.

Dow’s digital sustainability ledger drives low-carbon sales

Organization: Dow

Project: Carbon Footprint Ledger

IT leader: Deb Bauler, Chief Information and Digital Officer

Executives at Dow consider the Carbon Footprint Ledger (CFL) as more than a technology or innovative carbon accounting methodology. According to Senior Global IT Director Jeremy Preston, CFL is “a digital business capability that enables Dow to translate sustainability investments into customer value.”

CFL transformed how Dow uses greenhouse gas emissions data. It combines a methodology aligned to international standards with an enterprise-scale digital platform. It also integrates manufacturing, supply chain, commercial, and sustainability data to generate product carbon footprints under enterprise-level governance and management at scale.

In doing so, Preston says it creates “a trusted, traceable link between low-carbon processes and raw materials implemented across its manufacturing network and the lower-carbon products customers seek.”

The technology team worked closely with sustainability and business teams, collaboratively developing the capabilities needed to reconstruct product genealogy, maintain end-to-end data lineage, track low-carbon attributes across interconnected manufacturing processes, and generate product carbon footprints that can support customer offerings and commercial transactions.

CFL was built on Dow’s Integrated Data Hub and in partnership with Boston Consulting Group and Databricks.

The core CFL platform is fully deployed and supports commercial transactions today.

Preston says CFL “enables Dow to turn sustainability investments into customer value, commercial differentiation, and new growth opportunities.” Dow reports that it has driven hundreds of millions of dollars in low-carbon product sales in 2025 and 2026.

The company is now expanding its use. “We are extending adoption across additional products, manufacturing networks, business segments, and customer use cases while continuing to enhance automation, analytics, and integration with commercial processes,” Preston says.

J&J transforms quality management with AI

Organization: Johnson & Johnson

Project: Q&C Strategy

IT leader: Michael Comprelli, Vice President, Head of Technology, Technical Operations, and Risk; Joel O’Connor, Head of Technology, Medtech Quality, and Compliance

Johnson & Johnson is using AI to transform quality management through its Q&C Strategy.

QuIn is an AI-powered digital assistant that fuses human expertise with machine learning, automation, and data-driven insights to boost efficiency, reliability, and worker impact. By embedding gen AI into core quality management systems processes, QuIn proactively gathers actionable insights, increases operational efficiency, and allows teams to focus on high-value, patient-centric work.

Cora is an innovative generative AI platform that provides regulatory intelligence monitoring, impact analysis, and augmented content revision. Cora assists with document analysis, compliance comparison, stakeholder analysis, policy/standard creation, procedural/document updates, and document comparison. Cora is purpose-built for regulated environments, validating outputs against source material and offering a user experience that instills trust in the outcome.

QuIn and Cora, which automate time-intensive tasks and democratize information access, are on track to deliver significant value, with J&J reporting more than $62 million in documented true cost savings by 2028 from QuIn alone. Cora delivered $2 million in cost efficiency in 2025 and will deliver a documented cost savings of $25 million by 2028.

“Our teams proved responsible AI can be applied meaningfully in a highly regulated environment without compromising the rigor, accountability, or human judgment that quality requires,” says Michael Comprelli, vice president, head of technology, technical operations, and risk.

He continues, saying that J&J “moved these ideas beyond experimentation and into products that employees use in their daily work. We did that by bringing together Quality expertise, product management, data engineering, architecture, cybersecurity, user-experience design and AI engineering around a common purpose.”

JLL brings intelligent automation to business services

Organization: JLL

Project: Business Service Digitization

IT leader: Pinak Dash, Global Head of JLL Business Services and Legal Technologies

JLL launched its digitization initiative to drive process redesign as well as systematic AI and RPA deployment across JLL Business Services (JBS).

The initiative was designed to address inefficiencies that hampered scalability and competitive positioning. It was also designed to eliminate manual processes that consumed thousands of hours across finance, HR, legal, procurement, marketing, research, IT, and lease administration.

Pinak Dash, global head of JBS and legal technologies, says the digitization initiative had a dual-strategy combining traditional digitization with generative AI innovation to hundreds of processes.

JLL lists three innovations critical to the program’s success.

First is a hybrid platform that integrates RPA with JLL’s proprietary AI platform called Falcon, which created intelligent automation that adapts and learns. It enables real-time process automation, intelligent document processing with automated extraction/validation, and smart decision-making for continuously optimizing workflows.

The second innovation is its use of ProHance for real-time process monitoring and enabling of data-driven optimization. Sensors capture granular productivity metrics, identify bottlenecks, and provide actionable insights for continuous improvement across automated and manual processes.

Third is its custom AI assistants and transaction agents. Falcon-powered assistants provide intelligent knowledge search while specialized agents execute complex transactions across enterprise SaaS platforms. These handle multisystem workflows, reducing human touchpoints while maintaining accuracy and compliance.

Dash says the initiative has delivered quantifiable benefits through improved efficiency, accuracy, and quality of services provided to clients.

“The initiative delivers on our business goals, makes us more efficient, provides customers better service, and it opens up the capabilities and bandwidth of our people to do what they like to do and to find innovative ways to serve our business,” he adds.

Nationwide partnership platform delivers efficiencies, business growth

Organization: Nationwide

Project: Enterprise Digital Platform (EDP)

IT leader: Michael Carrel, EVP and CTO

Nationwide’s new Enterprise Digital Platform (EDP) gives the company “a scalable way to connect with external partners quickly, securely, and consistently across all areas of our business,” says company EVP and CTO Michael Carrel.

He explains that “instead of treating every integration as a custom effort, EDP creates a common front door for digital products, documentation, onboarding and governance.”

That innovation has produced better experiences for the company’s partners. It saves time for Nationwide teams, partners, and customers. And it supports faster launch times for new products and enables growth across the business.

“EDP changed the model from fragmented, point-to-point integrations into an enterprise platform built around reusable digital products. That shift lets us support a range of integration options in one governed environment, meet partners at different stages of technical maturity, and add new capabilities over time without redesigning every relationship from scratch,” Carrel explains.

EDP uses cloud-native microservices, role-based access control, and advanced analytics. Nationwide IT created modular microservices to make EDP more scalable, resilient, and adaptable. And IT decoupled it from infrastructure-specific dependencies so that it would be a platform-agnostic developer portal. That, Carrel says, reduced operational constraints across environments.

Additionally, IT shifted from a user-specific model to role-based access, which improved security, simplified administration, and better served the needs of different audiences.

Meanwhile, robust analytics delivers visibility into platform usage and performance, which Carrel says helps ensure Nationwide continuously evolves the platform based on measurable outcomes.

The core platform is fully deployed, with Nationwide planning to expand it.

“Our Enterprise Digital Platform is more than a piece of technology,” Carrel notes, “it represents a strategic enabler to support growth objectives across Nationwide’s businesses.”

PITT Ohio fast-tracks shipment requests with AI assist

Organization: PITT Ohio

Project: No Touch Email (N@TE AI)

IT leader: Scott Sullivan, President and CEO (formerly CIO)

As PITT Ohio started its AI journey in 2024, the mandate was clear: Use the technology to solve “real problems,” says Ryan Carner, director of enterprise IT solutions.

“We wanted to hit the ground running and find a problem that was solvable,” Carner says, noting that the company also wanted to use the experience to build in-house AI skills. “The idea was to find a business case for AI that would be our first but not the only one.”

PITT Ohio leaders decided to tackle what Carner describes as a “mundane but very important task for how our business operates”: handling emails to the customer service team.

The need was significant. Customer service representatives were manually processing hundreds of pickup request emails daily, each requiring five to 15 minutes to interpret and re-enter shipment details into the company’s transportation management system (TMS). The emails were complicated, containing a lot of information submitted in nonstandardized ways and varying formats. This repetitive task consumed valuable time, introduced errors, and delayed customer response.

N@TE uses generative AI and natural language processing to transform unstructured email content into structured pickup orders automatically and in real-time. N@TE scans incoming emails, extracts key shipment data, and creates orders directly in the TMS via API integration. It operates seamlessly within existing workflows, requiring no change in customer behavior or retraining of staff.

PITT Ohio deployed N@TE in 2025, and the company also secured a patent for the product that year. N@TE has produced a 30-60X increase in processing speed, 99% accuracy in extracting and populating order data, and a 70% reduction in handling costs per pickup order.

SMU builds AI adoption through grassroots ambassador program

Organization: Southern Methodist University

Project: Scaling AI Without Scaling AI: Organizational AI Scaling Through Willingness

IT leader: Jason Warner, Associate CIO

Like executives in most organizations, leaders at Southern Methodist University encountered mixed attitudes about AI. Some workers had little interest in using the tech, others were afraid it would take jobs, still others were curious about what it could do.

Associate CIO Jason Warner and other leaders decided to leverage that last group, believing the best way to get SMU faculty and staff to embrace AI was to use enthusiasts to help smooth the way.

So, instead of treating AI as a conventional technology rollout, Warner and his colleagues built opt-in communities of practice known as the AI Coalition of the Willing and Operation Copilot.

The goal, Warner says, was to build institutional capability, reduce risk, and generate momentum.

“We knew the fastest way to scale AI was to scale the willingness of people to use the technology, and not talking to people about cost savings and the like,” Warner says, adding that willing users as great ambassadors and evangelists who showcase in formal and informal ways the technology’s potential for hesitant or skeptical colleagues.

Participating faculty members have access to a licensed ChatGPT account as long as they use it. Staff members have access to Copilot accounts after taking a self-paced training course and likewise must use it to keep that access.

Warner says these willing workers are demonstrating the benefits of AI (significant time reclamation, reduced cognitive load, improved quality of outputs, expanded professional capacity).

SMU is now moving to a single solution and scaling AI, confident that its use will deliver returns following in the footsteps of the early adopters.

Interested in meeting and learning from all CIO 100 winners? Join us next week at CIO 100 Awards & Conference in Frisco, TX. Limited seats remain! Register here 

Four months ago, a front-end engineer on my team looking to make upgrades to a product or feature would have filed a ticket and waited for the infrastructure group to unblock them. They might have lost a day, sometimes a week. Today, that same engineer makes changes themselves. The code is occasionally brittle, but it works, and the end result ships in a fraction of the time it used to take.

That small story is unfolding inside nearly every engineering organization right now. While some celebrate the sudden fact that one person can do the work of five, others are focused entirely on tech industry layoffs. Both perspectives skip the question I find more interesting: What happens to mastery when every engineer can suddenly do everything?

For two decades, we have described strong engineers as T-shaped. The horizontal bar represents breadth, which is a working familiarity across many areas. The vertical bar represents depth, the real command of one domain earned over years. Agent tooling has stretched that horizontal bar wider than ever before. My concern is the vertical bar, which is quietly getting shorter.

Consider what is now possible in a single quarter. With the right agent harness, one engineer can stand up a billing system, a data connector framework, regional and organizational tenancy infrastructure, or a consumption-based pricing implementation. The pull requests pass review. The tests are green. All looks good. But green tests cannot tell you if the person who shipped that work understood why the system needs redundancy in one specific place, where its failure modes are hiding, or which trade-offs the model made silently on their behalf. The pattern recognition that comes from watching systems fail over many years is suddenly weighted differently than it was even 12 months ago. Our industry has not caught up to that shift.

When the interview stops measuring judgment

The first place this surfaces is hiring, a trend that should concern anyone who has built a team. Traditional coding interviews were always an imperfect proxy for engineering judgment, but agent tooling completely obliterates them. If a candidate can produce a working solution in 20 minutes that would have taken two hours a year ago, the exercise no longer measures technical competence. It just measures how well a coder can prompt an agent.

At Thread AI, we have responded by widening what we look at when we interview job candidates. Our process moves across coding exercises, problem decomposition, system architecture, and behavioral components, with the weighting shifting by role. We allow AI assistance only in specific sections because our engineers still need to be able to operate without it. Some of our work happens in secure environments where you cannot lean on an agent to debug for you. What we’re really testing for now is judgment under ambiguity — the ability to notice when an agent’s output is confidently wrong — and the depth to predict where a system will break before it breaks.

Hiring teams that fail to make this shift will fill their rosters with false positives. They will hire people who interview like experts but struggle the first time a system behaves in a way the model did not anticipate. Ultimately, these companies will miss out on top-tier talent, and they won’t discover the misstep until it’s too late.

Confusing velocity with understanding

That brings me to a larger risk: the rise of false expertise as a category of its own. Historically, the reasoning has gone, “I built a proof of concept, therefore I am an expert.” I have watched versions of this appear in technical leadership, in investment decisions, and in policy conversations about AI. It travels well because the artifact looks real. A working demo is highly persuasive, even when the person behind it only half-understands how it functions.

The problem is bigger than one false expert shipping one bad product; an organization can absorb that. The real risk is a generation of consequential decisions being made by people who have confused velocity with understanding. You can already see the cultural scaffolding being built around this with the celebration of the “idea guy,” and the sudden fashion for invoking “taste” as a substitute for knowing how a system actually works. Those of us shaping tooling, hiring norms, and regulations have a narrow window to set better defaults before this pattern hardens into the way the industry operates.

Depth and breadth, held together

This is the path we’ve been walking at Thread AI since before the latest wave of tooling arrived.

To ground this in a specific example: I have spent 15 years building complex systems. I worked at Goldman Sachs through the financial crisis and the early Dodd-Frank infrastructure, moved critical payment systems into the cloud at The New York Times when that ground was still new, and built the system of record for model training and evaluation at Palantir across highly regulated environments in defense, health, and finance. This experience is the superpower that lets me course-correct an agent when it produces confident-but-wrong output.

I felt this sharply not long ago while scoping consumption-based pricing in a single quarter. The agents did an enormous amount of the heavy lifting, and at some point, I realized that my largest contributions to the effort were knowing where the system would fail and steering around it before we got there. I have also seen how organizations have built large teams around efforts like these in the past. Someone earlier in their career or relying purely on AI guidance would not have had that instinct to draw on. That is the part the public conversation keeps missing.

Every engineer at Thread AI, regardless of seniority, is expected to be a builder at heart. Our people own outcomes across compute, data, and the organizational and identity primitives that hold the product together, all without the traditional product-manager and project-manager scaffolding around them. Our model works only because the people in those seats have the depth to know what they do not know, and the breadth to fill the gaps with agents. They use the tooling instead of being used by it.

AI doesn’t replace deep understanding

The core issue facing organizations today is not whether AI will replace engineers. That question has been answered dozens of times this year with varying degrees of nuance, and it has stopped being interesting. The more useful question for anyone running a company is whether we are protecting the people who understand our systems deeply enough to recognize when the machines are wrong.

In our company, the answers have been to move toward explicit end-to-end ownership, and to hire for depth and breadth together rather than treating them as a trade-off. Layoffs dominate the headlines because they are an easy narrative, but they describe a symptom rather than the actual choice in front of us. The real choice is whether we let breadth quietly stand in for mastery, or whether we build organizations that keep human judgment in the loop on purpose.

In an era when software can be generated faster than it can be understood, the companies that hold onto what is human, verifiable, and deeply understood will be the ones still standing when the brittle parts give way.

—

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.

Bending Spoons has snapped up Airtable to add to its portfolio of software companies, alongside AOL, Evernote, WeTransfer, Brightcove and Vimeo

Airtable made its name as a builder of low/no code database services, aimed particularly at non-technical staff, but is now one of many vendors facing financial difficulties in the face of the SaaS/AIpocalypse. The arrival of AI coding tools, which offer non-technical employees more flexible ways to build business applications, has hit demand for its services.

Bending Spoons bought Airtable in a deal it valued at just $1.285 billion, a far cry from the $11.7 billion Airtable was worth at its peak.

Bending Spoons has built its portfolio by buying once-successful companies like Airtable that have struggled to cope with newer, nimbler competitors or failed to adapt to emerging technologies. Bending Spoons takes these companies, cuts costs and markets them aggressively with the goal of returning them to profitability.

“Airtable is a pioneering brand reshaping how teams organize data and manage critical workflows. We’re committed to investing in Airtable for the long run, and doubling down on its core strength: bringing teams and workflows together in one flexible workspace. We plan to expand what can be done across the full spectrum of work and make Airtable even more valuable to customers at every scale,” said Luca Ferrari, Bending Spoons CEO and co-founder.

As Europe swelters in a heatwave, residents probably don’t want to hear about ways to make their homes even hotter, but that’s what Polish property developer Citylink is talking about, with plans to dump waste heat from a new data center in Wrocław into the municipal district heating network.

Citylink is designing the data center so that heat from servers can be recovered instead of being dissipated via cooling systems — and as the data center grows, any increase in computing power will mean more energy available for recovery.

The collaboration with local power company Kogeneracja will provide “valuable experience in designing and operating modern data centers, with a particular focus on infrastructure dedicated to AI nodes,” said Michał Starybrat, development director at Citylink.

“The dynamic growth of the artificial intelligence and cloud technology markets generates unprecedented demand for computing power, this collaboration demonstrates how modern digital infrastructure can actively contribute to building the energy ecosystem of the future,” he added.

This type of initiative is not new. There have been similar projects in the UK and in New Zealand, but with warnings that data centers are contributing to the warming of the planet, there may well be a lot more organizations looking to deploy that excess heat more fruitfully in the future.

However, announcing it during a heatwave may not be the most politically sensitive approach to take.

This article first appeared on Network World.

Wispr, the startup behind dictation tool Wispr Flow, has created an AI note-taking assistant that records meetings and generates conversation summaries for users.

The Wispr Flow Notetaker tool “captures your meetings so you can stop splitting your attention between listening and writing things down,” said Sahaj Garja, Wispr CTO and co-founder.

Notetaker starts recording with one click, and doesn’t require a bot to attend a video or voice call. It can also be used to capture in-person conversations.

The software has three key functions. Before a call, Notetaker displays a meeting brief with information such as meeting purpose and background of participants.

Once the meeting starts, a live transcript displays the dialogue text and labels speakers. A “what did I miss?” button provides a summary of talking points from the previous few minutes.

Finally, post-meeting, Notetaker generates a more detailed summary organized by topic that includes information such as key dates, decisions, and next steps. Users can search across notes from previous meetings in the Notetaker app. “Over time your meeting history stops being a folder of documents you have to go find and becomes something you can ask questions of,” said Garja.

Notetaker integrates with AI assistants such as Anthropic’s Claude and OpenAI’s ChatGPT via model context protocol. This allows users to connect outputs such as transcripts and summaries “into how you already work, instead of sitting in a separate app,” said Garja.

With Notetaker, Wispr competes in an increasingly busy market for AI note-taking apps that includes Fireflies, Granola and Otter.

Wispr claims Notetaker can produce more accurate transcripts than existing tools, partly because of the additional context it uses during transcription. It uses the same personal dictionary from Wispr Flow that includes acronyms, products, and preferred spellings, and can also draw on other sources such as calendar information to understand the purpose of a meeting and help ensure speakers are labelled correctly.

Before generating the final summary, Notetaker also re-reads the live meeting transcript and combines it with additional context to create a more accurate final output, Garja said.

Notetaker is the first new product launched by Wispr, which was founded in 2021 and has since raised $81 million in funding.

“We didn’t set out to build a dictation app,” said Garja. “The mission has always been to reshape how people interact with their devices, and dictation was the fastest way in.”

“Notetaker is the second product on that path. Dictation took the keyboard out of writing. Notetaker takes it out of meetings, so nobody has to spend the call typing up what everyone just said.”

User consent when recording calls

As AI note-taking tools have become more prevalent in the workplace, privacy concerns have arisen, including the need for all-party consent when recording a call in some jurisdictions, and whether meeting audio is used to train AI models. Two software vendors, Otter and Granola, currently face separate lawsuits in California that allege privacy law violations related to their products.

Wispr Flow Notetaker captures audio locally on a user’s device rather than joining the call as a visible bot. That means there’s no notification to signal that a conversation is being transcribed, which places responsibility on users to disclose the recording to others on the call in accordance with local laws, said Garja.

“Users should always let the other person know before you start recording or transcribing a conversation, whether it’s a video call, an in-person meeting, or a phone call,” he said, adding that Wispr intends to build additional features for automated consent messaging “in the coming weeks.”

Wispr doesn’t train its AI models on customer data without consent, though free and standard tier customers must choose to opt-out, according to Wispr’s privacy terms. Nor does it create “voiceprints or biometric profiles” of users or anyone else on a call using audio recording data, the company says.

When Notetaker is active, conversation audio is captured on a user’s device and processed on cloud servers to enable transcription. The recorded audio file is encrypted and stored temporarily on the user’s device or cloud storage, Wispr said. After a limited period, the audio is automatically deleted.

Notetaker is available with the Wispr Flow macOS app to free and paid subscribers, with support for Windows “coming soon.”

On March 24, 2026, developers building AI applications with LiteLLM — a Python package with 95 million monthly downloads — unknowingly installed malicious code. A threat actor group known as TeamPCP had compromised the PyPI distribution pipeline and pushed malicious versions 1.82.7 and 1.82.8 to the package index. The payload was subtle: a .pth file, a little-known Python mechanism that auto-executes code every time the interpreter starts. If you installed either compromised version, malicious code ran silently — no explicit import needed.

That is not the exception anymore. It is the pattern.

What is actually happening

ReversingLabs reports that malicious open-source packages rose by 73% in 2026. The LiteLLM attack was part of a broader campaign by TeamPCP that systematically compromised widely trusted open-source security tools — including Aqua Security’s Trivy and Checkmarx’s KICS — before moving into AI infrastructure libraries hosted on PyPI.

The attack chain for LiteLLM followed a now-familiar sequence. TeamPCP obtained the maintainer’s PyPI publishing credentials, pushed malicious versions that were virtually indistinguishable from the official package, and embedded a multi-stage payload designed to harvest high-value secrets: AWS, GCP and Azure tokens, SSH keys and cloud account credentials. According to Zscaler ThreatLabz, the poisoned packages were available for approximately three hours before quarantine. Three hours was enough to reach tens of thousands of corporate environments.

And it did not stop with LiteLLM. In late April 2026, PyTorch Lightning versions 2.6.2 and 2.6.3 were found to contain credential-stealing malware that executed on import. A single malicious workflow file exposed secrets across entire CI/CD pipelines.

Why AI development environments are uniquely exposed

Most supply chain attacks are bad. Supply chain attacks targeting AI development environments are worse.

AI and ML environments blend development, research, cloud infrastructure, data access, model publishing and automation inside the same workspace. A compromised Python package in a standard web application might steal a database credential. The same attack in an AI development environment can expose model weights, training data, cloud tokens across multiple providers, CI/CD pipeline secrets and production API keys — simultaneously, from a single infected dependency.

There is a second layer that most security teams are not accounting for. When developers use AI coding assistants to write code, those assistants frequently suggest pip install directives and import statements that reference specific packages. If the developer trusts the suggestion and installs the named package, and an attacker has already registered a malicious package under that name, the attack succeeds without the attacker ever interacting with the developer directly. Researchers have named this slopsquatting — and recent research found that across nearly 200,000 Python prompts, every major LLM generates hallucinated package names that do not exist on PyPI, creating a persistent attack surface that no individual model update can fully address.

Your developers are not doing anything wrong. They are using the tools that make them productive. The security assumption underneath those tools is broken.

3 controls that matter right now

1. Pin your dependencies and verify integrity

Floating version specifiers — requests>=2.0 rather than requests==2.31.0 — allow package managers to silently pull updates that include malicious code. Pin every dependency in your AI development environments to an exact version and verify checksums against a known-good hash. This alone would have limited the blast radius of the LiteLLM attack to environments that explicitly upgraded to the compromised versions rather than any environment that ran pip install litellm without constraints.

2. Audit post-install hooks in your development pipeline

The LiteLLM attack embedded its payload using Python’s .pth file mechanism — code that executes automatically during interpreter initialization, before any import statement runs. Post-install hooks and .pth file manipulation are a documented attack class, but enforcement in developer environments is inconsistent. Require review of packages that include post-install scripts before they reach developer machines. Tools like Socket and Sonatype provide real-time analysis of PyPI packages for malicious behavior before installation. This is not a nice-to-have. Given the pace of AI tooling adoption, it is a basic control.

3. Rotate cloud credentials immediately after any suspected exposure

The LiteLLM payload targeted AWS, GCP and Azure tokens specifically because those credentials provide lateral movement across cloud environments. If your development pipelines pulled LiteLLM during the March 24 exposure window, treat every cloud credential accessible from those environments as potentially compromised and rotate them. Review your cloud provider audit logs for activity patterns that do not correspond to developer-initiated requests — the signature of a stolen token being used by an attacker in a different location.

What this means for security teams

The TeamPCP campaign is not the end of this pattern. It is a proof of concept that AI infrastructure is now a target class. LiteLLM, PyTorch Lightning and the tools in between are packages your AI teams depend on every day. The attackers know that. They know that developers move fast, that AI tooling adoption outpaces security review cycles and that a malicious .pth file is invisible to most endpoint detection products.

The controls above are not complex. They do not require new vendors or new platforms. They require treating Python package installation in AI development environments with the same rigor you apply to production deployments — because in 2026, the distance between a developer’s local environment and your production infrastructure is shorter than it has ever been, and attackers have noticed.

Your developers trust their tools. Make sure that trust is warranted.

AI-generated vulnerability patches still heavily depend on human review, particularly the ones involving security-sensitive code, according to a research.

Researchers from 1Password have disclosed an internal evaluation that found AI-generated fixes frequently overlook broader concerns such as architectural intent, business requirements, security implications, and long-term maintainability, despite being syntactically correct.

“We studied what happens when Large Language Models (LLMs) generate vulnerability patches for recently disclosed, complex vulnerabilities,” said 1Password researcher Keith Hoodlet in a blog post. “Our data shows that LLMs produce Fix-Like Artifacts with Embedded Defects (FLAWED) 53.9% of the time when complex patches are required.”

The evaluation tested the AI-generated fixes across six recently disclosed CVEs, including CVE-2026-31431 (“Copy Fail”), CVE-2026-34197 (ActiveMQ RCE), CVE-2026-8512, CVE-2026-45185 (EXIM RCE), CVE-2026-22738 (SpringAI SpEL RCE), and the Gemini CLI RCE (GHSA-wpqr-6v78-jr5g).

1Password reportedly evaluated 6080 patches generated using ChatGPT-5.5 and Claude Opus 4.8, two frontier AI coding models, and found that only a little over a quarter of the fixes fully remediated the flaw without altering application behavior.

“Patches that successfully resolved the vulnerability, but altered the application’s behavior in the process, occurred 20.1% of the time,” Hoodlet added.

Fixing is not the same as securing

Instead of simply checking whether the fixed code compiled or passed automated tests, 1Password said it reviewed every generated fix for complete elimination of the vulnerability, preservation of application behavior, and avoidance of new security risks.

While only 26% of the patches successfully fixed the vulnerability without introducing application changes, 49.3% failed to remove at least one exploitable attack path, 2.3% fixed the original vulnerability but introduced a new one, and 2.2% both failed to remediate the issue and created an additional security weakness.

The researchers also found that passing pre-defined tests can create deeper problems. More than one-third of the patches that initially appeared successful were classified as “fragile” because they simply blocked the proof-of-concept (POC) exploit used during testing instead of addressing the underlying root cause.

Hoodlet explained this with the example of the SpringAI CVE patches. Both GPT and Claude models were found generating patches that targeted specific characters from the input string used in the POC presented to them, leaving the root cause untouched.

“If the guarded code were to become reachable again by using alternative inputs, it would lead to the old vulnerability resurfacing in the software,” he noted.

Human review remains the last security control

1Password argues that these shortcomings stem from the contextual reasoning required to produce production-ready security fixes.

Anthropic was reached out to and reportedly recommended keeping humans in the loop. “Patch generation has outpaced patch verification, and the fix is to make verification execution-grounded rather than inspection-based, while keeping domain experts as the final reviewers at current model capabilities,” it was quoted as saying.

1Password also challenged the notion that AI-generated patches are effectively “free.” While the average patch-and-validation cycle cost approximately $2.11 using ChatGPT-5.5 and $2.81 using Claude Opus 4.8, Hoodlet argued that the real expense lies in validating whether those patches are secure enough for production.

For years, applicant tracking systems and recruiting platforms were treated as HR technology: Important for workflow, efficiency, compliance and candidate experience, but rarely viewed as core security infrastructure. That assumption no longer holds. Once AI begins reading resumes, scoring candidates, conducting interviews, ranking applicants and influencing who moves forward, the hiring platform stops being a passive system of record. It becomes a decision system.

And any system that accepts public input, processes sensitive data and influences business decisions belongs inside the security conversation.

I learned this during an AI hiring platform rollout that never made it to production. The vendor was established, the product had a strong market reputation and the AI feature looked attractive: Upload a resume, compare it to a job description and return a neat percentage match. For recruiters, it promised speed. For executives, it promised modernization.

Before moving real candidate data into the system, I tested it with synthetic resumes. One weak resume came back with a surprisingly strong match. The reason was not hidden in the candidate’s experience. It was hidden in the text. The resume contained language instructing the AI to treat the candidate as an excellent fit, and the system appeared to follow that instruction instead of evaluating the resume on merit.

That changed the question from “Does the tool improve productivity?” to “Can the person being evaluated influence the evaluation itself?”

That is a security question.

The trust boundary has moved

CIOs do not need to become recruiting experts. They only need to look at the mechanics.

An anonymous user submits content into an enterprise system. That content is processed by software. The software then produces an output that can influence a business decision. In every other environment, security teams know what to call that: untrusted input crossing a trust boundary.

The difference is that in hiring, the input looks harmless. It is a resume, a cover letter, a chatbot reply or a spoken answer in an AI-led interview. But once AI reads that content and treats it as instruction, the harmless-looking input becomes part of the system’s control surface.

That is why prompt injection matters in hiring. It is not just an AI oddity or a model behavior issue. It is the same category of failure enterprises have spent decades trying to prevent: User-controlled input changing what the system does. OWASP lists prompt injection as the first risk in its Top 10 for LLM applications, describing it as a case where user prompts alter a model’s behavior or output in unintended ways.

In hiring, the implication is direct: A candidate may be able to manipulate the score, ranking or interview assessment that determines whether a human ever sees them.

The business impact is not theoretical

The obvious risk is that an unqualified candidate moves forward. But the impact is broader.

First, decision quality degrades. Hiring teams adopt AI scoring because they believe it improves signal. If the score can be manipulated, the business is not gaining signal; it is gaining false confidence. Recruiters may spend time on candidates who gamed the system while stronger candidates are buried lower in the queue. A tool bought to reduce friction can quietly create more of it.

Second, cost increases under the appearance of efficiency. Every false positive consumes recruiter time, hiring-manager attention, interview slots and opportunity cost. A small weakness in screening integrity can become a measurable operational drag across open roles.

Third, trust suffers. Candidates already question whether AI hiring tools are fair, explainable or accurate. If it becomes clear that a screening system can be manipulated by hidden instructions or verbal prompting, the issue is no longer just security. It becomes reputational. Strong candidates may lose confidence in the process, and employers may have to defend decisions made by systems they did not fully understand.

Fourth, sensitive data exposure becomes harder to contain. Recruiting systems hold names, addresses, work histories, education histories, compensation details, work authorization information and sometimes accommodation or demographic data. NIST guidance on personally identifiable information includes employment information as linkable personal data that must be protected from inappropriate access, use and disclosure. Yet hiring platforms often receive less security scrutiny than systems holding customer or financial data.

That mismatch is dangerous: High-value data, public-facing workflows and increasing automation.

The 2025 McHire incident should have made this impossible to ignore. Researchers reported that weaknesses in McDonald’s AI hiring platform, including default credentials and an access-control flaw, exposed applicant data at large scale before the issue was patched. The lesson for CIOs is not merely that a weak password was used. The lesson is that AI hiring systems can ship with basic, preventable security failures while still being treated as HR tools rather than enterprise risk surfaces.

Vendor reputation does not transfer to every AI feature

One reason this risk slips through is that buyers often trust the platform brand. Mature vendors may have strong security programs, enterprise customers, compliance documentation and procurement-friendly answers.

But AI features can change the architecture of risk.

A platform that was safe as a workflow tool may behave very differently once it adds resume scoring, interview grading, chatbot screening or automated ranking. The new feature may introduce new inputs, new model behavior, new data flows, new third-party dependencies and new decision points. In practical terms, the attack surface has changed.

CIOs should not allow AI features to inherit trust automatically from the legacy platform around them. When a vendor adds AI, the enterprise should reassess the feature as if it were a new product. That does not mean slowing innovation for bureaucracy. It means AI-enabled decision-making carries different failure modes from ordinary workflow automation.

The ownership gap is the real vulnerability

The biggest risk may not be the model. It may be the ownership gap.

Talent acquisition may buy the tool. HR operations may configure it. The vendor may guide implementation. Procurement and legal may approve the contract. But who owns the security of the candidate-facing AI layer?

In many organizations, the honest answer is unclear.

That ambiguity is where risk grows. Recruiting technology sits at the intersection of public input, sensitive data, third-party software, automated decision support and brand trust. That is exactly the kind of environment that needs named security ownership, asset inventory, vendor review, access-control testing, logging and incident-response planning.

If the hiring stack is not in the security inventory, the organization is already making an assumption it may later regret.

What CIOs should require now

The fix is not exotic. It is applying existing security discipline to a surface that has been underestimated.

Treat every candidate submission as untrusted input. Resumes, cover letters, chatbot responses, interview transcripts and spoken answers should be handled as attacker-controllable content. If AI processes it, the system must separate content from instruction.

Reassess vendors when AI features are introduced. A prior security review should not be treated as permanent approval for new AI capabilities. Ask what changed in the architecture, what data the model sees, what actions it can influence and how manipulation attempts are detected.

Ask AI-specific questions before signing. Can candidate-provided content alter scoring? Are hidden instructions filtered or ignored? Is there human review before AI output influences a decision? Can the vendor produce testing evidence for prompt injection, access control and data exposure risks?

Assign ownership. HR can own the process, but security must own the risk model. AI hiring systems should be included in third-party risk management, application security reviews, access governance, monitoring and incident response planning.

Measure business impact, not just AI adoption. The goal is not to say the recruiting function uses AI. The goal is to improve hiring speed, quality, fairness and cost without creating new risk. If the system cannot protect decision integrity, the business case is weaker than it appears.

The hiring platform is now part of the enterprise attack surface

AI has turned the careers page into more than a front door for applicants. It is now a public input channel feeding systems that store sensitive data and influence workforce decisions.

That makes it a CIO concern.

The next failure in AI hiring may not look like a traditional breach at first. It may look like bad rankings, manipulated scores, unexplainable decisions, wasted recruiter time or a candidate process no one trusts. But underneath those symptoms is a familiar security problem: A system trusted input it should have treated as hostile.

Enterprises have hardened payment systems, customer portals, APIs and employee applications around that lesson. Hiring deserves the same treatment.

AI hiring is not just an HR transformation. It is a security boundary. And it is time CIOs treated it like one.

There’s something very attractive about saying “we embed very closely with our customers and just figure it out with them”, especially since the company that started “forward deploying engineers” is growing 84% with $5B+ revenue. But “forward deployed engineer” is a vague term and means different things depending on the business you’re running.

I spent almost 5 years at Palantir as a forward-deployed software engineer, and Palantir’s version of an “FDE” does not make sense for most companies I now meet as an early-stage VC. Depending on the type of business you’re building, this role could broadly mean one of two things: “the product builder” or “the platform operator.” Clearly defining which bucket you fall into will make it easier to hire for this role and run your FDE org.

The product builder: The OG Palantir version

The north star is: do whatever it takes to actually solve the user’s problem. FDEs are not just responsible for making the platform work, but also discovering what to build and building it (actually creating software) in service of the customer.

The platform operator: Solutions + technical customer success

The north star is: make the product work for the customer – deploy and operationalize it. This is what most startups today really mean when they want FDEs. FDEs here configure the core platform, manage account relationships and drive adoption. This is not new – companies have always had solutions engineers, sales engineers, customer success etc., although the work looks different as FDEs are increasingly building prototypes, configuring evals and building MCPs.

Which FDE is right for you

For most situations, hiring product builder FDEs is a mistake.

At scale, the FDEs should be the platform operator. It’s hard to have FDEs build and maintain highly custom product features, especially as the company scales. Over time, the custom product surface area distracts from building the core product, even though AI coding tools make it easy to ship new features quickly and maintain them.

Many fast-growing AI startups recognize these constraints and structure the FDE role more like the platform operator. This also allows them to have 5-10 accounts per FDE, which is a much higher ratio than Palantir had (at least in 2023). Even the Palantir FDE role has evolved to look more like the platform operator.

There are, however, situations when your FDEs should be the product builder archetype.

1. You have very large customers (F500 scale)

Technical complexity: Large customers have complex environments with legacy infrastructure that often requires “out-of-platform” engineering work. I often encountered bespoke data infrastructure, privacy requirements, etc. at various Palantir customers that required me to build “out-of-platform” connectors, UIs and backends.

Organizational inertia and trust: Serving large enterprises is about building trust. In short time periods, overfitting product to a specific user/workflow is often what delivers the most value, builds trust and helps organizations get over the inertia of moving away from Excel and legacy software tools that are part of their day-to-day workflow. For AI-native startups, it’s arguably even more important to invest in doing “unscalable” development with engineering boots on the ground, as it helps solidify your right to exist and eventually expand the customer relationship.

2. You have many ICPs and workflows

If you have a broad range of ICPs and workflows that you serve, your product probably is not walk-up usable on day 1 of deployment. The short-term hacky things that product builder FDEs build to make the product work for these heterogeneous users/workflows will help you shape the product long-term.

Note: see Palantir Foundry’s architecture here.

This was a big reason why Palantir FDEs were more like product builders (and are still able to – see the Forward Deployed Software Engineer job profiles as an example). The vision for Foundry was to be the operating system for an enterprise’s critical decisions – inherently multiple industries, users and workflows. A lot of FDE-led development showed that solving many of these use cases required complex data integrations, which led to the early versions of Foundry being best-suited for complex data integrations and building a customer’s “Ontology”. Similarly, FDEs like myself built custom frontend applications for fraud analysis, pricing, etc. As certain patterns of what these applications required became more clear, they were centralized into an application-layer product.

Who you should hire

Platform operator: There is a much broader set of people you could hire, testing for technical fluency (e.g., being good at data analysis, complex Excel work, even SQL), product intuition and an inclination to build customer relationships. Backgrounds like technical customer success, solutions engineering, software engineering, product management and consulting are all strong fits.

Product builder: You want candidates that are high ownership and missionary software engineers, or technical PMs who want to ship products themselves.

Hiring for these profiles, especially product builders, is hard. It’s worth calling out two things that helped Palantir hire software engineers into what might be considered a less sexy role.

1. Culture of building at the edge: Strong engineers are motivated to build things. Palantir gave FDEs a lot of ownership to build products, which is why much of the core product leadership was former FDEs.
2. Cult built around mission: Internally, there was a cult-like devotion to the mission. Everyone always talked about why outcomes were far more important than software, and why most companies building tools had it wrong. I’ve never been at a company where people feel so closely bonded around a mission.

As founders building AI startups think about hiring FDEs, it’s worth being specific about your culture and asking: Am I just hiring people to support development teams, or am I hiring people to shape and build product? It’s hard to get software engineers (even today) to be excited about an FDE role that might just be technical customer success.

What FDEs should be doing (regardless of archetype)

You’ve hired the right people. How do you best leverage your team of FDEs?

FDEs were Palantir’s way of delivering outcomes rather than tools. AI-native startups can take this much further and FDEs can help in a few unique ways by leveraging their proximity to customers.

1. Find the most critical workflows: As AI lowers the cost of producing software, companies will face a lot more competition. FDEs at AI startups should be constantly finding ways to serve the most critical workflows for a customer and paying attention to how customers do work across newer and legacy tools. For example, FDEs at Harvey should pay attention to which workflows are in Westlaw, which ones are moving to ChatGPT/Claude, and how the Harvey product can stay ahead.
2. Build around nondeterminism: In more regulated environments, FDEs should be hyper-focused on making products reliable for specific use cases using evals and configs. Previously, product reliability lived with product and support. As companies provide outcomes instead of tools, configuring products appropriately and managing evals shifts towards FDE teams.

Business application development is entering a new operating model. The traditional approach of gathering requirements, designing screens, writing services, integrating systems, testing, fixing defects and preparing release documentation still exists, but it is no longer sufficient for enterprises that need speed, traceability, resilience and regulatory confidence at the same time. Hyperautomation brings a broader discipline to this challenge. It combines workflow orchestration, intelligent document processing, robotic automation, API-led integration, process mining, test automation, observability and artificial intelligence into a connected delivery fabric. With embedded Generative AI, this fabric becomes more adaptive because applications can interpret natural language, summarize complex data, generate explanations, detect exceptions and support decision workflows rather than merely execute predefined rules.

In banking, this shift is especially meaningful. Banks operate across dense application landscapes: trade reporting platforms, wealth management portals, core banking systems, investment banking applications, digital compliance engines, reconciliation utilities, operational dashboards, audit repositories and daily, weekly and monthly reporting platforms. Each of these areas has its own data models, control points, integration patterns, validation rules, exception paths and regulatory obligations. Hyperautomation does not replace engineering discipline; it strengthens it by making business intent, technical execution, control evidence and continuous improvement part of the same lifecycle.

From automation to hyperautomation in banking applications

Automation usually addresses a specific task: moving data from one system to another, generating a report, running a batch job or validating a transaction against a rule. Hyperautomation goes further. It looks at the complete business outcome and asks how the entire chain can be streamlined, governed, observed and improved. For example, a trade reporting process may begin with transaction capture, enrich the trade with reference data, validate regulatory fields, identify breaks, generate a submission file, transmit it to a regulator or trade repository, monitor acknowledgements and preserve audit evidence. A narrow automation script may accelerate one step, but a hyperautomated design coordinates the complete flow, including exception handling and evidence generation.

Figure: Automation vs. hyperautomation

Embedded Generative AI adds a new layer of intelligence. Instead of forcing every user interaction into rigid screens and codes, business applications can accept natural language prompts, interpret document content, summarize cases, generate draft responses, explain anomalies, produce test scenarios and create release notes. In a banking environment, this intelligence must be carefully bounded. Every AI-assisted action should be traceable, explainable, reviewable and aligned with data privacy, model risk, information security and regulatory expectations. The goal is not uncontrolled autonomy; the goal is governed acceleration.

Banking application components suitable for hyperautomation

A modern banking application is rarely a single monolithic system. It is a composition of business capabilities, integration services, workflow engines, data pipelines, user experience layers, analytics models, control dashboards and audit stores. Hyperautomation can accelerate the development and integration of these components by turning repetitive engineering work into reusable patterns and by embedding intelligence directly into business processes.

• Trade reporting applications: Generative AI can help map trade attributes to regulatory fields, explain validation failures, summarize rejected submissions and generate test cases for reporting scenarios. Hyperautomation can orchestrate enrichment, validation, submission, acknowledgement tracking and evidence archival.
• Wealth management platforms: Advisors can use embedded AI to summarize client portfolios, generate suitability narratives, identify missing documents and prepare personalized investment review notes. Automation can coordinate onboarding, risk profiling, document verification, portfolio rebalancing workflows and client communication approvals.
• Core banking applications: Account opening, loan servicing, deposits, payments, interest calculations and customer maintenance can benefit from automated validations, intelligent forms, workflow routing and natural language assistance for operations teams. AI can explain account events or transaction exceptions in plain language.
• Investment banking systems: Deal pipelines, research workflows, underwriting processes, trade lifecycle functions and risk calculations require strong coordination across front-office, middle-office and back-office platforms. Hyperautomation can standardize approvals, documentation, exception resolution and control evidence across these stages.
• Digital compliance applications: Compliance teams can use AI to summarize policy obligations, compare regulatory changes with internal controls, classify alerts, draft investigation notes and produce evidence packs. Automation ensures routing, approvals, segregation of duties, audit trails and regulatory reporting timelines are consistently enforced.
• Reconciliation platforms: AI can assist in matching narratives, explaining breaks, clustering exception patterns and suggesting resolution actions. Hyperautomation can pull data from ledgers, statements, payment processors, trading systems and data warehouses, then route unresolved breaks to the right teams.
• Reporting and audit applications: Daily, weekly and monthly reports can be generated through controlled data pipelines, automated quality checks, narrative generation, variance explanations and approval workflows. Audit applications can preserve lineage, approvals, source extracts, model outputs and control attestations.

Embedded generative AI as an application capability

Embedding Generative AI into business applications should be treated as an architectural capability, not as a decorative chatbot. A banking application may use AI for search, summarization, reasoning support, content generation, code generation, policy interpretation or anomaly explanation. Each use case requires clear boundaries. The application must know which data the model can access, which actions require approval, what evidence must be captured and where deterministic controls must override probabilistic suggestions.

For example, in trade reporting, an embedded AI assistant can explain why a transaction failed validation and suggest likely fields to review. However, the final correction should pass through rule-based validations, maker-checker approval and audit logging. In wealth management, AI may draft a client review note based on portfolio movements and risk profile, but the advisor must verify suitability, disclosures and final communication. In reconciliation, AI can propose likely matches or categorize break reasons, while the system preserves the original data, confidence score, reviewer action and final resolution path.

Hyperautomating the product development lifecycle

The Product Development Lifecycle can itself become hyperautomated. Instead of treating ideation, analysis, design, development, testing, security review, release and operations as disconnected phases, enterprises can create an AI-assisted delivery loop where every stage produces structured artifacts that the next stage can consume. Platforms such as GitHub Copilot, Claude Code or Claude Cowork-style agentic development environments and OpenAI Codex can support this movement by helping teams reason over requirements, generate code, create tests, review changes, modernize legacy modules and produce documentation. Their value increases when they are connected to repositories, issue trackers, design documents, build pipelines, test suites, security scanners, observability data and enterprise knowledge bases.

PDLC Stage	Hyperautomation Opportunity	AI-Assisted Outcome
Business discovery	Process mining, domain interviews, regulatory mapping, backlog creation	Structured epics, user stories, acceptance criteria, process maps and control requirements
Architecture and design	Reference architectures, API contracts, data models, event flows, security patterns	Architecture options, integration blueprints, threat-model prompts and design decision records
Development	Code generation, service scaffolding, UI component creation, data pipeline templates	Review-ready code increments, reusable components, migration utilities and integration adapters
Testing	Unit, integration, regression, performance, compliance and synthetic data testing	Generated test cases, defect reproduction steps, test automation scripts and coverage summaries
Security and compliance review	Static analysis, dependency checks, policy validation, evidence capture	Risk explanations, remediation suggestions, control traceability and approval evidence
Release and deployment	CI/CD orchestration, environment promotion, release notes, rollback preparation	Automated deployment packs, release summaries, operational checklists and change records
Operations and feedback	Observability, incident analysis, user feedback mining, backlog refinement	Incident summaries, root-cause hypotheses, improvement stories and reliability recommendations

Role of GitHub Copilot, Claude Cowork and Codex

GitHub Copilot is useful where developers need assistance inside the engineering flow: explaining code, generating functions, proposing tests, reviewing pull requests and helping teams move from issue to implementation. In a banking PDLC, it can accelerate microservice creation, API integration, batch processing logic, reconciliation rules, regulatory validation routines and UI workflows. When used with repository context and proper review discipline, it can reduce the time developers spend on repetitive coding while preserving human accountability for design and correctness.

Claude Cowork or Claude Code-style agentic environments are valuable for multi-file reasoning, refactoring, debugging and documentation-heavy engineering work. Banking applications often contain deep domain logic scattered across services, configuration files, stored procedures, integration scripts and test suites. An agentic coding assistant that can understand a wider codebase context can help engineers analyze dependencies, prepare modernization plans, update multiple files coherently and draft explanations for reviewers. This is particularly useful in core banking modernization, trade reporting rule updates and compliance workflow refactoring.

OpenAI Codex can support issue-to-pull-request workflows, test generation, code review, bug reproduction, migration activities and broader software engineering tasks across the lifecycle. In a hyperautomated PDLC, Codex-like agents can be assigned well-scoped work items, asked to inspect failing tests, propose fixes, create regression coverage and summarize the change for human reviewers. The important design principle is to keep agents inside controlled boundaries: clear prompts, repository permissions, test gates, approval workflows and traceable outputs.

Integration architecture for hyperautomated banking applications

A practical architecture begins with business capability decomposition. Each banking domain should be expressed as a set of bounded capabilities such as customer onboarding, account maintenance, trade enrichment, exception management, portfolio review, control attestation, report generation and audit retrieval. These capabilities should be exposed through APIs, events, workflow tasks, data products and user interfaces. Hyperautomation then connects these capabilities using orchestration engines, event streams, rules engines, AI services, RPA connectors where legacy integration is unavoidable and observability layers that capture business and technical telemetry.

The embedded AI layer should sit behind a secure application service boundary. It should use retrieval-augmented generation where approved policies, product rules, application documentation and regulatory mappings are retrieved from trusted sources. It should avoid uncontrolled exposure of sensitive customer information. Prompt templates, response validation, redaction, grounding checks, model monitoring and human-in-the-loop approval should be part of the production design. In banking, the most successful AI pattern is often not full automation but assisted decisioning with strong controls.

Example: Hyperautomated reconciliation and reporting flow

Consider a reconciliation application that compares ledger balances, payment files, trade settlement records and external statements. In a conventional model, operations teams spend significant time downloading files, running macros, investigating mismatches, documenting break reasons and preparing status reports. In a hyperautomated model, data ingestion is scheduled and monitored, schema checks run automatically, matching engines classify obvious matches, AI assists with ambiguous narratives, exceptions are routed through workflow queues and dashboards update in near real time. At the end of the day, the system can generate a draft operations report explaining unresolved breaks, aging trends, risk exposure and pending approvals.

The same pattern can extend to daily, weekly and monthly reporting. Data quality rules validate inputs, report templates are populated automatically, AI generates narrative commentary on variances, reviewers approve or amend explanations and the final report is archived with lineage and approvals. Audit teams can later retrieve not only the report but also the source extracts, transformation logs, exception history, reviewer decisions and AI-generated drafts. This creates a richer control environment than manual reporting because evidence is captured by design rather than reconstructed later.

Governance, risk and control considerations

Hyperautomation in banking must be designed with governance from the beginning. The development team should define which activities can be automated, which can be AI-assisted and which must remain under human approval. Source code generated by AI must pass normal engineering controls, including peer review, static analysis, dependency scanning, secure coding checks, test execution and production readiness review. Business outputs generated by AI, such as compliance narratives or client-facing explanations, should be reviewed where regulatory or reputational risk is material.

Data governance is equally important. AI-enabled applications must respect data classification, residency, retention, masking and access policies. The model should not become an uncontrolled channel through which confidential customer, trading or employee information can leak. Every prompt, retrieved source, generated response, user action and final decision may need to be logged depending on the use case. For audit applications, this traceability is not optional; it is the foundation of trust.

Operating model for AI-native PDLC

A hyperautomated PDLC requires changes in team behavior. Product owners should write requirements in a structured manner so that AI tools can generate better stories, acceptance criteria and test scenarios. Architects should maintain living decision records, reference patterns and integration standards that AI agents can use as context. Developers should learn prompt discipline, context packaging and review techniques. Test engineers should focus on coverage strategy, synthetic data, compliance scenarios and defect prevention rather than only manual execution. Operations teams should feed incident learnings back into the backlog so the system improves continuously.

The role of human experts becomes more important, not less. AI can draft, generate, compare and suggest, but domain judgment remains essential. A trade reporting specialist understands regulatory nuance. A wealth advisor understands client suitability. A core banking architect understands transaction integrity. A compliance officer understands control interpretation. Hyperautomation works best when it amplifies these experts and removes repetitive friction around them.

Conclusion

Hyperautomation in business application development is not simply a faster way to write software. It is a new way to connect business intent, engineering execution, operational control and continuous learning. In banking, where applications must be reliable, explainable, secure and compliant, the combination of embedded Generative AI and disciplined automation can transform how applications are designed, built, integrated, tested, released and operated. Trade reporting, wealth management, core banking, investment banking, compliance, reconciliation, reporting and audit functions can all benefit when AI is embedded responsibly and automation is orchestrated across the complete lifecycle.

Platforms such as GitHub Copilot, Claude Cowork or Claude Code and OpenAI Codex can play an important role in this transformation by accelerating analysis, development, testing, review, modernization and documentation. Their greatest value appears when enterprises treat them not as isolated productivity tools but as part of a governed, AI-native PDLC. The future of banking application development will belong to teams that can combine human expertise, reusable engineering patterns, intelligent automation and strong governance into one coherent delivery model.

This article was made possible by our partnership with the IASA Chief Architect Forum. The CAF’s purpose is to test, challenge and support the art and science of Business Technology Architecture and its evolution over time as well as grow the influence and leadership of chief architects both inside and outside the profession. The CAF is a leadership community of the IASA, the leading non-profit professional association for business technology architects.

As Europe swelters in a heatwave, residents probably don’t want to hear about ways to make their homes even hotter, but that’s what Polish property developer Citylink is talking about, with plans to dump waste heat from a new data center in Wrocław into the municipal district heating network.

Citylink is designing the data center so that heat from servers can be recovered instead of being dissipated via cooling systems — and as the data center grows, any increase in computing power will mean more energy available for recovery.

The collaboration with local power company Kogeneracja will provide “valuable experience in designing and operating modern data centers, with a particular focus on infrastructure dedicated to AI nodes,” said Michał Starybrat, development director at Citylink.

“The dynamic growth of the artificial intelligence and cloud technology markets generates unprecedented demand for computing power, this collaboration demonstrates how modern digital infrastructure can actively contribute to building the energy ecosystem of the future,” he added.

This type of initiative is not new. There have been similar projects in the UK and in New Zealand, but with warnings that data centers are contributing to the warming of the planet, there may well be a lot more organizations looking to deploy that excess heat more fruitfully in the future.

However, announcing it during a heatwave may not be the most politically sensitive approach to take.

Wispr, the startup behind dictation tool Wispr Flow, has created an AI note-taking assistant that records meetings and generates conversation summaries for users.

The Wispr Flow Notetaker tool “captures your meetings so you can stop splitting your attention between listening and writing things down,” said Sahaj Garja, Wispr CTO and co-founder.

Notetaker starts recording with one click, and doesn’t require a bot to attend a video or voice call. It can also be used to capture in-person conversations.

The software has three key functions. Before a call, Notetaker displays a meeting brief with information such as meeting purpose and background of participants.

Once the meeting starts, a live transcript displays the dialogue text and labels speakers. A “what did I miss?” button provides a summary of talking points from the previous few minutes.

Finally, post-meeting, Notetaker generates a more detailed summary organized by topic that includes information such as key dates, decisions, and next steps. Users can search across notes from previous meetings in the Notetaker app. “Over time your meeting history stops being a folder of documents you have to go find and becomes something you can ask questions of,” said Garja.

Notetaker integrates with AI assistants such as Anthropic’s Claude and OpenAI’s ChatGPT via model context protocol. This allows users to connect outputs such as transcripts and summaries “into how you already work, instead of sitting in a separate app,” said Garja.

With Notetaker, Wispr competes in an increasingly busy market for AI note-taking apps that includes Fireflies, Granola and Otter.

Wispr claims Notetaker can produce more accurate transcripts than existing tools, partly because of the additional context it uses during transcription. It uses the same personal dictionary from Wispr Flow that includes acronyms, products, and preferred spellings, and can also draw on other sources such as calendar information to understand the purpose of a meeting and help ensure speakers are labelled correctly.

Before generating the final summary, Notetaker also re-reads the live meeting transcript and combines it with additional context to create a more accurate final output, Garja said.

Notetaker is the first new product launched by Wispr, which was founded in 2021 and has since raised $81 million in funding.

“We didn’t set out to build a dictation app,” said Garja. “The mission has always been to reshape how people interact with their devices, and dictation was the fastest way in.”

“Notetaker is the second product on that path. Dictation took the keyboard out of writing. Notetaker takes it out of meetings, so nobody has to spend the call typing up what everyone just said.”

User consent when recording calls

As AI note-taking tools have become more prevalent in the workplace, privacy concerns have arisen, including the need for all-party consent when recording a call in some jurisdictions, and whether meeting audio is used to train AI models. Two software vendors, Otter and Granola, currently face separate lawsuits in California that allege privacy law violations related to their products.

Wispr Flow Notetaker captures audio locally on a user’s device rather than joining the call as a visible bot. That means there’s no notification to signal that a conversation is being transcribed, which places responsibility on users to disclose the recording to others on the call in accordance with local laws, said Garja.

“Users should always let the other person know before you start recording or transcribing a conversation, whether it’s a video call, an in-person meeting, or a phone call,” he said, adding that Wispr intends to build additional features for automated consent messaging “in the coming weeks.”

Wispr doesn’t train its AI models on customer data without consent, though free and standard tier customers must choose to opt-out, according to Wispr’s privacy terms. Nor does it create “voiceprints or biometric profiles” of users or anyone else on a call using audio recording data, the company says.

When Notetaker is active, conversation audio is captured on a user’s device and processed on cloud servers to enable transcription. The recorded audio file is encrypted and stored temporarily on the user’s device or cloud storage, Wispr said. After a limited period, the audio is automatically deleted.

Notetaker is available with the Wispr Flow macOS app to free and paid subscribers, with support for Windows “coming soon.”

There’s something very attractive about saying “we embed very closely with our customers and just figure it out with them”, especially since the company that started “forward deploying engineers” is growing 84% with $5B+ revenue. But “forward deployed engineer” is a vague term and means different things depending on the business you’re running.

I spent almost 5 years at Palantir as a forward-deployed software engineer, and Palantir’s version of an “FDE” does not make sense for most companies I now meet as an early-stage VC. Depending on the type of business you’re building, this role could broadly mean one of two things: “the product builder” or “the platform operator.” Clearly defining which bucket you fall into will make it easier to hire for this role and run your FDE org.

The product builder: The OG Palantir version

The north star is: do whatever it takes to actually solve the user’s problem. FDEs are not just responsible for making the platform work, but also discovering what to build and building it (actually creating software) in service of the customer.

The platform operator: Solutions + technical customer success

The north star is: make the product work for the customer – deploy and operationalize it. This is what most startups today really mean when they want FDEs. FDEs here configure the core platform, manage account relationships and drive adoption. This is not new – companies have always had solutions engineers, sales engineers, customer success etc., although the work looks different as FDEs are increasingly building prototypes, configuring evals and building MCPs.

Which FDE is right for you

For most situations, hiring product builder FDEs is a mistake.

At scale, the FDEs should be the platform operator. It’s hard to have FDEs build and maintain highly custom product features, especially as the company scales. Over time, the custom product surface area distracts from building the core product, even though AI coding tools make it easy to ship new features quickly and maintain them.

Many fast-growing AI startups recognize these constraints and structure the FDE role more like the platform operator. This also allows them to have 5-10 accounts per FDE, which is a much higher ratio than Palantir had (at least in 2023). Even the Palantir FDE role has evolved to look more like the platform operator.

There are, however, situations when your FDEs should be the product builder archetype.

1. You have very large customers (F500 scale)

Technical complexity: Large customers have complex environments with legacy infrastructure that often requires “out-of-platform” engineering work. I often encountered bespoke data infrastructure, privacy requirements, etc. at various Palantir customers that required me to build “out-of-platform” connectors, UIs and backends.

Organizational inertia and trust: Serving large enterprises is about building trust. In short time periods, overfitting product to a specific user/workflow is often what delivers the most value, builds trust and helps organizations get over the inertia of moving away from Excel and legacy software tools that are part of their day-to-day workflow. For AI-native startups, it’s arguably even more important to invest in doing “unscalable” development with engineering boots on the ground, as it helps solidify your right to exist and eventually expand the customer relationship.

2. You have many ICPs and workflows

If you have a broad range of ICPs and workflows that you serve, your product probably is not walk-up usable on day 1 of deployment. The short-term hacky things that product builder FDEs build to make the product work for these heterogeneous users/workflows will help you shape the product long-term.

Note: see Palantir Foundry’s architecture here.

This was a big reason why Palantir FDEs were more like product builders (and are still able to – see the Forward Deployed Software Engineer job profiles as an example). The vision for Foundry was to be the operating system for an enterprise’s critical decisions – inherently multiple industries, users and workflows. A lot of FDE-led development showed that solving many of these use cases required complex data integrations, which led to the early versions of Foundry being best-suited for complex data integrations and building a customer’s “Ontology”. Similarly, FDEs like myself built custom frontend applications for fraud analysis, pricing, etc. As certain patterns of what these applications required became more clear, they were centralized into an application-layer product.

Who you should hire

Platform operator: There is a much broader set of people you could hire, testing for technical fluency (e.g., being good at data analysis, complex Excel work, even SQL), product intuition and an inclination to build customer relationships. Backgrounds like technical customer success, solutions engineering, software engineering, product management and consulting are all strong fits.

Product builder: You want candidates that are high ownership and missionary software engineers, or technical PMs who want to ship products themselves.

Hiring for these profiles, especially product builders, is hard. It’s worth calling out two things that helped Palantir hire software engineers into what might be considered a less sexy role.

1. Culture of building at the edge: Strong engineers are motivated to build things. Palantir gave FDEs a lot of ownership to build products, which is why much of the core product leadership was former FDEs.
2. Cult built around mission: Internally, there was a cult-like devotion to the mission. Everyone always talked about why outcomes were far more important than software, and why most companies building tools had it wrong. I’ve never been at a company where people feel so closely bonded around a mission.

As founders building AI startups think about hiring FDEs, it’s worth being specific about your culture and asking: Am I just hiring people to support development teams, or am I hiring people to shape and build product? It’s hard to get software engineers (even today) to be excited about an FDE role that might just be technical customer success.

What FDEs should be doing (regardless of archetype)

You’ve hired the right people. How do you best leverage your team of FDEs?

FDEs were Palantir’s way of delivering outcomes rather than tools. AI-native startups can take this much further and FDEs can help in a few unique ways by leveraging their proximity to customers.

1. Find the most critical workflows: As AI lowers the cost of producing software, companies will face a lot more competition. FDEs at AI startups should be constantly finding ways to serve the most critical workflows for a customer and paying attention to how customers do work across newer and legacy tools. For example, FDEs at Harvey should pay attention to which workflows are in Westlaw, which ones are moving to ChatGPT/Claude, and how the Harvey product can stay ahead.
2. Build around nondeterminism: In more regulated environments, FDEs should be hyper-focused on making products reliable for specific use cases using evals and configs. Previously, product reliability lived with product and support. As companies provide outcomes instead of tools, configuring products appropriately and managing evals shifts towards FDE teams.

Business application development is entering a new operating model. The traditional approach of gathering requirements, designing screens, writing services, integrating systems, testing, fixing defects and preparing release documentation still exists, but it is no longer sufficient for enterprises that need speed, traceability, resilience and regulatory confidence at the same time. Hyperautomation brings a broader discipline to this challenge. It combines workflow orchestration, intelligent document processing, robotic automation, API-led integration, process mining, test automation, observability and artificial intelligence into a connected delivery fabric. With embedded Generative AI, this fabric becomes more adaptive because applications can interpret natural language, summarize complex data, generate explanations, detect exceptions and support decision workflows rather than merely execute predefined rules.

In banking, this shift is especially meaningful. Banks operate across dense application landscapes: trade reporting platforms, wealth management portals, core banking systems, investment banking applications, digital compliance engines, reconciliation utilities, operational dashboards, audit repositories and daily, weekly and monthly reporting platforms. Each of these areas has its own data models, control points, integration patterns, validation rules, exception paths and regulatory obligations. Hyperautomation does not replace engineering discipline; it strengthens it by making business intent, technical execution, control evidence and continuous improvement part of the same lifecycle.

From automation to hyperautomation in banking applications

Automation usually addresses a specific task: moving data from one system to another, generating a report, running a batch job or validating a transaction against a rule. Hyperautomation goes further. It looks at the complete business outcome and asks how the entire chain can be streamlined, governed, observed and improved. For example, a trade reporting process may begin with transaction capture, enrich the trade with reference data, validate regulatory fields, identify breaks, generate a submission file, transmit it to a regulator or trade repository, monitor acknowledgements and preserve audit evidence. A narrow automation script may accelerate one step, but a hyperautomated design coordinates the complete flow, including exception handling and evidence generation.

Figure: Automation vs. hyperautomation

Embedded Generative AI adds a new layer of intelligence. Instead of forcing every user interaction into rigid screens and codes, business applications can accept natural language prompts, interpret document content, summarize cases, generate draft responses, explain anomalies, produce test scenarios and create release notes. In a banking environment, this intelligence must be carefully bounded. Every AI-assisted action should be traceable, explainable, reviewable and aligned with data privacy, model risk, information security and regulatory expectations. The goal is not uncontrolled autonomy; the goal is governed acceleration.

Banking application components suitable for hyperautomation

A modern banking application is rarely a single monolithic system. It is a composition of business capabilities, integration services, workflow engines, data pipelines, user experience layers, analytics models, control dashboards and audit stores. Hyperautomation can accelerate the development and integration of these components by turning repetitive engineering work into reusable patterns and by embedding intelligence directly into business processes.

• Trade reporting applications: Generative AI can help map trade attributes to regulatory fields, explain validation failures, summarize rejected submissions and generate test cases for reporting scenarios. Hyperautomation can orchestrate enrichment, validation, submission, acknowledgement tracking and evidence archival.
• Wealth management platforms: Advisors can use embedded AI to summarize client portfolios, generate suitability narratives, identify missing documents and prepare personalized investment review notes. Automation can coordinate onboarding, risk profiling, document verification, portfolio rebalancing workflows and client communication approvals.
• Core banking applications: Account opening, loan servicing, deposits, payments, interest calculations and customer maintenance can benefit from automated validations, intelligent forms, workflow routing and natural language assistance for operations teams. AI can explain account events or transaction exceptions in plain language.
• Investment banking systems: Deal pipelines, research workflows, underwriting processes, trade lifecycle functions and risk calculations require strong coordination across front-office, middle-office and back-office platforms. Hyperautomation can standardize approvals, documentation, exception resolution and control evidence across these stages.
• Digital compliance applications: Compliance teams can use AI to summarize policy obligations, compare regulatory changes with internal controls, classify alerts, draft investigation notes and produce evidence packs. Automation ensures routing, approvals, segregation of duties, audit trails and regulatory reporting timelines are consistently enforced.
• Reconciliation platforms: AI can assist in matching narratives, explaining breaks, clustering exception patterns and suggesting resolution actions. Hyperautomation can pull data from ledgers, statements, payment processors, trading systems and data warehouses, then route unresolved breaks to the right teams.
• Reporting and audit applications: Daily, weekly and monthly reports can be generated through controlled data pipelines, automated quality checks, narrative generation, variance explanations and approval workflows. Audit applications can preserve lineage, approvals, source extracts, model outputs and control attestations.

Embedded generative AI as an application capability

Embedding Generative AI into business applications should be treated as an architectural capability, not as a decorative chatbot. A banking application may use AI for search, summarization, reasoning support, content generation, code generation, policy interpretation or anomaly explanation. Each use case requires clear boundaries. The application must know which data the model can access, which actions require approval, what evidence must be captured and where deterministic controls must override probabilistic suggestions.

For example, in trade reporting, an embedded AI assistant can explain why a transaction failed validation and suggest likely fields to review. However, the final correction should pass through rule-based validations, maker-checker approval and audit logging. In wealth management, AI may draft a client review note based on portfolio movements and risk profile, but the advisor must verify suitability, disclosures and final communication. In reconciliation, AI can propose likely matches or categorize break reasons, while the system preserves the original data, confidence score, reviewer action and final resolution path.

Hyperautomating the product development lifecycle

The Product Development Lifecycle can itself become hyperautomated. Instead of treating ideation, analysis, design, development, testing, security review, release and operations as disconnected phases, enterprises can create an AI-assisted delivery loop where every stage produces structured artifacts that the next stage can consume. Platforms such as GitHub Copilot, Claude Code or Claude Cowork-style agentic development environments and OpenAI Codex can support this movement by helping teams reason over requirements, generate code, create tests, review changes, modernize legacy modules and produce documentation. Their value increases when they are connected to repositories, issue trackers, design documents, build pipelines, test suites, security scanners, observability data and enterprise knowledge bases.

PDLC Stage	Hyperautomation Opportunity	AI-Assisted Outcome
Business discovery	Process mining, domain interviews, regulatory mapping, backlog creation	Structured epics, user stories, acceptance criteria, process maps and control requirements
Architecture and design	Reference architectures, API contracts, data models, event flows, security patterns	Architecture options, integration blueprints, threat-model prompts and design decision records
Development	Code generation, service scaffolding, UI component creation, data pipeline templates	Review-ready code increments, reusable components, migration utilities and integration adapters
Testing	Unit, integration, regression, performance, compliance and synthetic data testing	Generated test cases, defect reproduction steps, test automation scripts and coverage summaries
Security and compliance review	Static analysis, dependency checks, policy validation, evidence capture	Risk explanations, remediation suggestions, control traceability and approval evidence
Release and deployment	CI/CD orchestration, environment promotion, release notes, rollback preparation	Automated deployment packs, release summaries, operational checklists and change records
Operations and feedback	Observability, incident analysis, user feedback mining, backlog refinement	Incident summaries, root-cause hypotheses, improvement stories and reliability recommendations

Role of GitHub Copilot, Claude Cowork and Codex

GitHub Copilot is useful where developers need assistance inside the engineering flow: explaining code, generating functions, proposing tests, reviewing pull requests and helping teams move from issue to implementation. In a banking PDLC, it can accelerate microservice creation, API integration, batch processing logic, reconciliation rules, regulatory validation routines and UI workflows. When used with repository context and proper review discipline, it can reduce the time developers spend on repetitive coding while preserving human accountability for design and correctness.

Claude Cowork or Claude Code-style agentic environments are valuable for multi-file reasoning, refactoring, debugging and documentation-heavy engineering work. Banking applications often contain deep domain logic scattered across services, configuration files, stored procedures, integration scripts and test suites. An agentic coding assistant that can understand a wider codebase context can help engineers analyze dependencies, prepare modernization plans, update multiple files coherently and draft explanations for reviewers. This is particularly useful in core banking modernization, trade reporting rule updates and compliance workflow refactoring.

OpenAI Codex can support issue-to-pull-request workflows, test generation, code review, bug reproduction, migration activities and broader software engineering tasks across the lifecycle. In a hyperautomated PDLC, Codex-like agents can be assigned well-scoped work items, asked to inspect failing tests, propose fixes, create regression coverage and summarize the change for human reviewers. The important design principle is to keep agents inside controlled boundaries: clear prompts, repository permissions, test gates, approval workflows and traceable outputs.

Integration architecture for hyperautomated banking applications

A practical architecture begins with business capability decomposition. Each banking domain should be expressed as a set of bounded capabilities such as customer onboarding, account maintenance, trade enrichment, exception management, portfolio review, control attestation, report generation and audit retrieval. These capabilities should be exposed through APIs, events, workflow tasks, data products and user interfaces. Hyperautomation then connects these capabilities using orchestration engines, event streams, rules engines, AI services, RPA connectors where legacy integration is unavoidable and observability layers that capture business and technical telemetry.

The embedded AI layer should sit behind a secure application service boundary. It should use retrieval-augmented generation where approved policies, product rules, application documentation and regulatory mappings are retrieved from trusted sources. It should avoid uncontrolled exposure of sensitive customer information. Prompt templates, response validation, redaction, grounding checks, model monitoring and human-in-the-loop approval should be part of the production design. In banking, the most successful AI pattern is often not full automation but assisted decisioning with strong controls.

Example: Hyperautomated reconciliation and reporting flow

Consider a reconciliation application that compares ledger balances, payment files, trade settlement records and external statements. In a conventional model, operations teams spend significant time downloading files, running macros, investigating mismatches, documenting break reasons and preparing status reports. In a hyperautomated model, data ingestion is scheduled and monitored, schema checks run automatically, matching engines classify obvious matches, AI assists with ambiguous narratives, exceptions are routed through workflow queues and dashboards update in near real time. At the end of the day, the system can generate a draft operations report explaining unresolved breaks, aging trends, risk exposure and pending approvals.

The same pattern can extend to daily, weekly and monthly reporting. Data quality rules validate inputs, report templates are populated automatically, AI generates narrative commentary on variances, reviewers approve or amend explanations and the final report is archived with lineage and approvals. Audit teams can later retrieve not only the report but also the source extracts, transformation logs, exception history, reviewer decisions and AI-generated drafts. This creates a richer control environment than manual reporting because evidence is captured by design rather than reconstructed later.

Governance, risk and control considerations

Hyperautomation in banking must be designed with governance from the beginning. The development team should define which activities can be automated, which can be AI-assisted and which must remain under human approval. Source code generated by AI must pass normal engineering controls, including peer review, static analysis, dependency scanning, secure coding checks, test execution and production readiness review. Business outputs generated by AI, such as compliance narratives or client-facing explanations, should be reviewed where regulatory or reputational risk is material.

Data governance is equally important. AI-enabled applications must respect data classification, residency, retention, masking and access policies. The model should not become an uncontrolled channel through which confidential customer, trading or employee information can leak. Every prompt, retrieved source, generated response, user action and final decision may need to be logged depending on the use case. For audit applications, this traceability is not optional; it is the foundation of trust.

Operating model for AI-native PDLC

A hyperautomated PDLC requires changes in team behavior. Product owners should write requirements in a structured manner so that AI tools can generate better stories, acceptance criteria and test scenarios. Architects should maintain living decision records, reference patterns and integration standards that AI agents can use as context. Developers should learn prompt discipline, context packaging and review techniques. Test engineers should focus on coverage strategy, synthetic data, compliance scenarios and defect prevention rather than only manual execution. Operations teams should feed incident learnings back into the backlog so the system improves continuously.

The role of human experts becomes more important, not less. AI can draft, generate, compare and suggest, but domain judgment remains essential. A trade reporting specialist understands regulatory nuance. A wealth advisor understands client suitability. A core banking architect understands transaction integrity. A compliance officer understands control interpretation. Hyperautomation works best when it amplifies these experts and removes repetitive friction around them.

Conclusion

Hyperautomation in business application development is not simply a faster way to write software. It is a new way to connect business intent, engineering execution, operational control and continuous learning. In banking, where applications must be reliable, explainable, secure and compliant, the combination of embedded Generative AI and disciplined automation can transform how applications are designed, built, integrated, tested, released and operated. Trade reporting, wealth management, core banking, investment banking, compliance, reconciliation, reporting and audit functions can all benefit when AI is embedded responsibly and automation is orchestrated across the complete lifecycle.

Platforms such as GitHub Copilot, Claude Cowork or Claude Code and OpenAI Codex can play an important role in this transformation by accelerating analysis, development, testing, review, modernization and documentation. Their greatest value appears when enterprises treat them not as isolated productivity tools but as part of a governed, AI-native PDLC. The future of banking application development will belong to teams that can combine human expertise, reusable engineering patterns, intelligent automation and strong governance into one coherent delivery model.

This article was made possible by our partnership with the IASA Chief Architect Forum. The CAF’s purpose is to test, challenge and support the art and science of Business Technology Architecture and its evolution over time as well as grow the influence and leadership of chief architects both inside and outside the profession. The CAF is a leadership community of the IASA, the leading non-profit professional association for business technology architects.

For years, applicant tracking systems and recruiting platforms were treated as HR technology: Important for workflow, efficiency, compliance and candidate experience, but rarely viewed as core security infrastructure. That assumption no longer holds. Once AI begins reading resumes, scoring candidates, conducting interviews, ranking applicants and influencing who moves forward, the hiring platform stops being a passive system of record. It becomes a decision system.

And any system that accepts public input, processes sensitive data and influences business decisions belongs inside the security conversation.

I learned this during an AI hiring platform rollout that never made it to production. The vendor was established, the product had a strong market reputation and the AI feature looked attractive: Upload a resume, compare it to a job description and return a neat percentage match. For recruiters, it promised speed. For executives, it promised modernization.

Before moving real candidate data into the system, I tested it with synthetic resumes. One weak resume came back with a surprisingly strong match. The reason was not hidden in the candidate’s experience. It was hidden in the text. The resume contained language instructing the AI to treat the candidate as an excellent fit, and the system appeared to follow that instruction instead of evaluating the resume on merit.

That changed the question from “Does the tool improve productivity?” to “Can the person being evaluated influence the evaluation itself?”

That is a security question.

The trust boundary has moved

CIOs do not need to become recruiting experts. They only need to look at the mechanics.

An anonymous user submits content into an enterprise system. That content is processed by software. The software then produces an output that can influence a business decision. In every other environment, security teams know what to call that: untrusted input crossing a trust boundary.

The difference is that in hiring, the input looks harmless. It is a resume, a cover letter, a chatbot reply or a spoken answer in an AI-led interview. But once AI reads that content and treats it as instruction, the harmless-looking input becomes part of the system’s control surface.

That is why prompt injection matters in hiring. It is not just an AI oddity or a model behavior issue. It is the same category of failure enterprises have spent decades trying to prevent: User-controlled input changing what the system does. OWASP lists prompt injection as the first risk in its Top 10 for LLM applications, describing it as a case where user prompts alter a model’s behavior or output in unintended ways.

In hiring, the implication is direct: A candidate may be able to manipulate the score, ranking or interview assessment that determines whether a human ever sees them.

The business impact is not theoretical

The obvious risk is that an unqualified candidate moves forward. But the impact is broader.

First, decision quality degrades. Hiring teams adopt AI scoring because they believe it improves signal. If the score can be manipulated, the business is not gaining signal; it is gaining false confidence. Recruiters may spend time on candidates who gamed the system while stronger candidates are buried lower in the queue. A tool bought to reduce friction can quietly create more of it.

Second, cost increases under the appearance of efficiency. Every false positive consumes recruiter time, hiring-manager attention, interview slots and opportunity cost. A small weakness in screening integrity can become a measurable operational drag across open roles.

Third, trust suffers. Candidates already question whether AI hiring tools are fair, explainable or accurate. If it becomes clear that a screening system can be manipulated by hidden instructions or verbal prompting, the issue is no longer just security. It becomes reputational. Strong candidates may lose confidence in the process, and employers may have to defend decisions made by systems they did not fully understand.

Fourth, sensitive data exposure becomes harder to contain. Recruiting systems hold names, addresses, work histories, education histories, compensation details, work authorization information and sometimes accommodation or demographic data. NIST guidance on personally identifiable information includes employment information as linkable personal data that must be protected from inappropriate access, use and disclosure. Yet hiring platforms often receive less security scrutiny than systems holding customer or financial data.

That mismatch is dangerous: High-value data, public-facing workflows and increasing automation.

The 2025 McHire incident should have made this impossible to ignore. Researchers reported that weaknesses in McDonald’s AI hiring platform, including default credentials and an access-control flaw, exposed applicant data at large scale before the issue was patched. The lesson for CIOs is not merely that a weak password was used. The lesson is that AI hiring systems can ship with basic, preventable security failures while still being treated as HR tools rather than enterprise risk surfaces.

Vendor reputation does not transfer to every AI feature

One reason this risk slips through is that buyers often trust the platform brand. Mature vendors may have strong security programs, enterprise customers, compliance documentation and procurement-friendly answers.

But AI features can change the architecture of risk.

A platform that was safe as a workflow tool may behave very differently once it adds resume scoring, interview grading, chatbot screening or automated ranking. The new feature may introduce new inputs, new model behavior, new data flows, new third-party dependencies and new decision points. In practical terms, the attack surface has changed.

CIOs should not allow AI features to inherit trust automatically from the legacy platform around them. When a vendor adds AI, the enterprise should reassess the feature as if it were a new product. That does not mean slowing innovation for bureaucracy. It means AI-enabled decision-making carries different failure modes from ordinary workflow automation.

The ownership gap is the real vulnerability

The biggest risk may not be the model. It may be the ownership gap.

Talent acquisition may buy the tool. HR operations may configure it. The vendor may guide implementation. Procurement and legal may approve the contract. But who owns the security of the candidate-facing AI layer?

In many organizations, the honest answer is unclear.

That ambiguity is where risk grows. Recruiting technology sits at the intersection of public input, sensitive data, third-party software, automated decision support and brand trust. That is exactly the kind of environment that needs named security ownership, asset inventory, vendor review, access-control testing, logging and incident-response planning.

If the hiring stack is not in the security inventory, the organization is already making an assumption it may later regret.

What CIOs should require now

The fix is not exotic. It is applying existing security discipline to a surface that has been underestimated.

Treat every candidate submission as untrusted input. Resumes, cover letters, chatbot responses, interview transcripts and spoken answers should be handled as attacker-controllable content. If AI processes it, the system must separate content from instruction.

Reassess vendors when AI features are introduced. A prior security review should not be treated as permanent approval for new AI capabilities. Ask what changed in the architecture, what data the model sees, what actions it can influence and how manipulation attempts are detected.

Ask AI-specific questions before signing. Can candidate-provided content alter scoring? Are hidden instructions filtered or ignored? Is there human review before AI output influences a decision? Can the vendor produce testing evidence for prompt injection, access control and data exposure risks?

Assign ownership. HR can own the process, but security must own the risk model. AI hiring systems should be included in third-party risk management, application security reviews, access governance, monitoring and incident response planning.

Measure business impact, not just AI adoption. The goal is not to say the recruiting function uses AI. The goal is to improve hiring speed, quality, fairness and cost without creating new risk. If the system cannot protect decision integrity, the business case is weaker than it appears.

The hiring platform is now part of the enterprise attack surface

AI has turned the careers page into more than a front door for applicants. It is now a public input channel feeding systems that store sensitive data and influence workforce decisions.

That makes it a CIO concern.

The next failure in AI hiring may not look like a traditional breach at first. It may look like bad rankings, manipulated scores, unexplainable decisions, wasted recruiter time or a candidate process no one trusts. But underneath those symptoms is a familiar security problem: A system trusted input it should have treated as hostile.

Enterprises have hardened payment systems, customer portals, APIs and employee applications around that lesson. Hiring deserves the same treatment.

AI hiring is not just an HR transformation. It is a security boundary. And it is time CIOs treated it like one.

As Europe swelters in a heatwave, residents probably don’t want to hear about ways to make their homes even hotter, but that’s what Polish property developer Citylink is talking about, with plans to dump waste heat from a new data center in Wrocław into the municipal district heating network.

Citylink is designing the data center so that heat from servers can be recovered instead of being dissipated via cooling systems — and as the data center grows, any increase in computing power will mean more energy available for recovery.

The collaboration with local power company Kogeneracja will provide “valuable experience in designing and operating modern data centers, with a particular focus on infrastructure dedicated to AI nodes,” said Michał Starybrat, development director at Citylink.

“The dynamic growth of the artificial intelligence and cloud technology markets generates unprecedented demand for computing power, this collaboration demonstrates how modern digital infrastructure can actively contribute to building the energy ecosystem of the future,” he added.

This type of initiative is not new. There have been similar projects in the UK and in New Zealand, but with warnings that data centers are contributing to the warming of the planet, there may well be a lot more organizations looking to deploy that excess heat more fruitfully in the future.

However, announcing it during a heatwave may not be the most politically sensitive approach to take.

This article first appeared on Network World.

Bending Spoons has snapped up Airtable to add to its portfolio of software companies, alongside AOL, Evernote, WeTransfer, Brightcove and Vimeo

Airtable made its name as a builder of low/no code database services, aimed particularly at non-technical staff, but is now one of many vendors facing financial difficulties in the face of the SaaS/AIpocalypse. The arrival of AI coding tools, which offer non-technical employees more flexible ways to build business applications, has hit demand for its services.

Bending Spoons bought Airtable in a deal it valued at just $1.285 billion, a far cry from the $11.7 billion Airtable was worth at its peak.

Bending Spoons has built its portfolio by buying once-successful companies like Airtable that have struggled to cope with newer, nimbler competitors or failed to adapt to emerging technologies. Bending Spoons takes these companies, cuts costs and markets them aggressively with the goal of returning them to profitability.

“Airtable is a pioneering brand reshaping how teams organize data and manage critical workflows. We’re committed to investing in Airtable for the long run, and doubling down on its core strength: bringing teams and workflows together in one flexible workspace. We plan to expand what can be done across the full spectrum of work and make Airtable even more valuable to customers at every scale,” said Luca Ferrari, Bending Spoons CEO and co-founder.

This article first appeared on InfoWorld.

Technology leaders are facing a sobering reality: They’re investing heavily in AI, yet many initiatives continue to struggle to move beyond experimentation and pilot programs. For example, Gartner found only 28% of AI use cases in infrastructure and operations fully succeed and meet ROI expectations, while 20% fail outright.

The conversation around AI often focuses on models, tools and technical capabilities. Those decisions matter, but in my experience, they are rarely the only factors that determine success. The organizations realizing meaningful value from AI are also focused on operational readiness, governance, employee adoption and measurable outcomes.

As both CIO and CDO, I spend a lot of time helping our organization navigate AI adoption while balancing the needs of our internal teams, our clients and running 24×7 secure operations. What I have learned is that AI transformation depends on how well the organization understands its data, improves its business processes and prepares people to work differently.

I sometimes describe my role as being the organization’s traffic light. The green lights are easy – these are moments when the right answer is to accelerate. There are also moments when we need to slow down. As leaders, we must assess when we need to focus on the fundamentals and make sure the organization is ready for what comes next. And the most important decisions are the red lights – when we prevent the organization from spending time, money and energy on the wrong things.

AI adoption breaks down when it does not fit how people work

One common misconception about AI transformation is that deployment automatically creates adoption. In practice, adoption happens when employees understand how the technology improves their work and have confidence in how it fits into their day-to-day responsibilities.

I have seen AI pilots work well with small groups of users and then encounter challenges when expanded across larger teams. The technology may perform as expected, but the operating environment changes. Teams follow different workflows. Information is managed differently across functions. Employees have different levels of trust in the data. Success is not always measured the same way.

These are readiness, process and change management issues.

We saw similar lessons during our own transformation work. As part of a broader modernization program, we consolidated more than 50 engineering tools into one software delivery platform supporting thousands of developers. The technical migration mattered, but the bigger effort was helping teams adopt new ways of working and establish common practices.

Anyone who has asked developers to move away from their favorite tools knows that change management is real. That experience reinforced a lesson: Transformation succeeds when people understand the value of the change, have the right support and can see how it improves the work they do every day.

The same principle applies to AI.

When we began introducing AI capabilities internally, we avoided a broad rollout from day one. Rolling AI out to thousands of employees is a process of education, adoption support and continuous learning. We introduced capabilities in phases, helped employees understand use cases relevant to their role and gave teams room to build confidence over time. Different teams adopt AI differently, so we found that cohort-based deployment and tailored change management created better long-term adoption than broad enterprise-wide rollouts.

Pilots often succeed because the variables are limited. Production environments introduce the realities of the enterprise: inconsistent processes, disconnected data, unclear ownership and varying levels of employee readiness. In many cases, issues that surface during scaling can be traced back to operating model decisions, process gaps or unclear expectations.

Employees need to understand where AI fits, when human judgment remains essential and how success will be measured. Without that clarity, scaling becomes much harder.

Creating the operational conditions for AI success

The most successful AI transformations start before AI is introduced.

They begin with understanding where employees experience friction. In most enterprises, those opportunities are not difficult to find. Repetitive administrative work and manual handoffs consume time and slow the business down. Employees directly in the workflows have the clearest view of where these issues exist.

When we launched our own efficiency and transformation program, we deliberately did not start with AI. We started by evaluating our data, reviewing business processes and identifying opportunities to simplify how work was performed. We found that simplifying and standardizing workflows before introducing AI significantly reduced complexity during deployment. Rather than asking AI to compensate for fragmented processes, we focused first on creating a consistent operational foundation. We focused first on process improvement, automation and operational discipline. Once those foundations were in place, we began layering AI into the environment.

AI outcomes are heavily influenced by the quality of the processes and the data along with the governance structures supporting them. If the underlying process is inconsistent, AI will struggle to create consistent value. If the process is understood, governed and measurable, AI has a much stronger foundation.

I often say that good data and good processes deliver good AI outcomes. That continues to hold true regardless of the model or technology being deployed.

The real challenge is making sure employees know what AI is using, where it fits in the workflow and when they should rely on the output. If that is unclear, adoption slows. People may not trust the answer, may use the tool inconsistently or may avoid changing how work gets done.

Before scaling AI, leaders need to answer a few basic questions. What problem are we solving? Is the process consistent enough? Is the data reliable enough? Where does human judgment still matter? And how will we know whether the tool is improving the work? Those questions determine whether AI becomes part of how teams operate.

Measure outcomes before you scale

AI programs often lose momentum when leaders measure activity instead of impact. 63% of high-maturity organizations implement formal metrics to evaluate transformation efforts.

Leaders often track how many employees have access to AI, how many licenses have been provisioned or how many use cases have been launched. Those metrics can be useful, but they do not always show whether the organization is creating business value. Activity is not the same as impact.

The more meaningful indicators are instead tied to operational performance: support ticket volumes, incident reduction, productivity improvements, user experience, cycle times and service quality.

We have seen the value of this approach firsthand. As part of our transformation program, we standardized service delivery processes and moved hundreds of teams onto a common service management platform. In our own experience, process improvements and platform consolidation initially reduced support ticket volumes by approximately 30%.

After that foundation was established, additional automation and AI capabilities helped drive reductions closer to 70%.

The initial improvement came from better processes and greater operational consistency. Automation and AI then helped accelerate the results. That is the pattern leaders should look for: Identify where work slows down, improve the process, establish accountability and introduce AI where the environment is ready to support it.

This approach also helps build trust. Employees can see the value being created. Leaders can measure progress. Teams can learn from early deployments before scaling more broadly.

Preparing people is the real AI strategy

Technology adoption has always been closely connected to people.

Employees are more likely to embrace change when they understand how technology helps them be more effective. They need practical experience, clear expectations and opportunities to learn. AI introduces new ways of working, and organizations need to prepare employees for that shift.

In our own organization, we encouraged every employee to establish an AI-related learning goal because familiarity with emerging technologies is becoming part of every role. Some goals were simple. Some were more advanced. The important point was creating a culture where people continue to learn and understand how AI applies to their work versus forcing AI activity broadly all at once.

As AI becomes more embedded in enterprise operations, organizations with strong foundations in governance, process discipline and workforce readiness will be better positioned to capture long-term value.

The companies realizing the greatest value from AI are investing in technology while also strengthening the operating models, information management practices and employee capabilities that support adoption. Sustainable transformation requires attention to people, processes, data and technology.

Preparing people, building trust and creating clear operating models remain central to any successful AI strategy.

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

Technology leaders are facing a sobering reality: They’re investing heavily in AI, yet many initiatives continue to struggle to move beyond experimentation and pilot programs. For example, Gartner found only 28% of AI use cases in infrastructure and operations fully succeed and meet ROI expectations, while 20% fail outright.

The conversation around AI often focuses on models, tools and technical capabilities. Those decisions matter, but in my experience, they are rarely the only factors that determine success. The organizations realizing meaningful value from AI are also focused on operational readiness, governance, employee adoption and measurable outcomes.

As both CIO and CDO, I spend a lot of time helping our organization navigate AI adoption while balancing the needs of our internal teams, our clients and running 24×7 secure operations. What I have learned is that AI transformation depends on how well the organization understands its data, improves its business processes and prepares people to work differently.

I sometimes describe my role as being the organization’s traffic light. The green lights are easy – these are moments when the right answer is to accelerate. There are also moments when we need to slow down. As leaders, we must assess when we need to focus on the fundamentals and make sure the organization is ready for what comes next. And the most important decisions are the red lights – when we prevent the organization from spending time, money and energy on the wrong things.

AI adoption breaks down when it does not fit how people work

One common misconception about AI transformation is that deployment automatically creates adoption. In practice, adoption happens when employees understand how the technology improves their work and have confidence in how it fits into their day-to-day responsibilities.

I have seen AI pilots work well with small groups of users and then encounter challenges when expanded across larger teams. The technology may perform as expected, but the operating environment changes. Teams follow different workflows. Information is managed differently across functions. Employees have different levels of trust in the data. Success is not always measured the same way.

These are readiness, process and change management issues.

We saw similar lessons during our own transformation work. As part of a broader modernization program, we consolidated more than 50 engineering tools into one software delivery platform supporting thousands of developers. The technical migration mattered, but the bigger effort was helping teams adopt new ways of working and establish common practices.

Anyone who has asked developers to move away from their favorite tools knows that change management is real. That experience reinforced a lesson: Transformation succeeds when people understand the value of the change, have the right support and can see how it improves the work they do every day.

The same principle applies to AI.

When we began introducing AI capabilities internally, we avoided a broad rollout from day one. Rolling AI out to thousands of employees is a process of education, adoption support and continuous learning. We introduced capabilities in phases, helped employees understand use cases relevant to their role and gave teams room to build confidence over time. Different teams adopt AI differently, so we found that cohort-based deployment and tailored change management created better long-term adoption than broad enterprise-wide rollouts.

Pilots often succeed because the variables are limited. Production environments introduce the realities of the enterprise: inconsistent processes, disconnected data, unclear ownership and varying levels of employee readiness. In many cases, issues that surface during scaling can be traced back to operating model decisions, process gaps or unclear expectations.

Employees need to understand where AI fits, when human judgment remains essential and how success will be measured. Without that clarity, scaling becomes much harder.

Creating the operational conditions for AI success

The most successful AI transformations start before AI is introduced.

They begin with understanding where employees experience friction. In most enterprises, those opportunities are not difficult to find. Repetitive administrative work and manual handoffs consume time and slow the business down. Employees directly in the workflows have the clearest view of where these issues exist.

When we launched our own efficiency and transformation program, we deliberately did not start with AI. We started by evaluating our data, reviewing business processes and identifying opportunities to simplify how work was performed. We found that simplifying and standardizing workflows before introducing AI significantly reduced complexity during deployment. Rather than asking AI to compensate for fragmented processes, we focused first on creating a consistent operational foundation. We focused first on process improvement, automation and operational discipline. Once those foundations were in place, we began layering AI into the environment.

AI outcomes are heavily influenced by the quality of the processes and the data along with the governance structures supporting them. If the underlying process is inconsistent, AI will struggle to create consistent value. If the process is understood, governed and measurable, AI has a much stronger foundation.

I often say that good data and good processes deliver good AI outcomes. That continues to hold true regardless of the model or technology being deployed.

The real challenge is making sure employees know what AI is using, where it fits in the workflow and when they should rely on the output. If that is unclear, adoption slows. People may not trust the answer, may use the tool inconsistently or may avoid changing how work gets done.

Before scaling AI, leaders need to answer a few basic questions. What problem are we solving? Is the process consistent enough? Is the data reliable enough? Where does human judgment still matter? And how will we know whether the tool is improving the work? Those questions determine whether AI becomes part of how teams operate.

Measure outcomes before you scale

AI programs often lose momentum when leaders measure activity instead of impact. 63% of high-maturity organizations implement formal metrics to evaluate transformation efforts.

Leaders often track how many employees have access to AI, how many licenses have been provisioned or how many use cases have been launched. Those metrics can be useful, but they do not always show whether the organization is creating business value. Activity is not the same as impact.

The more meaningful indicators are instead tied to operational performance: support ticket volumes, incident reduction, productivity improvements, user experience, cycle times and service quality.

We have seen the value of this approach firsthand. As part of our transformation program, we standardized service delivery processes and moved hundreds of teams onto a common service management platform. In our own experience, process improvements and platform consolidation initially reduced support ticket volumes by approximately 30%.

After that foundation was established, additional automation and AI capabilities helped drive reductions closer to 70%.

The initial improvement came from better processes and greater operational consistency. Automation and AI then helped accelerate the results. That is the pattern leaders should look for: Identify where work slows down, improve the process, establish accountability and introduce AI where the environment is ready to support it.

This approach also helps build trust. Employees can see the value being created. Leaders can measure progress. Teams can learn from early deployments before scaling more broadly.

Preparing people is the real AI strategy

Technology adoption has always been closely connected to people.

Employees are more likely to embrace change when they understand how technology helps them be more effective. They need practical experience, clear expectations and opportunities to learn. AI introduces new ways of working, and organizations need to prepare employees for that shift.

In our own organization, we encouraged every employee to establish an AI-related learning goal because familiarity with emerging technologies is becoming part of every role. Some goals were simple. Some were more advanced. The important point was creating a culture where people continue to learn and understand how AI applies to their work versus forcing AI activity broadly all at once.

As AI becomes more embedded in enterprise operations, organizations with strong foundations in governance, process discipline and workforce readiness will be better positioned to capture long-term value.

The companies realizing the greatest value from AI are investing in technology while also strengthening the operating models, information management practices and employee capabilities that support adoption. Sustainable transformation requires attention to people, processes, data and technology.

Preparing people, building trust and creating clear operating models remain central to any successful AI strategy.

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

Als Umgebung für Entwickler hat Microsoft Windows in den letzten Jahren einen Sprung nach vorne gemacht. Mit dem Windows-Subsystem für Linux (WSL) ist es nahtlos möglich, mit Linux unter Windows zu arbeiten – ohne den Mehraufwand, den eine virtuelle Maschine (VM) mit sich bringt. Zudem sind sämtliche gängigen Dev-Tools als native Windows-Versionen verfügbar – und Microsoft hat eine ganze Reihe entsprechender Funktionen auch direkt in sein Betriebssystem integriert.

Für Developer, die besonders schnell mit einer Windows-Maschine entwickeln wollen, hat Microsoft mit der „Windows Developer Config“ sogar so etwas wie eine Schnellspur geschaffen: Diese Sammlung von Powershell-Skripten fungiert als eine Art „Starter Kit“ und unterstützt dabei, Windows-Systeme möglichst schnell und komfortabel als Entwicklungsumgebung einzurichten. 

Wenn Sie hingegen – wie die meisten Entwickler – Wert darauflegen, die Kontrolle zu behalten und Ihr Dev-System selbst einzurichten und zu konfigurieren, ist ein bisschen Vorarbeit nötig. Der Aufwand selbst ist dabei überschaubar, die konkreten Schritte sind jedoch erfolgsentscheidend (und nicht unbedingt offensichtlich).   

Hinweis: Um die nachfolgenden Maßnahmen umzusetzen, sollten Sie auf Ihrem System über Administratorrechte verfügen.

1. WSL installieren

WSL stellt Windows-Benutzern ein vollständiges Linux-System über die Kommandozeile zur Verfügung – was weniger Overhead verursacht als eine VM. Da Software weltweit vor allem unter Linux– oder Unix-ähnlichen Systemen wie macOS entwickelt wird, ist das ein echter Vorteil.

Um WSL zu installieren, öffnen Sie ein Konsolenfenster mit Administratorrechten und nutzen den Befehl:

wsl --install

Die Installation kann einige Zeit in Anspruch nehmen, da das System sowohl die Kernkomponenten für WSL als auch – damit zusammenhängend – eine Linux-Distribution herunterladen muss.

Die Standard-Linux-Distribution in WSL ist Ubuntu 26.04 LTS. Diese erfüllt als Default-Lösung die meisten Anforderungen, die Entwickler an eine Linux-Distribution stellen. Es stehen jedoch auch andere Distributionen zur Verfügung – und es kommen regelmäßig neue hinzu. Sie könnten sogar Ihre eigene, benutzerdefinierte Linux-Distribution für WSL kreieren.

Sobald WSL installiert ist, können Sie über den Befehl wsl –list –online alle verfügbaren Distributionen anzeigen. Um eine davon zu installieren, nutzen Sie den Befehl wsl --install . Die meisten verfügbaren Optionen sind auf unterschiedliche Vorlieben oder spezifische Anforderungen zugeschnitten. Wenn Sie beispielsweise an einem Projekt arbeiten, das Debian als Grundlage voraussetzt, sollten Sie das auch installieren.

WSL-Distributionen werden standardmäßig im AppData-Verzeichnis abgelegt – genauer gesagt unter AppData\Local\Packages\. Wenn Sie die Dateien in ein anderes Verzeichnis oder auf ein anderes Laufwerk verschieben möchten, können Sie das mit dem Befehl wsl --manage --move bewerkstelligen.

Darüber hinaus hat Microsoft Ende Juni 2026 mit WSL-Container (derzeit in der Public Preview) eine wichtige neue Funktion für WSL vorgestellt. Diese ermöglicht es, Linux-Container nativ unter Windows auszuführen.

2. Dev-Drive-Laufwerk konfigurieren

Um Projekte zu speichern, nutzen die meisten Windows-Benutzer standardmäßig ein Verzeichnis auf einem NTFS-Volume – entweder im eigenen Benutzerprofil oder über einen anderen Pfad. Das ist als Default-Option keine schlechte Wahl. Allerdings gibt es bessere Alternativen.

Zum Beispiel „Dev Drive“, ein neuer Laufwerkstyp unter Windows. Dieser nutzt statt NTFS das neuere Dateisystem ReFS („Resilient File System“). Dieses wurde ursprünglich für Windows Server entwickelt und bietet Funktionen, die darauf ausgelegt sind, Softwareentwicklungs-Workloads besser zu bewältigen. Dazu gehören:  

• Copy-on-Write: Projektverzeichnisse können Tausende von Dateien und Dutzende von Unterverzeichnissen enthalten. Kopien von Projekten dieser Art anzufertigen, lässt sich mit ReFS deutlich schneller bewältigen, da das Dateisystem Kopien von Daten erst dann erstellt, wenn diese auch geändert werden. Reine Kopien sind hingegen Links, die auf die Originale verweisen.
• Antivirus-Komfort: Über einen Dev Drive lassen sich die standardmäßigen Beeinträchtigungen durch die nativen Antivirus-Tools von Windows minimieren. Dieses Feature erlaubt es, Entwicklerverzeichnisse manuell von Scan-Vorgängen zu exkludieren.
• Virtuelle Festplatte oder Partition: Dev Drives können als virtuelle Festplattendatei eingerichtet oder direkt auf einer formatierten Partition genutzt werden. Ersteres ist flexibler (unter anderem lässt sich die Größe leichter anpassen), Letzteres möglicherweise performanter.

Zwei Dinge sollten Sie im Zusammenhang mit Dev Drives unbedingt beachten:

1. Dev Drives sind für Projekte gedacht, nicht für Tools: Dort legen Sie Ihre Projekt-Repositories, Build-Artefakte und zwischengespeicherte Dateien ab. Language Runtimes, Compiler oder anderen Toolchain-Utlities sollten hingegen auf regulären NTFS-Volumes gespeichert werden.
2. Low-Level-Tools funktionieren unter Umständen nicht wie beabsichtigt: Dateisystem-Utilities auf Expertenniveau, die Informationen direkt aus den Dateiinformationen auslesen, verhalten sich im Zusammenspiel mit ReFS-Volumes möglicherweise nicht wie vorgesehen. So ist etwa das Speicherplatz-Management-Tool WizTree unter ReFS extrem langsam.

3. WinGet nutzen

Microsoft hat Windows inzwischen auch mit einem offiziellen Package-Management-System ausgestattet – WinGet. Dieses installiert jede Art von Windows-Applikation und bietet zudem ein vollständiges Befehlszeilen-Interface für Interaktion und Automatisierung.    

WinGet wird vom Windows-Software-Ökosystem umfassend unterstützt – die Wahrscheinlichkeit ist also groß, dass es für jedes Windows-Programm, das Sie benötigen, ein WinGet-Paket gibt (dazu gleich mehr).

Um im WinGet-Repository nach einem Paket zu suchen, nutzen Sie diesen Befehl (die Anführungszeichen sind erforderlich, wenn der Name des gesuchten Pakets Leerzeichen enthält – etwa Adobe Acrobat Reader):

winget search "Thing to search for"

Das WinGet-Package zu installieren, geht denkbar simpel von der Hand – und zwar mit:

winget install 

Dabei meint die ID des zu installierenden Pakets – nicht bloß seinen Namen. Im vorgenannten Beispiel (Adobe Acrobat Reader) würden Sie also folgenden Befehl nutzen, um dieses zu installieren:

winget install Adobe.Acrobat.Reader.64-bit

Falls Sie eine ansprechende grafische Benutzeroberfläche suchen, empfiehlt sich ein Blick auf UniGetUI. Dieses Tool verwaltet Packages aus verschiedenen Quellen – etwa WinGet, Scoop, Chocolatey, npm, pip oder Cargo, um nur einige zu nennen.

4. PowerShell für Skripte konfigurieren

Dieser Schritt ist lediglich einmal pro System zu absolvieren, kann jedoch die Entwicklererfahrung von Windows gewaltig steigern: PowerShell sollte entsprechend konfiguriert werden, damit lokale Skripte ausgeführt werden können.   

Um das zu bewerkstelligen, starten Sie PowerShell als Admin und nutzen folgendes Kommando:

set-executionpolicy remotesigned

Zwar verlangt Windows weiterhin, dass alle PowerShell-Skripte, die Sie aus dem Internet herunterladen, signiert sind – das ist jedoch im Grunde ein Edge Case. Alle lokal erstellten Skripte funktionieren nach dieser Maßnahme ohne Weiteres.

5. Weitere Dev-Tools installieren

Wie bereits erwähnt, bietet WinGet schnellen Zugriff auf alle gängigen Tools, die ein entwicklungsorientiertes Windows-System benötigt. Nachfolgend haben wir eine kleine Übersicht der wichtigsten Dev-Tools für Windows inklusive deren WinGet-IDs zusammengestellt, um Ihnen die Installation zu erleichtern.

• Git (Git.Git): Die Windows-Version des populären Versionskontrollsystems ist im Wesentlichen identisch mit der auf anderen Plattformen.
• Visual Studio BuildTools 2022 (Microsoft.VisualStudio.2022.BuildTools): Dieses minimale CLI-Tooling ist erforderlich, um das C/C++-Kompilierungssystem von Visual Studio zu nutzen.
• CMake (Kitware.Cmake): Die plattformübergreifende Build-Lösung wird häufig für größere oder komplexere Projekte benötigt, die C/C++ nutzen.

Dabei ist zu beachten, dass die standardmäßige BuildTools-Installation in der Regel nicht über die Tools verfügt, die für minimale C/C++-Build-Prozesse erforderlich sind. Das beheben Sie mit folgendem Befehl:

winget install -e --id Microsoft.VisualStudio.2022.BuildTools --force --override "--passive --wait --add Microsoft.VisualStudio.Workload.VCTools;includeRecommended"

Alle gängigen Editoren sind ebenfalls als native Windows-Apps über WinGet verfügbar – etwa:

• Microsoft Visual Studio Code (Microsoft.VisualStudioCode),
• GNU Emacs (GNU.Emacs), oder
• Neovim (Neovim.Neovim).

Für die Softwareentwicklung unter Windows optional, aber durchaus nützlich, sind außerdem folgende Werkzeuge:

• CoreUtils for Windows (Microsoft.Coreutils): Ein von Microsoft gepflegtes Open-Source-Projekt, das Dutzende von Linux-Befehlszeilen-Dienstprogrammen auf Windows bringt, beispielsweise cp, grep, find und ls.
• MSYS2 (MSYS2.MSYS2): Eine Tool-Sammlung, um Windows-Binärdateien mit dem GCC-Compiler zu erstellen. Diese bildet im Grunde eine Alternative zum Visual-Studio-Build-Stack auf Basis der Cygwin-Umgebung.
• LLVM (LLVM.LLVM): Auf diesem Compiler-Framework basieren Clang, Rust, Swift und viele andere Projekte. Wenn Sie LLVM als Abhängigkeit verwenden, müssen Sie die spezifische Version installieren, die Ihr Projekt erfordert.
• Docker Desktop (XP8CBJ40XLBWKX): Die Windows-native Version der Docker-Desktop-App.
• Microsoft PowerToys (Microsoft.PowerToys): Diese Sammlung besteht aus über 30 Utilities, die es erheblich vereinfachen, Windows anzupassen. Dazu gehören unter anderem ein Hosts-File-Editor, ein Unlocking-Tool für Dateien (praktisch, um festzustellen, welche Prozesse eine bestimmte Datei sperren) sowie ein Werkzeug, um Text zu extrahieren (praktisch, um Text von beliebigen Stellen auszulesen, einschließlich Bildschirmbereichen, die nicht mit dem Cursor markiert werden können).

(fm)

Dieser Artikel ist im Original bei unserer Schwesterpublikation Infoworld.com erschienen.

Traditional operating systems (OS) were built to manage hardware, files, apps, and users on a device, but Cloudflare says the agentic AI era requires a whole new format.

The company this week announced Cloudflare OS, which connects AI agents, enterprise data and context, internal systems, and workflows together in one secure workspace. It is open source and browser-based, sparing companies the need to build all-new infrastructure.

The OS is launching alongside several other new security, identity, spending, and user insight tools that Cloudflare has built for the AI-based workplace.

“Cloudflare OS isn’t a traditional desktop OS,” said Rita Kozlov, VP of product at Cloudflare. “It reimagines the workplace computing environment for AI.”

Open source OS runs in a browser

Cloudflare OS serves as a secure, AI-equipped workspace that is plugged into internal company systems. Available now through Cloudflare’s open source repository, it is accessible directly in a browser, and runs inside an enterprise’s Cloudflare account.

“It is a browser-based workspace that begins with a conversation,” Kozlov explained. Users can ask an agent to research, create slides, spreadsheets, and documents, build full-stack apps, or automate workflows without the need for a terminal. Those outputs are then shareable, but kept in isolated databases with access controls.

Enterprises will soon be able to access the OS directly through Cloudflare or via a “select group” of partners that will build tailored offerings on Cloudflare’s architecture, the company says. Because it is open source, organizational processes, internal system connections, and context aren’t locked into a vendor product or AI model provider. Customers can use whatever models they choose.

Cloudflare OS is built on Cloudflare Workers, Dynamic Workers, Durable Objects, and Access, the company’s zero trust network access (ZTNA) tool that verifies every user and request. Agents start with zero permissions by default and are only granted access to tools required for a specific task. Organizations configure their own Access policies, models, branding, skills, and integrations, Kozlov explained.

Governed connectors known as gatekeepers give admins control over what AI can see, what it can change, and when the system needs human sign-off. They can also control budgets, set rate limits, and delegate tasks to different models.

“Because agents act on people’s behalf and produce work others can access and modify, they require a new security model,” Kozlov said. Thus, Cloudflare OS tracks the resources an agent requires so the right access controls follow its work when it is shared.

Cloudflare initially built the OS for internal use, and employees “across every team” use it daily. Kozlov estimated that, over the last 30 days, internal users have used it to create more than 4,000 apps, automations, and tools. Over that same period, she claimed, the company’s sales team saved an estimated 10,000 hours by automating previously manual tasks like territory planning and proposal creation.

“We open sourced Cloudflare OS so any organization can build ‘Your Company OS,’” Kozlov said. Open source is critical because “you cannot put your company into software you do not own. Organizations need to be able to inspect the platform, customize it, connect their own systems, and make it their own,” she explained.

A more cohesive bundle

Cloudflare deserves credit for packaging Cloudflare OS as an operating system, noted tech analyst Carmi Levy.

“This very much is not Windows, macOS, or Linux, and it isn’t an operating system by its common definition,” he said. “But Cloudflare’s use of this terminology implies familiarity to enterprise IT buyers.”

This makes for an easier discussion as enterprises struggle to understand how to best incorporate AI-related platforms and workflows into infrastructure that wasn’t initially designed for it.

Microsoft has marketed the combination of its Azure, Entra, Fabric, Windows, and Microsoft 365 offerings as an operating system of sorts, but hasn’t pulled all the pieces into a common brand, Levy said. And Google’s Gemini, Workspace, Vertex AI, and Cloud Run are “circling similar territory.”

But, he noted, Cloudflare OS is “more cohesively bundled” and infrastructure-focused, offering a single pane of glass platform for buyers worried about stitching together otherwise disparate AI-aware networking pieces. The company recognizes that AI introduces new architectural realities such as inference and model routing “over and above” traditional OS core competencies.

“While competing offerings generally leave the infrastructure heavy lifting to enterprise decision-makers, Cloudflare is marketing itself as a single-source vendor, which potentially frees IT planners from having to integrate all the AI pieces on their own,” Levy said.

An infrastructure-first, application-agnostic approach means Cloudflare OS can coexist with whatever AI applications already exist in an enterprise, he said. It will “play nice” with OpenAI, Anthropic, Google, Microsoft, Meta, or open source layers, allowing employees to begin working in familiar workflows after sign-in.

“Its open-source architecture also minimizes the potential for vendor lock-in as enterprises gradually figure out how to evolve their stacks to align with new AI-era realities,” Levy said.

Managing identities and budgets for both humans and AI

As AI agents emerge across the enterprise, tracking their use can be challenging, causing problems from both a security and a spend standpoint. Along with Cloudflare OS, the company has launched a way to address this issue with its new Identity-Aware AI Gateway, now in beta.

Also integrated with Access, the offering gives admins visibility into what users (both human and AI) are requesting from AI models. It allows security teams to set up custom domains in front of their gateways and replace shared API keys by integrating with their identity provider, like Okta or Entra, and ZTNA infrastructure, Cloudflare explained.

Every request is tied to Access-verified identities, and enterprises can filter each user’s logs, analytics, and spend. IT teams can track redundancies, limit usage rates, and apply filters that strip out employee names, passwords, and other sensitive data before requests go to outside model providers.

A companion feature, AI Spend, tracks every user’s behavior over time to create a baseline of normal AI usage. When spending deviates from that pattern, the system alerts the IT team.

A new tab, User Insights, tracks cost and identifies over-spend caused by activities such as low cache-hit rates or oversized context windows. The capability scores sessions and compares them against account history using a 95th percentile session cost over the previous 30 days, Cloudflare product managers Ming Lu, Kenny Johnson, and Ayush Kumar explain in a blog post. Anything above 2x an account’s 95th percentile is a “strong candidate for anomalous behavior.”

For instance, one Cloudflare customer had an employee who left a rogue AI session running, generating a $30K bill. “User Insights helped them identify the problem and shut off access before the problem was further exacerbated,” Kozlov said.

Cloudflare is also building prompt classification functionality that sorts requests into categories such as coding or writing. This can help enterprises understand what AI is being used for.

“Once business traffic is separated from everything else, personal use becomes visible,” the project managers explained. “From the outside, someone running a side hustle on company time and someone quietly moving data out through a model look the same. Telling them apart is central to catching insider risk.”

Looking at the bigger picture

Identity-Aware AI Gateway and AI Spend address the visibility problem that has dogged so many recent AI deployments where enterprises failed to monitor usage, Levy noted. Projects “crashed and burned” as users unwittingly blew through token allocations.

These platforms provide single-point visibility into what is being used, how it’s being used, and where the potential lies for raising the productivity bar, he said. They overlay with existing models; in doing so, they enhance security with more precise control over resource allocations, and via automated anonymization protocols that prevent inadvertent sharing of sensitive data.

Ultimately, he said, vendors who free IT from having to independently assemble the pieces of their own AI implementations, and who assist them with answers to AI-specific questions, “will gain advantage over vendors that aren’t looking at the bigger picture.

This article originally appeared on CIO.com.

Traditional operating systems (OS) were built to manage hardware, files, apps, and users on a device, but Cloudflare says the agentic AI era requires a whole new format.

The company this week announced Cloudflare OS, which connects AI agents, enterprise data and context, internal systems, and workflows together in one secure workspace. It is open source and browser-based, sparing companies the need to build all-new infrastructure.

The OS is launching alongside several other new security, identity, spending, and user insight tools that Cloudflare has built for the AI-based workplace.

“Cloudflare OS isn’t a traditional desktop OS,” said Rita Kozlov, VP of product at Cloudflare. “It reimagines the workplace computing environment for AI.”

Open source OS runs in a browser

Cloudflare OS serves as a secure, AI-equipped workspace that is plugged into internal company systems. Available now through Cloudflare’s open source repository, it is accessible directly in a browser, and runs inside an enterprise’s Cloudflare account.

“It is a browser-based workspace that begins with a conversation,” Kozlov explained. Users can ask an agent to research, create slides, spreadsheets, and documents, build full-stack apps, or automate workflows without the need for a terminal. Those outputs are then shareable, but kept in isolated databases with access controls.

Enterprises will soon be able to access the OS directly through Cloudflare or via a “select group” of partners that will build tailored offerings on Cloudflare’s architecture, the company says. Because it is open source, organizational processes, internal system connections, and context aren’t locked into a vendor product or AI model provider. Customers can use whatever models they choose.

Cloudflare OS is built on Cloudflare Workers, Dynamic Workers, Durable Objects, and Access, the company’s zero trust network access (ZTNA) tool that verifies every user and request. Agents start with zero permissions by default and are only granted access to tools required for a specific task. Organizations configure their own Access policies, models, branding, skills, and integrations, Kozlov explained.

Governed connectors known as gatekeepers give admins control over what AI can see, what it can change, and when the system needs human sign-off. They can also control budgets, set rate limits, and delegate tasks to different models.

“Because agents act on people’s behalf and produce work others can access and modify, they require a new security model,” Kozlov said. Thus, Cloudflare OS tracks the resources an agent requires so the right access controls follow its work when it is shared.

Cloudflare initially built the OS for internal use, and employees “across every team” use it daily. Kozlov estimated that, over the last 30 days, internal users have used it to create more than 4,000 apps, automations, and tools. Over that same period, she claimed, the company’s sales team saved an estimated 10,000 hours by automating previously manual tasks like territory planning and proposal creation.

“We open sourced Cloudflare OS so any organization can build ‘Your Company OS,’” Kozlov said. Open source is critical because “you cannot put your company into software you do not own. Organizations need to be able to inspect the platform, customize it, connect their own systems, and make it their own,” she explained.

A more cohesive bundle

Cloudflare deserves credit for packaging Cloudflare OS as an operating system, noted tech analyst Carmi Levy.

“This very much is not Windows, macOS, or Linux, and it isn’t an operating system by its common definition,” he said. “But Cloudflare’s use of this terminology implies familiarity to enterprise IT buyers.”

This makes for an easier discussion as enterprises struggle to understand how to best incorporate AI-related platforms and workflows into infrastructure that wasn’t initially designed for it.

Microsoft has marketed the combination of its Azure, Entra, Fabric, Windows, and Microsoft 365 offerings as an operating system of sorts, but hasn’t pulled all the pieces into a common brand, Levy said. And Google’s Gemini, Workspace, Vertex AI, and Cloud Run are “circling similar territory.”

But, he noted, Cloudflare OS is “more cohesively bundled” and infrastructure-focused, offering a single pane of glass platform for buyers worried about stitching together otherwise disparate AI-aware networking pieces. The company recognizes that AI introduces new architectural realities such as inference and model routing “over and above” traditional OS core competencies.

“While competing offerings generally leave the infrastructure heavy lifting to enterprise decision-makers, Cloudflare is marketing itself as a single-source vendor, which potentially frees IT planners from having to integrate all the AI pieces on their own,” Levy said.

An infrastructure-first, application-agnostic approach means Cloudflare OS can coexist with whatever AI applications already exist in an enterprise, he said. It will “play nice” with OpenAI, Anthropic, Google, Microsoft, Meta, or open source layers, allowing employees to begin working in familiar workflows after sign-in.

“Its open-source architecture also minimizes the potential for vendor lock-in as enterprises gradually figure out how to evolve their stacks to align with new AI-era realities,” Levy said.

Managing identities and budgets for both humans and AI

As AI agents emerge across the enterprise, tracking their use can be challenging, causing problems from both a security and a spend standpoint. Along with Cloudflare OS, the company has launched a way to address this issue with its new Identity-Aware AI Gateway, now in beta.

Also integrated with Access, the offering gives admins visibility into what users (both human and AI) are requesting from AI models. It allows security teams to set up custom domains in front of their gateways and replace shared API keys by integrating with their identity provider, like Okta or Entra, and ZTNA infrastructure, Cloudflare explained.

Every request is tied to Access-verified identities, and enterprises can filter each user’s logs, analytics, and spend. IT teams can track redundancies, limit usage rates, and apply filters that strip out employee names, passwords, and other sensitive data before requests go to outside model providers.

A companion feature, AI Spend, tracks every user’s behavior over time to create a baseline of normal AI usage. When spending deviates from that pattern, the system alerts the IT team.

A new tab, User Insights, tracks cost and identifies over-spend caused by activities such as low cache-hit rates or oversized context windows. The capability scores sessions and compares them against account history using a 95th percentile session cost over the previous 30 days, Cloudflare product managers Ming Lu, Kenny Johnson, and Ayush Kumar explain in a blog post. Anything above 2x an account’s 95th percentile is a “strong candidate for anomalous behavior.”

For instance, one Cloudflare customer had an employee who left a rogue AI session running, generating a $30K bill. “User Insights helped them identify the problem and shut off access before the problem was further exacerbated,” Kozlov said.

Cloudflare is also building prompt classification functionality that sorts requests into categories such as coding or writing. This can help enterprises understand what AI is being used for.

“Once business traffic is separated from everything else, personal use becomes visible,” the project managers explained. “From the outside, someone running a side hustle on company time and someone quietly moving data out through a model look the same. Telling them apart is central to catching insider risk.”

Looking at the bigger picture

Identity-Aware AI Gateway and AI Spend address the visibility problem that has dogged so many recent AI deployments where enterprises failed to monitor usage, Levy noted. Projects “crashed and burned” as users unwittingly blew through token allocations.

These platforms provide single-point visibility into what is being used, how it’s being used, and where the potential lies for raising the productivity bar, he said. They overlay with existing models; in doing so, they enhance security with more precise control over resource allocations, and via automated anonymization protocols that prevent inadvertent sharing of sensitive data.

Ultimately, he said, vendors who free IT from having to independently assemble the pieces of their own AI implementations, and who assist them with answers to AI-specific questions, “will gain advantage over vendors that aren’t looking at the bigger picture.

Traditional operating systems (OS) were built to manage hardware, files, apps, and users on a device, but Cloudflare says the agentic AI era requires a whole new format.

The company this week announced Cloudflare OS, which connects AI agents, enterprise data and context, internal systems, and workflows together in one secure workspace. It is open source and browser-based, sparing companies the need to build all-new infrastructure.

The OS is launching alongside several other new security, identity, spending, and user insight tools that Cloudflare has built for the AI-based workplace.

“Cloudflare OS isn’t a traditional desktop OS,” said Rita Kozlov, VP of product at Cloudflare. “It reimagines the workplace computing environment for AI.”

Open source OS runs in a browser

Cloudflare OS serves as a secure, AI-equipped workspace that is plugged into internal company systems. Available now through Cloudflare’s open source repository, it is accessible directly in a browser, and runs inside an enterprise’s Cloudflare account.

“It is a browser-based workspace that begins with a conversation,” Kozlov explained. Users can ask an agent to research, create slides, spreadsheets, and documents, build full-stack apps, or automate workflows without the need for a terminal. Those outputs are then shareable, but kept in isolated databases with access controls.

Enterprises will soon be able to access the OS directly through Cloudflare or via a “select group” of partners that will build tailored offerings on Cloudflare’s architecture, the company says. Because it is open source, organizational processes, internal system connections, and context aren’t locked into a vendor product or AI model provider. Customers can use whatever models they choose.

Cloudflare OS is built on Cloudflare Workers, Dynamic Workers, Durable Objects, and Access, the company’s zero trust network access (ZTNA) tool that verifies every user and request. Agents start with zero permissions by default and are only granted access to tools required for a specific task. Organizations configure their own Access policies, models, branding, skills, and integrations, Kozlov explained.

Governed connectors known as gatekeepers give admins control over what AI can see, what it can change, and when the system needs human sign-off. They can also control budgets, set rate limits, and delegate tasks to different models.

“Because agents act on people’s behalf and produce work others can access and modify, they require a new security model,” Kozlov said. Thus, Cloudflare OS tracks the resources an agent requires so the right access controls follow its work when it is shared.

Cloudflare initially built the OS for internal use, and employees “across every team” use it daily. Kozlov estimated that, over the last 30 days, internal users have used it to create more than 4,000 apps, automations, and tools. Over that same period, she claimed, the company’s sales team saved an estimated 10,000 hours by automating previously manual tasks like territory planning and proposal creation.

“We open sourced Cloudflare OS so any organization can build ‘Your Company OS,’” Kozlov said. Open source is critical because “you cannot put your company into software you do not own. Organizations need to be able to inspect the platform, customize it, connect their own systems, and make it their own,” she explained.

A more cohesive bundle

Cloudflare deserves credit for packaging Cloudflare OS as an operating system, noted tech analyst Carmi Levy.

“This very much is not Windows, macOS, or Linux, and it isn’t an operating system by its common definition,” he said. “But Cloudflare’s use of this terminology implies familiarity to enterprise IT buyers.”

This makes for an easier discussion as enterprises struggle to understand how to best incorporate AI-related platforms and workflows into infrastructure that wasn’t initially designed for it.

Microsoft has marketed the combination of its Azure, Entra, Fabric, Windows, and Microsoft 365 offerings as an operating system of sorts, but hasn’t pulled all the pieces into a common brand, Levy said. And Google’s Gemini, Workspace, Vertex AI, and Cloud Run are “circling similar territory.”

But, he noted, Cloudflare OS is “more cohesively bundled” and infrastructure-focused, offering a single pane of glass platform for buyers worried about stitching together otherwise disparate AI-aware networking pieces. The company recognizes that AI introduces new architectural realities such as inference and model routing “over and above” traditional OS core competencies.

“While competing offerings generally leave the infrastructure heavy lifting to enterprise decision-makers, Cloudflare is marketing itself as a single-source vendor, which potentially frees IT planners from having to integrate all the AI pieces on their own,” Levy said.

An infrastructure-first, application-agnostic approach means Cloudflare OS can coexist with whatever AI applications already exist in an enterprise, he said. It will “play nice” with OpenAI, Anthropic, Google, Microsoft, Meta, or open source layers, allowing employees to begin working in familiar workflows after sign-in.

“Its open-source architecture also minimizes the potential for vendor lock-in as enterprises gradually figure out how to evolve their stacks to align with new AI-era realities,” Levy said.

Managing identities and budgets for both humans and AI

As AI agents emerge across the enterprise, tracking their use can be challenging, causing problems from both a security and a spend standpoint. Along with Cloudflare OS, the company has launched a way to address this issue with its new Identity-Aware AI Gateway, now in beta.

Also integrated with Access, the offering gives admins visibility into what users (both human and AI) are requesting from AI models. It allows security teams to set up custom domains in front of their gateways and replace shared API keys by integrating with their identity provider, like Okta or Entra, and ZTNA infrastructure, Cloudflare explained.

Every request is tied to Access-verified identities, and enterprises can filter each user’s logs, analytics, and spend. IT teams can track redundancies, limit usage rates, and apply filters that strip out employee names, passwords, and other sensitive data before requests go to outside model providers.

A companion feature, AI Spend, tracks every user’s behavior over time to create a baseline of normal AI usage. When spending deviates from that pattern, the system alerts the IT team.

A new tab, User Insights, tracks cost and identifies over-spend caused by activities such as low cache-hit rates or oversized context windows. The capability scores sessions and compares them against account history using a 95th percentile session cost over the previous 30 days, Cloudflare product managers Ming Lu, Kenny Johnson, and Ayush Kumar explain in a blog post. Anything above 2x an account’s 95th percentile is a “strong candidate for anomalous behavior.”

For instance, one Cloudflare customer had an employee who left a rogue AI session running, generating a $30K bill. “User Insights helped them identify the problem and shut off access before the problem was further exacerbated,” Kozlov said.

Cloudflare is also building prompt classification functionality that sorts requests into categories such as coding or writing. This can help enterprises understand what AI is being used for.

“Once business traffic is separated from everything else, personal use becomes visible,” the project managers explained. “From the outside, someone running a side hustle on company time and someone quietly moving data out through a model look the same. Telling them apart is central to catching insider risk.”

Looking at the bigger picture

Identity-Aware AI Gateway and AI Spend address the visibility problem that has dogged so many recent AI deployments where enterprises failed to monitor usage, Levy noted. Projects “crashed and burned” as users unwittingly blew through token allocations.

These platforms provide single-point visibility into what is being used, how it’s being used, and where the potential lies for raising the productivity bar, he said. They overlay with existing models; in doing so, they enhance security with more precise control over resource allocations, and via automated anonymization protocols that prevent inadvertent sharing of sensitive data.

Ultimately, he said, vendors who free IT from having to independently assemble the pieces of their own AI implementations, and who assist them with answers to AI-specific questions, “will gain advantage over vendors that aren’t looking at the bigger picture.

AI note-taking app maker Granola is accused of violating privacy laws by developing software that can record conversations without all participants’ consent, according to a lawsuit filed July 30 in a California federal court.

It follows a similar ongoing case in the same district, filed last year, that involves another note-taking and transcription software vendor, Otter.ai.

AI note-taking apps have proliferated in recent years, with dedicated tools emerging from vendors including Fellow, Fireflies, Otter, and others, some of which claim to have tens of millions of users. These AI assistants record and transcribe meeting conversations, generating automated summaries and follow-up items. Similar note-taking functionality is also built into virtual meeting platforms such as Google Meet, Microsoft Teams, and Zoom.

However, the use of these AI note-taking tools has raised privacy concerns over the ability of some to record and transcribe conversations without the consent of all participants.

The proposed class action complaint against Granola, filed by Florida resident Tarra Chamberlain in the US District Court for the Northern District of California, alleges the company “purposefully” designed its app to record calls without requiring disclosure to all participants.  

While some note-taking tools require a bot to join a video or voice call, Granola captures audio directly from the user’s computer, allowing it to transcribe meetings without appearing as a meeting participant.

The complaint argues that this violates individual privacy rights as well as the California Invasion of Privacy Act (CIPA) that requires “all-party” consent when recording calls.

The complaint also alleges that Granola then by default uses transcription data for commercial purposes, including its use in training its AI models, and “actively advertises the hidden nature of its technology as one of its primary advantages.”

Granola did not respond to a request for comment.

According to the company’s website, Granola offers two optional “transparency features” that can be enabled by app users and admins: an automated chat message that alerts participants when transcription begins, and a watermark added to the user’s video feed. The company also promises that data used to train its AI models is anonymized and “never sent to third parties.”

The Granola case bears similarities to a separate lawsuit involving Otter.ai. The class action filed last year alleges that Otter.ai records all users without their consent and uses their voices to train its speech recognition AI tools.

Reporting on the latest developments in the Otter.ai suit, MLex wrote this week that, during a court hearing Monday, the judge overseeing the case expressed skepticism about the company’s argument to dismiss the case. US District Judge Eumi K. Lee did not issue a ruling from the bench, saying a written judgement would follow.

The two cases highlight some of the concerns businesses face when deploying AI note-taking tools.

AI notetaking is “more dangerous than any other type of traditional recording apps and tools,” said Enza Iannopollo, Forrester VP and principal analyst, as it raises additional questions about the use of employees’ conversation data.

“Specifically, is the recorded data used for training models? Is the voice used for training other AI? How do I get ‘forgotten’ after my data and biometrics have been recorded? These concerns apply to AI specifically and must be added to the traditional privacy and confidentiality concerns organizations have for other type of recording apps and tools,” she said.

Before deploying AI note-taking apps, Iannopollo recommends that businesses take appropriate steps to vet the tools and “ensure that all contractual clauses are aligned to the business AI risk appetite and risk management best practices.”

“As these tools record, process, store, and share biometric data, organizations must ensure that they comply with all the relevant requirements,” Iannopollo said, adding that transparency and consent notices should be provided to all parties involved in the use of AI note-taking apps.

Governance is what lets a team run coding agents and stand behind what they ship. As more code originates from agents, the question every engineering leader is now answering is not how fast the work moves, but who owns it and how it gets checked before it lands.

The teams pulling ahead decide on the boundaries and the checks in advance. That’s what makes it safe to hit the accelerator: handing agents real work, with the right context in front of them, instead of the supervised busywork you get when no one trusts the output.

Manual review doesn’t scale, it just moves the bottleneck

Reviewing everything by hand feels responsible, and at low volume it works. It falls apart the moment agents produce more than people can read. A team that inspects every change by hand just moves the constraint from writing code to approving it, and the queue that forms there is as long as the one it replaced.

Worse, blanket caution treats every change as equally risky, so a copy tweak and a change to the authentication layer get the same scrutiny. Attention gets spread evenly across all kinds of work, which means the actually risky changes get less review time. Caution without structure doesn’t make you safer. It just slows you down.

Governance should be infrastructure, not process

Governance done well is a set of decisions made once, in advance, so they don’t have to be relitigated on every change and so agents spend tokens on work that ships instead of reruns and reverts.

1.       Scope: what each agent can touch, and what it can see. An agent working on documentation should not be able to modify how the system handles credentials. Defining those boundaries up front does double duty: it keeps most agent work inside areas where mistakes are cheap and recoverable, and it gives each agent the right context for its task instead of the whole codebase. Scope is where governance and good context come together, and it’s a big part of why governed agent programs produce better work.

2.      Policy that runs itself. The parts of a CI/CD pipeline can run automatically on every change: tests pass, security scans clear, dependencies are approved, and anything touching a sensitive system routes to a required human owner. Encoded as policy, these run on both the first change and the ten-thousandth without fatigue, which is exactly the property you want when volume climbs.

3.      Ownership that’s never ambiguous. Every change, whoever or whatever produced it, has a named person accountable for accepting it and standing behind it. Ownership is what keeps velocity from turning into a diffusion of responsibility, and it’s what lets you trace any decision back to a person when something goes wrong.

What governed agent programs actually look like

Put those decisions in place and you can give agents more room without worrying about them running wild. When the boundaries are clear and the checks run on their own, letting an agent work in a well-scoped area stops being a leap of faith. The guardrails are what make the freedom usable, the same way brakes allow a car to go fast with confidence.

Governance isn’t the tax you pay to use agents safely. It’s the infrastructure that turns agents from a risk you manage into leverage you can actually rely on.

Where to start

You don’t need a new governance program before you can move. Run agents inside your existing system of work, where the permissions, ownership, and checks already live. Start with the scope and policy decisions that protect your riskiest areas, and widen the lane as trust builds.

See how leading engineering organizations govern agent work without slowing it down at jira.dev.

AI note-taking app maker Granola is accused of violating privacy laws by developing software that can record conversations without all participants’ consent, according to a lawsuit filed July 30 in a California federal court.

It follows a similar ongoing case in the same district, filed last year, that involves another note-taking and transcription software vendor, Otter.ai.

AI note-taking apps have proliferated in recent years, with dedicated tools emerging from vendors including Fellow, Fireflies, Otter, and others, some of which claim to have tens of millions of users. These AI assistants record and transcribe meeting conversations, generating automated summaries and follow-up items. Similar note-taking functionality is also built into virtual meeting platforms such as Google Meet, Microsoft Teams, and Zoom.

However, the use of these AI note-taking tools has raised privacy concerns over the ability of some to record and transcribe conversations without the consent of all participants.

The proposed class action complaint against Granola, filed by Florida resident Tarra Chamberlain in the US District Court for the Northern District of California, alleges the company “purposefully” designed its app to record calls without requiring disclosure to all participants.  

While some note-taking tools require a bot to join a video or voice call, Granola captures audio directly from the user’s computer, allowing it to transcribe meetings without appearing as a meeting participant.

The complaint argues that this violates individual privacy rights as well as the California Invasion of Privacy Act (CIPA) that requires “all-party” consent when recording calls.

The complaint also alleges that Granola then by default uses transcription data for commercial purposes, including its use in training its AI models, and “actively advertises the hidden nature of its technology as one of its primary advantages.”

Granola did not respond to a request for comment.

According to the company’s website, Granola offers two optional “transparency features” that can be enabled by app users and admins: an automated chat message that alerts participants when transcription begins, and a watermark added to the user’s video feed. The company also promises that data used to train its AI models is anonymized and “never sent to third parties.”

The Granola case bears similarities to a separate lawsuit involving Otter.ai. The class action filed last year alleges that Otter.ai records all users without their consent and uses their voices to train its speech recognition AI tools.

Reporting on the latest developments in the Otter.ai suit, MLex wrote this week that, during a court hearing Monday, the judge overseeing the case expressed skepticism about the company’s argument to dismiss the case. US District Judge Eumi K. Lee did not issue a ruling from the bench, saying a written judgement would follow.

The two cases highlight some of the concerns businesses face when deploying AI note-taking tools.

AI notetaking is “more dangerous than any other type of traditional recording apps and tools,” said Enza Iannopollo, Forrester VP and principal analyst, as it raises additional questions about the use of employees’ conversation data.

“Specifically, is the recorded data used for training models? Is the voice used for training other AI? How do I get ‘forgotten’ after my data and biometrics have been recorded? These concerns apply to AI specifically and must be added to the traditional privacy and confidentiality concerns organizations have for other type of recording apps and tools,” she said.

Before deploying AI note-taking apps, Iannopollo recommends that businesses take appropriate steps to vet the tools and “ensure that all contractual clauses are aligned to the business AI risk appetite and risk management best practices.”

“As these tools record, process, store, and share biometric data, organizations must ensure that they comply with all the relevant requirements,” Iannopollo said, adding that transparency and consent notices should be provided to all parties involved in the use of AI note-taking apps.

Governance is what lets a team run coding agents and stand behind what they ship. As more code originates from agents, the question every engineering leader is now answering is not how fast the work moves, but who owns it and how it gets checked before it lands.

The teams pulling ahead decide on the boundaries and the checks in advance. That’s what makes it safe to hit the accelerator: handing agents real work, with the right context in front of them, instead of the supervised busywork you get when no one trusts the output.

Manual review doesn’t scale, it just moves the bottleneck

Reviewing everything by hand feels responsible, and at low volume it works. It falls apart the moment agents produce more than people can read. A team that inspects every change by hand just moves the constraint from writing code to approving it, and the queue that forms there is as long as the one it replaced.

Worse, blanket caution treats every change as equally risky, so a copy tweak and a change to the authentication layer get the same scrutiny. Attention gets spread evenly across all kinds of work, which means the actually risky changes get less review time. Caution without structure doesn’t make you safer. It just slows you down.

Governance should be infrastructure, not process

Governance done well is a set of decisions made once, in advance, so they don’t have to be relitigated on every change and so agents spend tokens on work that ships instead of reruns and reverts.

1.       Scope: what each agent can touch, and what it can see. An agent working on documentation should not be able to modify how the system handles credentials. Defining those boundaries up front does double duty: it keeps most agent work inside areas where mistakes are cheap and recoverable, and it gives each agent the right context for its task instead of the whole codebase. Scope is where governance and good context come together, and it’s a big part of why governed agent programs produce better work.

2.      Policy that runs itself. The parts of a CI/CD pipeline can run automatically on every change: tests pass, security scans clear, dependencies are approved, and anything touching a sensitive system routes to a required human owner. Encoded as policy, these run on both the first change and the ten-thousandth without fatigue, which is exactly the property you want when volume climbs.

3.      Ownership that’s never ambiguous. Every change, whoever or whatever produced it, has a named person accountable for accepting it and standing behind it. Ownership is what keeps velocity from turning into a diffusion of responsibility, and it’s what lets you trace any decision back to a person when something goes wrong.

What governed agent programs actually look like

Put those decisions in place and you can give agents more room without worrying about them running wild. When the boundaries are clear and the checks run on their own, letting an agent work in a well-scoped area stops being a leap of faith. The guardrails are what make the freedom usable, the same way brakes allow a car to go fast with confidence.

Governance isn’t the tax you pay to use agents safely. It’s the infrastructure that turns agents from a risk you manage into leverage you can actually rely on.

Where to start

You don’t need a new governance program before you can move. Run agents inside your existing system of work, where the permissions, ownership, and checks already live. Start with the scope and policy decisions that protect your riskiest areas, and widen the lane as trust builds.

See how leading engineering organizations govern agent work without slowing it down at jira.dev.

Ancient Greek sophist Protagoras famously said, “There are two sides to every question.” But OpenAI’s latest attempt at reality distortion seems determined to narrow this dispute to just one. In its motion to reject Apple’s complaint, the company does not meaningfully acknowledge the criticisms levelled against it, preferring instead to recast the case as a grievance over talent retention and product-market failure.

The filing

In case you missed the news, OpenAI filed a motion to the court to dismiss Apple’s recent lawsuit against it. In that filing, OpenAI argued that, “Apple should not be permitted to use a baseless and pretextual lawsuit to make up for its shortcomings in the market for talent and retaining its employees, and its failures to integrate AI into its products.”

The company’s dismissal claims Apple’s case was, “plainly filed without adequate investigation and built on selectively excerpted communications and ordinary conduct stripped of context,” adding, in a turn of phrase borrowed from Apple’s own complaint, that it is “rotten to its core.”

The narratives can change

As ever with litigation, these are allegations and counter-allegations rather than findings of fact. The value of the filings is that they show how each side wants the court, and the public, to understand the same disputed events. At the moment, we don’t yet know how Apple will respond to OpenAI’s response; it follows that company’s failed attempt to woo public opinion earlier in the week when it deployed what some see as a “cookie jar” defense, arguing that Apple’s secrets only slipped out because the figurative jar lid was open.

OpenAI likely hopes for more success with its latest attempt to defend itself against Apple’s claims it engaged in a coordinated attempt to obtain trade secrets through questionable recruitment practices.

Central to the company’s counter-argument are its attempts to recharacterize some of Apple’s claims. For example, Apple alleges that one former staffer, Chang Liu, downloaded confidential files after leaving the company. OpenAI argues that Liu was instead attempting to help ex-colleagues who asked him for assistance. This is a useful example of the Protagorean frame: both companies are trying to extract different meanings from the same event.

What the truth might be

The courts will need to decide which version of events is closer to the truth. What is already clear is that OpenAI has been actively involved in recruiting Apple staff, including the services of former Chief Design Officer Jony Ive, as it develops a product that, to a layman like me, sounds likely to compete with Apple hardware. OpenAI says those recruitments reflect Apple’s failure to retain its staff; Apple argues its competitor is using exfiltrated confidential information to guide its hiring. The court will need to decide that story as well.

Ultimately, I don’t expect OpenAI’s efforts to have the court reject Apple’s lawsuit to succeed. Apple is asking for discovery precisely so it can test whether its reading of this distorted reality is supported by OpenAI’s internal procedures and the available facts. One of OpenAI’s arguments seems to be that Apple has not researched the matter thoroughly enough; Apple is quite literally requesting discovery to do just that.

What happens next?

I don’t know what discovery might turn up, but it does amuse me to think Apple could build its own large language model to boost the discovery process and identify communication conduits that might otherwise be obscured in the evidence initially available to it. How high, and in what direction, do OpenAI’s claimed recruitment practices go, and who is implicated in them? That’s something we might find out in the coming months.

OpenAI’s Protagorean defense extends a little further, of course, as the company also said it had “no use, need or desire for Apple’s trade secrets” because it is building “something entirely new.” This may surprise Apple, which has already alleged that OpenAI contacted its manufacturing partners and sought access to secret manufacturing processes Apple developed with them.

Once again, it will be up to the courts to decide whether those events took place, or if OpenAI’s defense has substance. Given that this dispute centers on product design and involves the AI company’s growing army of former Apple design and development staff, I find the denial hard to accept. But courts tend to make their own decisions, for good, or for ill. 

Fight or settle

What happens next? I think this attempt to reject the original litigation will fail, which means the case will enter the discovery process before one of two outcomes becomes more likely: A bitter public battle that lasts for years and might well end up in the Supreme Court, or an out-of-court settlement shaped by which side gains the most compelling evidence.

Like any war, there are really only two options: one side fights until the other can no longer continue, or both sides find a way to settle. The path to settlement may begin by recognizing that two stories can be applied to the same facts, and that the version closest to the truth often sits somewhere between them. I’m not a lawyer and I don’t have insider insight into the practicalities of the case, but based on what has been revealed so far, the most plausible combined story may be that Apple’s own vulnerabilities helped create an environment OpenAI chose to exploit. If so, Apple’s legal team will be searching hard for evidence of intent.

I expect they’ll find it.

You can follow me on social media! Join me on BlueSky,  LinkedIn, Mastodon and subscribe to The Core.

Ancient Greek sophist Protagoras famously said, “There are two sides to every question.” But OpenAI’s latest attempt at reality distortion seems determined to narrow this dispute to just one. In its motion to reject Apple’s complaint, the company does not meaningfully acknowledge the criticisms levelled against it, preferring instead to recast the case as a grievance over talent retention and product-market failure.

The filing

In case you missed the news, OpenAI filed a motion to the court to dismiss Apple’s recent lawsuit against it. In that filing, OpenAI argued that, “Apple should not be permitted to use a baseless and pretextual lawsuit to make up for its shortcomings in the market for talent and retaining its employees, and its failures to integrate AI into its products.”

The company’s dismissal claims Apple’s case was, “plainly filed without adequate investigation and built on selectively excerpted communications and ordinary conduct stripped of context,” adding, in a turn of phrase borrowed from Apple’s own complaint, that it is “rotten to its core.”

The narratives can change

As ever with litigation, these are allegations and counter-allegations rather than findings of fact. The value of the filings is that they show how each side wants the court, and the public, to understand the same disputed events. At the moment, we don’t yet know how Apple will respond to OpenAI’s response; it follows that company’s failed attempt to woo public opinion earlier in the week when it deployed what some see as a “cookie jar” defense, arguing that Apple’s secrets only slipped out because the figurative jar lid was open.

OpenAI likely hopes for more success with its latest attempt to defend itself against Apple’s claims it engaged in a coordinated attempt to obtain trade secrets through questionable recruitment practices.

Central to the company’s counter-argument are its attempts to recharacterize some of Apple’s claims. For example, Apple alleges that one former staffer, Chang Liu, downloaded confidential files after leaving the company. OpenAI argues that Liu was instead attempting to help ex-colleagues who asked him for assistance. This is a useful example of the Protagorean frame: both companies are trying to extract different meanings from the same event.

What the truth might be

The courts will need to decide which version of events is closer to the truth. What is already clear is that OpenAI has been actively involved in recruiting Apple staff, including the services of former Chief Design Officer Jony Ive, as it develops a product that, to a layman like me, sounds likely to compete with Apple hardware. OpenAI says those recruitments reflect Apple’s failure to retain its staff; Apple argues its competitor is using exfiltrated confidential information to guide its hiring. The court will need to decide that story as well.

Ultimately, I don’t expect OpenAI’s efforts to have the court reject Apple’s lawsuit to succeed. Apple is asking for discovery precisely so it can test whether its reading of this distorted reality is supported by OpenAI’s internal procedures and the available facts. One of OpenAI’s arguments seems to be that Apple has not researched the matter thoroughly enough; Apple is quite literally requesting discovery to do just that.

What happens next?

I don’t know what discovery might turn up, but it does amuse me to think Apple could build its own large language model to boost the discovery process and identify communication conduits that might otherwise be obscured in the evidence initially available to it. How high, and in what direction, do OpenAI’s claimed recruitment practices go, and who is implicated in them? That’s something we might find out in the coming months.

OpenAI’s Protagorean defense extends a little further, of course, as the company also said it had “no use, need or desire for Apple’s trade secrets” because it is building “something entirely new.” This may surprise Apple, which has already alleged that OpenAI contacted its manufacturing partners and sought access to secret manufacturing processes Apple developed with them.

Once again, it will be up to the courts to decide whether those events took place, or if OpenAI’s defense has substance. Given that this dispute centers on product design and involves the AI company’s growing army of former Apple design and development staff, I find the denial hard to accept. But courts tend to make their own decisions, for good, or for ill. 

Fight or settle

What happens next? I think this attempt to reject the original litigation will fail, which means the case will enter the discovery process before one of two outcomes becomes more likely: A bitter public battle that lasts for years and might well end up in the Supreme Court, or an out-of-court settlement shaped by which side gains the most compelling evidence.

Like any war, there are really only two options: one side fights until the other can no longer continue, or both sides find a way to settle. The path to settlement may begin by recognizing that two stories can be applied to the same facts, and that the version closest to the truth often sits somewhere between them. I’m not a lawyer and I don’t have insider insight into the practicalities of the case, but based on what has been revealed so far, the most plausible combined story may be that Apple’s own vulnerabilities helped create an environment OpenAI chose to exploit. If so, Apple’s legal team will be searching hard for evidence of intent.

I expect they’ll find it.

You can follow me on social media! Join me on BlueSky,  LinkedIn, Mastodon and subscribe to The Core.

Meta has released a beta coding agent designed to handle complex software assignments across large codebases.

Available for macOS and Linux, Muse Code uses the company’s new Muse Spark 1.2 model. It includes specialized background agents that remain active throughout a session instead of being created separately for individual tasks.

The agents carry out work asynchronously and decide when to report their findings to the primary agent. Meta said keeping them active reduces repeated information gathering and the need for developer direction during difficult, multi-step tasks.

“Muse Code uses a local event log in which every model call, tool run, approval, and edit is appended,” Meta said in a post, adding that the record “makes the runtime replay-exact and restart-safe” and allows the agent to resume precisely where it stopped after a crash.

Muse Spark 1.2 is available through Muse Code and the Meta Model API, for which Meta announced expanded global access.

Training and evaluation

Meta said it co-trained Muse Spark 1.2 with Muse Code to improve the model’s performance and usability when used with the agent. The training incorporated Muse Code’s tools and agent workflows, while Meta increased the computing resources used for coding and broadened the range of development environments.

The model was also trained on longer assignments, including whole-repository generation and large end-to-end software projects.

Lian Jye Su, chief analyst at Omdia, said Meta’s co-training approach was unlikely to provide a clear advantage because rivals were also developing their coding models and agent harnesses in close coordination.

“Other vendors, such as OpenAI and Anthropic, have been treating harness engineering as part of the training process,” Su said.

Optimizing the model and agent together could improve planning and context handling, but any competitive advantage would need to be demonstrated through better results on enterprise projects while reducing the need for human intervention, said Pareekh Jain, CEO of Pareekh Consulting.

Meta reported that Muse Spark 1.2 achieved an 82.9% pass@1 score on Terminal-Bench 2.1, behind Claude Opus 5 but slightly ahead of GPT-5.6 Terra. On DeepSWE 1.1, the model scored 59.3%, trailing both rivals.

For Terminal-Bench 2.1 and DeepSWE 1.1, Meta evaluated each model with its selected coding agent rather than using the same agent throughout. It also acknowledged that rival proprietary models may have performed differently under tools and prompts designed specifically for them.

Neil Shah, vice president of research at Counterpoint Research, said cross-vendor comparisons would be more meaningful if models were evaluated with third-party tools or within the same agent harness.

“The key metric for CIOs is the pass rate against an enterprise’s own pipeline, which will determine the success of the model-and-harness bundle, or, in this case, Meta’s Muse Spark 1.2 and Muse Code,” Shah said. “This will be the real benchmark.”

Enterprise adoption hurdles

Su said security and governance requirements could slow enterprise adoption, particularly where coding agents must be connected to existing identity systems.

“Many enterprises are still less willing to open up their CI/CD environments for AI tool integration,” Su said.

Shah said companies would need controls governing how agents access repositories, along with records showing how models and agent workflows handle enterprise data. He also cited the difficulty of forecasting token consumption and its effect on costs.

Meta’s pricing structure also creates a data-governance choice. The company said the lower-priced Contributor model may be used to improve its products, while the standard tier is not used for that purpose.

The Contributor tier costs $0.10 per million input tokens and $0.20 per million output tokens, compared with $1.25 and $4.25, respectively, for the standard tier.

“There is also a fear of vendor lock-in and reliance, as it may hurt long-term flexibility and system interoperability,” Su added.

Jain said adoption was likely to begin with narrowly defined, lower-risk work before companies allowed persistent agents to modify critical production code.

Microsoft has unveiled a suite of IQ products over the last few months. Work IQ, Fabric IQ, and Foundry IQ build on what Microsoft used to call its “Graphs,” the underlying data architecture that underpins its cloud services. These graphs provided a way to query the data your business uses, treating that data as nodes in a graph database and using the GraphQL API model to extract that data — for example, to pull data related to a specific individual held across the various Microsoft 365 applications.

The IQ suite follows a similar approach, using the same data, but treating it as the sparse vector store needed to provide grounding data for LLM-based applications. By treating the data as a set of embedding vectors, and integrating it with Model Context Protocol (MCP) servers, Microsoft is giving you the necessary tools to tie LLM output to your data, reducing the risk of hallucination and improving accuracy. Using your own data is a key part of delivering effective agents, ensuring they work within your constraints.

Extending IQ to the web

Web IQ, the latest member of the IQ suite, was unveiled at Build 2026. A modernization of the retired Bing Search APIs, Web IQ is an agent-focused web search tool that builds on the massive Bing search index to provide up-to-date general information for use in your applications.

It may seem a little odd to be talking about a web-wide source of grounding data in the context of a suite of tools that exist to improve the accuracy of your AI applications by providing access to your Microsoft-hosted data. However, in many cases you want to link your agent not only to your data but also to related information from the wider world. For example, an agent powering an ecommerce service could use Web IQ and web-based data sources to provide product comparisons. An agent managing stock levels for a product that is weather-sensitive could use Web IQ as a source of weather data, using Bing’s multiple weather feeds and forecasts.

Just as Google Gemini drew on Google Search, Microsoft Copilot began by using Bing search data to provide grounding for consumer chatbots. It’s easy to take a service like Bing and use it with a LLM, as the nearest neighbor search algorithms use semantic vector similarity techniques to find results that look like your query, ranking them according to their proximity to your search terms.

Microsoft has been tuning its search vector index and the underlying technology stack to work with agents, as agents operate much differently than humans searching the web or querying a chatbot. Providing web search capabilities to agents means having to deal with persistent queries, as the agent hunts for the information it needs, refining queries and applying reasoning algorithms to develop the response it needs. LLM inferencing requires quick responses that deliver large amounts of data, working with queries that go far beyond the one-word or two-word requests that are typical of humans.

More than the training weights

Using Web IQ gives you access to up-to-date information, beyond the training data used to build and weight an LLM. Bing’s crawler works within the standards developed by the search engine industry, obeying meta tags and using its own algorithms to crawl regularly updated websites more often. Bing’s crawler ensures that data is both fresh and being used appropriately, with a focus on quality rather than quantity.

Providing access to web data is only part of Web IQ. Microsoft is using Web IQ to host its own models to manage embeddings, ranking, and content extraction, all running on the company’s global hyperscale platform. The intent here is to use only a limited number of models, to keep the system performance high while aiming to deliver accurate results. The Web IQ models are different from those used to deliver search results to humans, as they’re designed to deliver responses that are suitable for LLMs to use for reasoning.

The underlying search system is based on the DiskANN algorithm developed by Microsoft Research, which allows fast search without requiring enormous amounts of in-memory data access. This approach has been extended to manage information retrieval at scale, building on Microsoft’s distributed systems architectures, to support the demands Microsoft is seeing from agent-based systems. At the same time, it must respond to the rapidly changing economics of inference, where token costs now demand the best possible output from the fewest tokens.

To meet those economic demands, the Web IQ platform doesn’t deliver whole documents to querying agents. Whole documents can lead to expensive inference further down the chain, as LLMs process results repeatedly to drive the agent workflow. Instead, Web IQ structures the information retrieved from the underlying search engine data, delivering what Microsoft calls “structured evidence objects” as well as passage-level information from unstructured text documents. This should result in a much higher signal-to-noise ratio than simply querying a search engine, with a focus on delivering information that lets agents work using fewer tokens.

Using Web IQ in your agent code

The API for Web IQ is a standard REST call, delivering a request object to the Web IQ endpoint. Along with your API authorization key, you will send a query, a set of parameters that control the number of results returned, the language and region used, and the maximum size of the responses and the format used. Responses can be returned in text, HTML, or markdown formats, as well as extracted passages that are selected for context. All other options return the full document, so can be more expensive to use. Markdown is an interesting alternative, as it can be used as the basis for giving agents semantic memories.

Results include important contextual and citation information, including web page titles and URLs, as well as data about when the site was last crawled and how stale the underlying information is. This can be used to improve grounding and provide more information that can be included in formatted responses — much in the same way as Bing’s Copilot displays context in the form of footnotes in its responses.

Responses to video searches include text descriptions. If these aren’t provided as part of the original web content, they will be generated by an LLM. The same approach is used for image searches, with both offering the same contextual cues as the web search API. If you don’t care about the type of data being returned, you can choose a “classic search,” which will return text, images, video, and news.

Supporting autonomous agents

Microsoft provides LLM-ready documentation for the Web IQ service, with an llms.txt file and an OpenAPI description. These allow AI tools to discover Web IQ capabilities and include them in workflows as part of autonomous operations, so that agents and other AI applications can implement grounding calls to Web IQ whenever user interactions require them. The API descriptions include errors as well as the structure of a standard 200 response.

As Web IQ is designed for use by modern agent frameworks, the Web IQ API is available through an MCP server. The Web IQ MCP server exposes tools that map to API calls: web, videos, news, and images. They also include a browse option, which lets you pull content from a target URL. The service can be configured with a standard JSON file and requires an API key to control access and manage billing. If your account doesn’t have access to a specific tool, then it won’t be available from inside the MCP server.

If you’re building an agent and you want to evaluate the Web IQ MCP server, it can be added to common coding agents, such as the GitHub Copilot CLI. You can then test it out using familiar tools and generate code that can be dropped into applications via your choice of development tooling. Queries sent to the Web IQ MCP server use the same syntax as REST calls, without having to construct the calls yourself. Working with the MCP server allows you to connect Web IQ to your choice of agent framework, relying on its built-in MCP methods to reduce the code and maintenance overhead.

Web IQ is not for human interactions; Microsoft provides an alternative “Grounding with Bing” service for chatbots. Instead, Web IQ is a tool for agents, providing necessary background information that helps keep results fresh and relevant. It’s easy to use, fast, and, above all, cheap, which makes it an ideal tool for modern inference platforms built around Microsoft Azure’s AI tooling.

Agents have turned up just about everywhere in software this past year, with one conspicuous exception: data. That’s a little odd, because querying data is exactly the kind of structured, checkable task that agents excel at. The likeliest culprit is timing. Large language models have only been reliably good at writing SQL for the last six to nine months, and the field hasn’t caught up to what that unlocks. It’s worth separating two flavors of the idea: agents that do analytics, and agents that help you run the data plumbing. Both turn out to be more useful than they first look.

Data engineering is hard mostly because you’re at the mercy of systems you don’t control. Schemas change without warning. Sources go offline. The API you pull from ships a new version. A column that only ever holds integers starts returning decimals. A field you assumed was unique sprouts duplicates, and the next join detonates into a Cartesian explosion. Records go missing, or come back wrong for an hour and then quietly fix themselves. If nothing ever changed, data engineering would be easy. But as they say, the only constant is change.

The boring work is where agents thrive

Unglamorous maintenance is something agents are genuinely good at. Every data model is a stack of assumptions: this is unique, that’s always populated, these two tables join cleanly. An agent can read those assumptions out of your code and turn them into tests that check whether they still hold. A lot of the fixes are mechanical anyway: a table got renamed, a type got widened, a column moved. An agent can often patch those on its own, and when it can’t, it can still do the legwork, tracing what changed and handing a human a diagnosis and a proposed fix instead of just a 3am stack trace.

Context is the other half of the story, and the context landscape is honestly a mess. Vendors are working hard to convince you that only their semantic modeling language can save you, while it is not entirely clear whether these are necessary or even sufficient. Whether you keep your business logic in a semantic layer like MetricFlow or Malloy, or just in plain Markdown, the goal is the same: get that logic into a form an LLM can use. Context is almost always created by hand, and like all hand-written documentation, it starts drifting the moment it gets written down.

This highlights an opportunity, namely that agents are good at precisely the parts of context that are mechanical and bad at precisely the parts that aren’t. An agent can infer which tables join to which, what values a column tends to hold, what your sales regions are, and which tables people actually query. What it can’t infer is the stuff that was never really a data question: the right way to calculate revenue, what counts as a “customer,” when the fiscal year starts. Those aren’t facts hiding in the warehouse waiting to be found. They’re decisions, often business ones, that a person has to make. What an agent can do is flag the moment one of them quietly stops being true.

Automated agent insights remain a fantasy

The flashier pitch, where agents surface insights you never asked for, is the one I’d bet on last. It sounds wonderful to have hands-free analytics. An agent will keep watch over your data, notice what matters, and drop a dashboard tailored to whatever is happening today. But the bar is high for relevance and false positives can make human users lose confidence.

Deterministic alerting systems have the same problem. People end up turning off alarms because they are too hard to tune. But if humans writing pre-canned triggers have a hard time getting it right, it is going to be hard for agents to do better (at least not before we get some form of super-intelligence). While I’d expect proactive insights to be part of the future, they are still a research prototype at this point.

Here are three concrete things a data team should do to get their stack ready for agents:

1. Lay the groundwork first. Agent use cases that are compelling sit on top of groundwork most teams haven’t laid yet. You don’t need an agent to curate your context until you’ve decided how your context is going to work in the first place.
2. Then go after context. Write a handful of evals, automate them, and then wait to see what breaks. Evals are the load-bearing part. They’re what makes it safe to let an agent near your pipeline at all, because they tell you the instant it gets something wrong.
3. Run on infrastructure that fits how agents behave. An agent goes from zero to a flood of queries in an instant, so you want something that scales up and back down quickly. Agents also fan out, chasing several threads at once, so you need both the headroom and the tenant isolation to absorb a burst. One agent’s curiosity shouldn’t take down everyone else’s ability to run queries.

Latency is a bigger deal than it looks

Latency matters more than you’d expect when you’re using agents. While you might be waiting seconds or minutes for Claude Code to do its thing, it is often running a bunch of tasks. Part of the time that the agent spends is waiting for the LLM, but an increasing amount of time is using other tools, like querying a database. Over time, you can expect LLMs to get a lot faster; you can use smaller models, smarter models, local models, or fancier GPUs. As that happens the tools that an agent uses become the bottleneck.

Picture two engines: one answers in 10 milliseconds, the other in 100. A person won’t notice the difference because both feel near instantaneous, and a person will spend far longer thinking up the next question than either engine spends answering it. What feels instantaneous to an agent is very different, and it doesn’t need to stop and think. When its next query depends on the last result, that 10x gap compounds straight into 10x more work per minute.

One of the ways to make an agent go faster is to take more of their work and run it in parallel. But this also increases load on the systems. You’d want to make sure you have enough parallel capacity and isolation to be able to scale to all of the parallel agent queries at once. Engines tuned for human patience and engines tuned for agent throughput are not the same engines.

The agentic wave is coming whether or not any given team is ready, and the best time to start preparing yourself and your stack is now, before the queries start pouring in. This isn’t just future proofing. The teams that move early are the ones who work out the patterns everyone else ends up copying. A little curiosity now buys a real head start later.

—

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.

The race to adopt AI has left many CIOs wrestling with a fundamental question: How do you move faster without introducing unacceptable risk?

Few leaders face that challenge at a higher level than David Burns, CIO of GE Aerospace. Building on the company’s decade of experience applying AI across its business, Burns is helping lead the next phase of the company’s digital transformation by leveraging AI to simplify and automate processes. Burns’ experience shows how AI can accelerate innovation, improve decision-making, and create value for the business and customers while maintaining the trust, safety, and operational rigor expected in the aerospace industry.

In a recent episode of the Tech Whisperers podcast, Burns opened up his playbook for leading organizations through turbulence. In this conversation, edited for length and clarity, he shares more practical lessons for technology leaders who are seeking to move beyond experimentation and scale AI responsibly across the enterprise.

Dan Roberts: You’ve described AI as an accelerator. What exactly is AI accelerating inside GE Aerospace?

David Burns: At GE Aerospace, AI is used across our operations as an accelerator to Flight Deck, our proprietary lean operating model, and is applied to all key aspects of the business — design, manufacture, sales, and services. We identify and solve problems with Flight Deck and use AI to accelerate our problem-solving in ways we can genuinely feel, enabling us to identify issues earlier, solve problems faster for our customers, and improve how work gets done.

For example, we are also using AI in:

Design: While traditional processes for developing engine design concepts take months of manual work, the GE Aerospace Research Center built a proprietary generative AI application capable of producing hundreds of design concepts. As a result, the team produced the hypersonic ramjet engine design concept that met all regulatory requirements more than 90% faster than before, highlighting how AI is possible in engine design to support engineers bringing new technologies to market faster.

Manufacture: Our team in Indianapolis used an AI coding assistant to automate a part quality inspection workflow, reducing 8 hours of manual measurement data entry for complex parts to just 3 seconds while improving data accuracy and inspection consistency. This has improved both the quality and efficiency for clearing parts to build, which helps drive on-time engine deliveries.

Sales: Based on customer feedback that GE Aerospace’s responses for proposals needed to be faster, the sales team utilized a generative AI tool to synthesize data and produce deal proposals. The tool improved customer response time by more than two weeks for the GEnx team through reduced proposal development cycle time and standardized creation of more comprehensive deal proposals.

Service: When LEAP engine rebuilds faced potential turnaround time (TAT) challenges due to material availability at our Maintenance, Repair and Overhaul (MRO) sites, our team in Lafayette, Indiana, applied AI to help reduce delays for customers. Using Daily & Visual Management, they surfaced material flow challenges and their underlying drivers, leading to a new AI solution that leverages data to predict when and where parts are needed faster to reduce delays for our customers with an approximately six-day turnaround time improvement, 16% increase in on-time material orders, and 15% increase in on-time material delivery.

Ultimately, by leveraging AI, Flight Deck helps us eliminate waste and identify and accelerate the most value-added steps for our customers, be it designing a part faster or responding to a customer request faster. And I would underscore that it’s value through the eyes of our customer. How we define value is not what we internally say; it’s how our customers define value, and how we’re working to be more customer-driven.

GE Aerospace has been investing in analytics, machine learning, and digital capabilities for more than a decade. What advantages does that foundation create as you move into the generative AI era?

We’ve built one of the largest AI patent portfolios in the aviation industry through years of investment and supercomputing through digital technologies, and we continue to do work on our core transactional systems and our data foundations, so that way our data is AI-ready. This has allowed us to build our own AI capabilities and strong talent base. For example, the generative AI app we built to create new propulsion systems design was built in house by GE Aerospace scientists at the GE Aerospace Research Center.

At the same time, our knowledge and familiarity with the landscape has allowed us to make connections with tech companies, including one where we’re using agentic AI in a multi-year partnership to predict demand and identify constraints to enhance production readiness in the Defense business.

We were fortunate to have leaders who were very smart to invest in data scientists 10, 15 years ago, and we’re getting to leverage that talent today. The lesson there is that is you always have to be thinking long term when you’re talking about talent, because you may not know exactly how the world will play out, but making sure you have the best athletes on the field to run the race becomes critically important. For us, some of those investments we did around our people is what’s paying off today.

One of the biggest challenges facing CIOs today is balancing innovation with risk management. How do you approach that balance in an industry where safety, reliability, and trust are non-negotiable?

It’s all about risk tolerance. There are certain areas in our business where we don’t have high risk tolerance, and we’re very methodical and cautious about how we deploy technology into those uses and have very stringent processes that we comply consistently with. In areas that are not safety and quality critical, we are more aggressive in looking at how we can use technology to deliver more for our customers and to make our employees more effective. That’s where we strike the balance, and at the end of the day, it’s about making sure we’re never compromising safety or quality in what we do.

As for the process, we start with Flight Deck and focus AI where it can help solve critical challenges for our customers and with the highest impact to customer outcomes, enhancing safety, quality, delivery, and cost, in that order, to solve problems that matter most and keep fleets flying. ​

We have three guiding principles for safe and responsible AI use: 

• Trust: The data-informing AI must be known, trusted, and reliable. 
• Transparent: The AI must be transparent and repeatable, which means we need to know what is informing an AI model’s insights and actions.
• Human: A human must always be in the loop and make the final decision.    

Our culture of discipline also plays an important role. Our business variation is challenging, so one of the core fundamentals of Flight Deck is standard work. It’s embedded into our culture, and it’s the base expectation that we operate with standards that we’re continuously improving.

Many organizations are struggling to move from AI pilots to enterprise-scale value. What lessons have you learned about successfully scaling AI across a large, complex organization?

AI is a tool that strengthens the capabilities of skilled employees; it is not a substitute for their judgment, experience, or accountability. So we focus on testing and validating AI solutions through pilots before scaling, and look for AI applications that meaningfully change how work gets done.

Early on, when we started doing a lot of our generative AI work, we focused on 14 big problems in the business, and we didn’t let ourselves stray all over the place. We also didn’t look at it as a technology solution. We looked at the process and where technology played into the process, and then we embedded AI into those core processes. So now, it’s not a separate thing where you go do AI. It’s embedded in the workflow of how things get done.

That gave us a foundation to learn and grow from that we’ve now applied. We’re not trying to create popcorn AI solutions all over the place. We’re trying to transform our business processes. In some cases, we’re doing good old process improvement, lean process improvement, eliminating waste, not necessarily a technology play. In other places, we’re applying technology that’s helping to lift us up and accelerate value by embedding it into the way work gets done, with a little bit of burning the boats behind you. You’re not able to do it the old way. You’ve got to use the tools. You’ve got to use the technology, because it’s the best-known way of doing it. The technology becomes part of the standard work.

That’s why one of the biggest lessons in scaling AI is that success starts with the core fundamentals and understanding the problem you’re trying to solve. It’s critical to test and validate AI solutions before they are deployed at scale to ensure they improve how work gets done and become embedded in our workflows. If you do not have strong standard work and transparent and reliable data in place, it becomes difficult to move beyond pilot stage and create repeatable value at scale.

Every day brings a new AI announcement, new model, or new prediction about the future. How do you separate what is truly meaningful from what is simply noise, and what advice would you give other leaders trying to do the same?

First and foremost is starting with the problem being solved, not the solution. If you’ve got a hammer that you want to use, everything starts looking like a nail. The most effective use of AI begins with an understanding of the problem that needs to be solved, then determining whether AI is the right tool to address it.

As far as dealing with distractions, and there are a lot of them right now, it’s important to try a lot of things, but very quickly, and then make decisions on which are the bets you want to make and spend more time and more money on and which are the ones you want to pivot away from. We spend a lot of time doing quick experiments with technology and then having the courage to stop something when it’s not working.

What excites you most about the future intersection of AI, engineering, manufacturing, and aerospace? And what should CIOs be doing today to prepare for that future?

Across aviation, AI is already helping to enhance safety, support more efficient operations, strengthen the resilience of global fleets, and improve the overall passenger experience. That includes GE Aerospace. These benefits come from investing not only in technology, but also in people, capacity, and trusted partnerships. 

They also depend on building mature, fully connected data threads through manufacturing and services that will drive higher value across our operations. The challenge will be ensuring that we enable this data thread across our operations to support AI solutions that will be developed and deployed.

The most important thing is to understand that the role of digital technology and information technology is fundamentally going to change. When I came out of university, the only people that knew how to do software coding were computer scientists or information systems majors. We used to frown upon shadow IT, but the reality is, now everyone coming out of college knows how to do some level of software development, and AI tools are only going to make that easier.

What CIOs need to start doing today is prepare for the future. The big questions they need to answer: How are they going to make sure they’ve got the platforms and the data set up in a way to serve a workforce that is capable of doing true citizen development, able to develop their own applications, their own solutions? How do you govern that from a data perspective, from a data privacy perspective, from a cybersecurity perspective, while not stifling but enabling the innovation of all those smart people that we’re hiring?

While many organizations search for shortcuts to AI success, GE Aerospace’s disciplined investment in data, analytics, talent, and operational excellence sets the company apart. Burns’ experience offers a clear lesson for CIOs: Creating the greatest value from AI requires building the capabilities, culture, and foundations that allow AI to amplify what the organization already does exceptionally well. For more from his leadership playbook, tune in to the Tech Whisperers.

The race to adopt AI has left many CIOs wrestling with a fundamental question: How do you move faster without introducing unacceptable risk?

Few leaders face that challenge at a higher level than David Burns, CIO of GE Aerospace. Building on the company’s decade of experience applying AI across its business, Burns is helping lead the next phase of the company’s digital transformation by leveraging AI to simplify and automate processes. Burns’ experience shows how AI can accelerate innovation, improve decision-making, and create value for the business and customers while maintaining the trust, safety, and operational rigor expected in the aerospace industry.

In a recent episode of the Tech Whisperers podcast, Burns opened up his playbook for leading organizations through turbulence. In this conversation, edited for length and clarity, he shares more practical lessons for technology leaders who are seeking to move beyond experimentation and scale AI responsibly across the enterprise.

Dan Roberts: You’ve described AI as an accelerator. What exactly is AI accelerating inside GE Aerospace?

David Burns: At GE Aerospace, AI is used across our operations as an accelerator to Flight Deck, our proprietary lean operating model, and is applied to all key aspects of the business — design, manufacture, sales, and services. We identify and solve problems with Flight Deck and use AI to accelerate our problem-solving in ways we can genuinely feel, enabling us to identify issues earlier, solve problems faster for our customers, and improve how work gets done.

For example, we are also using AI in:

Design: While traditional processes for developing engine design concepts take months of manual work, the GE Aerospace Research Center built a proprietary generative AI application capable of producing hundreds of design concepts. As a result, the team produced the hypersonic ramjet engine design concept that met all regulatory requirements more than 90% faster than before, highlighting how AI is possible in engine design to support engineers bringing new technologies to market faster.

Manufacture: Our team in Indianapolis used an AI coding assistant to automate a part quality inspection workflow, reducing 8 hours of manual measurement data entry for complex parts to just 3 seconds while improving data accuracy and inspection consistency. This has improved both the quality and efficiency for clearing parts to build, which helps drive on-time engine deliveries.

Sales: Based on customer feedback that GE Aerospace’s responses for proposals needed to be faster, the sales team utilized a generative AI tool to synthesize data and produce deal proposals. The tool improved customer response time by more than two weeks for the GEnx team through reduced proposal development cycle time and standardized creation of more comprehensive deal proposals.

Service: When LEAP engine rebuilds faced potential turnaround time (TAT) challenges due to material availability at our Maintenance, Repair and Overhaul (MRO) sites, our team in Lafayette, Indiana, applied AI to help reduce delays for customers. Using Daily & Visual Management, they surfaced material flow challenges and their underlying drivers, leading to a new AI solution that leverages data to predict when and where parts are needed faster to reduce delays for our customers with an approximately six-day turnaround time improvement, 16% increase in on-time material orders, and 15% increase in on-time material delivery.

Ultimately, by leveraging AI, Flight Deck helps us eliminate waste and identify and accelerate the most value-added steps for our customers, be it designing a part faster or responding to a customer request faster. And I would underscore that it’s value through the eyes of our customer. How we define value is not what we internally say; it’s how our customers define value, and how we’re working to be more customer-driven.

GE Aerospace has been investing in analytics, machine learning, and digital capabilities for more than a decade. What advantages does that foundation create as you move into the generative AI era?

We’ve built one of the largest AI patent portfolios in the aviation industry through years of investment and supercomputing through digital technologies, and we continue to do work on our core transactional systems and our data foundations, so that way our data is AI-ready. This has allowed us to build our own AI capabilities and strong talent base. For example, the generative AI app we built to create new propulsion systems design was built in house by GE Aerospace scientists at the GE Aerospace Research Center.

At the same time, our knowledge and familiarity with the landscape has allowed us to make connections with tech companies, including one where we’re using agentic AI in a multi-year partnership to predict demand and identify constraints to enhance production readiness in the Defense business.

We were fortunate to have leaders who were very smart to invest in data scientists 10, 15 years ago, and we’re getting to leverage that talent today. The lesson there is that is you always have to be thinking long term when you’re talking about talent, because you may not know exactly how the world will play out, but making sure you have the best athletes on the field to run the race becomes critically important. For us, some of those investments we did around our people is what’s paying off today.

One of the biggest challenges facing CIOs today is balancing innovation with risk management. How do you approach that balance in an industry where safety, reliability, and trust are non-negotiable?

It’s all about risk tolerance. There are certain areas in our business where we don’t have high risk tolerance, and we’re very methodical and cautious about how we deploy technology into those uses and have very stringent processes that we comply consistently with. In areas that are not safety and quality critical, we are more aggressive in looking at how we can use technology to deliver more for our customers and to make our employees more effective. That’s where we strike the balance, and at the end of the day, it’s about making sure we’re never compromising safety or quality in what we do.

As for the process, we start with Flight Deck and focus AI where it can help solve critical challenges for our customers and with the highest impact to customer outcomes, enhancing safety, quality, delivery, and cost, in that order, to solve problems that matter most and keep fleets flying. ​

We have three guiding principles for safe and responsible AI use: 

• Trust: The data-informing AI must be known, trusted, and reliable. 
• Transparent: The AI must be transparent and repeatable, which means we need to know what is informing an AI model’s insights and actions.
• Human: A human must always be in the loop and make the final decision.    

Our culture of discipline also plays an important role. Our business variation is challenging, so one of the core fundamentals of Flight Deck is standard work. It’s embedded into our culture, and it’s the base expectation that we operate with standards that we’re continuously improving.

Many organizations are struggling to move from AI pilots to enterprise-scale value. What lessons have you learned about successfully scaling AI across a large, complex organization?

AI is a tool that strengthens the capabilities of skilled employees; it is not a substitute for their judgment, experience, or accountability. So we focus on testing and validating AI solutions through pilots before scaling, and look for AI applications that meaningfully change how work gets done.

Early on, when we started doing a lot of our generative AI work, we focused on 14 big problems in the business, and we didn’t let ourselves stray all over the place. We also didn’t look at it as a technology solution. We looked at the process and where technology played into the process, and then we embedded AI into those core processes. So now, it’s not a separate thing where you go do AI. It’s embedded in the workflow of how things get done.

That gave us a foundation to learn and grow from that we’ve now applied. We’re not trying to create popcorn AI solutions all over the place. We’re trying to transform our business processes. In some cases, we’re doing good old process improvement, lean process improvement, eliminating waste, not necessarily a technology play. In other places, we’re applying technology that’s helping to lift us up and accelerate value by embedding it into the way work gets done, with a little bit of burning the boats behind you. You’re not able to do it the old way. You’ve got to use the tools. You’ve got to use the technology, because it’s the best-known way of doing it. The technology becomes part of the standard work.

That’s why one of the biggest lessons in scaling AI is that success starts with the core fundamentals and understanding the problem you’re trying to solve. It’s critical to test and validate AI solutions before they are deployed at scale to ensure they improve how work gets done and become embedded in our workflows. If you do not have strong standard work and transparent and reliable data in place, it becomes difficult to move beyond pilot stage and create repeatable value at scale.

Every day brings a new AI announcement, new model, or new prediction about the future. How do you separate what is truly meaningful from what is simply noise, and what advice would you give other leaders trying to do the same?

First and foremost is starting with the problem being solved, not the solution. If you’ve got a hammer that you want to use, everything starts looking like a nail. The most effective use of AI begins with an understanding of the problem that needs to be solved, then determining whether AI is the right tool to address it.

As far as dealing with distractions, and there are a lot of them right now, it’s important to try a lot of things, but very quickly, and then make decisions on which are the bets you want to make and spend more time and more money on and which are the ones you want to pivot away from. We spend a lot of time doing quick experiments with technology and then having the courage to stop something when it’s not working.

What excites you most about the future intersection of AI, engineering, manufacturing, and aerospace? And what should CIOs be doing today to prepare for that future?

Across aviation, AI is already helping to enhance safety, support more efficient operations, strengthen the resilience of global fleets, and improve the overall passenger experience. That includes GE Aerospace. These benefits come from investing not only in technology, but also in people, capacity, and trusted partnerships. 

They also depend on building mature, fully connected data threads through manufacturing and services that will drive higher value across our operations. The challenge will be ensuring that we enable this data thread across our operations to support AI solutions that will be developed and deployed.

The most important thing is to understand that the role of digital technology and information technology is fundamentally going to change. When I came out of university, the only people that knew how to do software coding were computer scientists or information systems majors. We used to frown upon shadow IT, but the reality is, now everyone coming out of college knows how to do some level of software development, and AI tools are only going to make that easier.

What CIOs need to start doing today is prepare for the future. The big questions they need to answer: How are they going to make sure they’ve got the platforms and the data set up in a way to serve a workforce that is capable of doing true citizen development, able to develop their own applications, their own solutions? How do you govern that from a data perspective, from a data privacy perspective, from a cybersecurity perspective, while not stifling but enabling the innovation of all those smart people that we’re hiring?

While many organizations search for shortcuts to AI success, GE Aerospace’s disciplined investment in data, analytics, talent, and operational excellence sets the company apart. Burns’ experience offers a clear lesson for CIOs: Creating the greatest value from AI requires building the capabilities, culture, and foundations that allow AI to amplify what the organization already does exceptionally well. For more from his leadership playbook, tune in to the Tech Whisperers.

Die Normen der Softwareentwicklung sind weiterhin gültig. Zumindest offiziell sind robuste CI/CD-Pipelines, elegante Architekturmuster und wartbarer Code nach wie vor gesetzt.

Wenn wir unbeobachtet sind, zeigt sich dann in vielen Fällen die Realität: Wir hängen wie entrückte Magier mit manischem Glanz in den Augen über unseren Konsolen und beschwören Modelle und Agenten, um uns voll und ganz dem KI-Rausch hinzugeben.

Dabei begehen wir nicht selten Development-Sünden, die Fred Brooks die Schamesröte ins Gesicht getrieben hätten. So wie die folgenden sieben. Vorsicht, Ironie – stellenweise.

1. Grundlagenwissen für überflüssig halten

Objektorientierte oder funktionale Programmierung? CAP-Theorem? DRY-Prinzip? Design-Pattern? Können Sie vergessen. Ebenso Frameworks, Runtimes und Deployment-Plattformen.

Die KI weiß schließlich ganz genau, was bereits vorhanden ist und welche Tools zu nutzen sind. So haben wir als Entwickler auch mehr mentale Bandbreite, um uns Nebenprojekten zu widmen. Zum Beispiel einem Roman über die KI-Weltherrschaft.

2. Dokumentationen links liegen lassen

„RTFM“ nutzen viele Developer auch heutzutage noch gerne – auch wenn sie selbst eigentlich seit 2023 keine einzige Seite einer Anbieter-Dokumentation mehr gelesen haben. Löst ein Package eine bizarre Exception aus, wird weder der Execution-Pfad überprüft noch erfolgt ein Blick in die Release Notes. Stattdessen werden alle 200 Zeilen des Stack-Trace kopiert und in eine KI geworfen – in der Erwartung, dass diese uns dann löffelweise mit der Lösung füttert.

Oder es wird direkt eine ADE auf den Fehler angesetzt. Die findet den Fehler und fragt uns dann nur noch, ob die Lösung so korrekt ist. Manche werfen dann eventuell einen Blick auf die Beschreibung dieser Lösung – insofern sie die KI nicht vorher schon auf „Auto-Confirm“ umgestellt haben.

So werden wir zu glorifizierten Copy-Paste-Orchestratoren – die einfach nur darauf hoffen, dass der stochastische Papagei hinter dem Prompt die Syntax richtig errät.

3. Backend-Struktur ignorieren

KI-berauschte Devs geben manchmal vor, Datenflüsse akribisch designt, relationale Einschränkungen sorgfältig ausgearbeitet und API-Beziehungsgeflechte gewissenhaft abgebildet zu haben. Auch wenn wir eigentlich nur die KI angewiesen haben, ein modernes Deployment-Gerüst zu bauen und dieses mit einer Backend-Datenbank zu verknüpfen.   

Dabei wurden Security-Regeln und Schemata erstellt, die wir unter Umständen nicht vollständig verstehen. Aber solange es funktional aussieht, wird es schon gut gehen. Eventuell wurden auch Infrastructure-as-Code-Skripte generiert, die Cloud-Ressourcen bereitstellen. Sicher wird sich jemand anderes darum kümmern, dass das kein Loch ins Budget frisst. Wahrscheinlich, indem er die Metriken in einen anderen Chatbot einspeist.

Ist aber auch egal, weil das Mittagessen wartet.

4. Inzestuöses Testing fördern

Test-driven Development war immer schon ein schöner Traum, der – wenn man ihn lebt – in Dependency-Wildwuchs ausarten kann. Es ist also eine super Sache, dass wir heutzutage mit KI fast mühelos eine Testabdeckung von 95 Prozent erreichen können. Warum sollten wir die Maschine das nicht direkt mit übernehmen lassen, wenn sie auch alles andere automatisiert erstellt?

So kann man auch jedem der es wissen will (oder der gerade keine Fluchtmöglichkeit hat), das Narrativ von der erstaunlichen Testabdeckung unter die Nase reiben und sich in ausgiebigen Schwärmereien über die automatisierte Qualitätssicherung ergehen. Was dabei geflissentlich verschwiegen wird: Die komplexe Anwendungslogik und die Testsuite wurden von derselben KI generiert. Diese validiert also genau den Code, den sie zuvor zusammengeschustert hat.

Daraus entsteht ein hermetisch abgeriegelter Kreislauf der algorithmischen Selbstbeweihräucherung: Die Mocks, Randfälle und Assertions werden zur Echokammer für die ursprünglichen Annahmen des KI-Modells. Die Maschine benotet also ihre eigenen Hausaufgaben und gibt sich dafür eine Eins mit Sternchen.

Das wird von einigen von uns allerdings gerne in Kauf genommen, denn wenn der Code verändert werden muss, zaubert die KI auch dafür mühelos neue Tests aus dem Hut.

5. KI-Ergebnisse als Strategie ausgeben

Dokumente zu designen, kann KI erstaunlich gut: Diese sind meist apart formatiert, wirken schlüssig und schlagen nahtlos die Brücke zwischen übergeordneten Geschäftszielen und detaillierten technischen Specs. Und: Sie enthalten auch die tollen Sequenz-Diagramme, die das Management so schätzt.

Architekturvorschläge, die auf diese Art und Weise entstanden sind, werden regelmäßig in Sprint-Planungs-Meetings präsentiert – und kommen beim Rest des Teams oft gut an. Schließlich weiß auch niemand, dass in den hochgelobten Vorschlag ungefähr vier Sekunden „Mühe“ investiert wurden.

Ignoriert wird dabei, dass solche KI-generierten Dokumente gleichermaßen anfällig für fatale Mängel in Bezug auf Scope und Alignment sind, wie von Menschenhand gemachte. Aber wenn das Projekt schon scheitert, war wenigstens das Markdown schön klar und die Bulletpoints echt überzeugend. Das wahre Ausmaß des folgenden Desasters wird zwar erst erkannt, wenn es schon viel zu spät ist – aber immerhin war der Ansatz visionär.

6. Heimlich dem Vibe Coding verfallen

Vibe Coding ist unter Devs in sozialen Kanälen regelmäßig eine Lachnummer. Und auch in Slack-Channels werden regelmäßige augenrollende Emojis verschickt, wenn es um das Thema geht. Nach außen möchten wir alle möglichst professionell wirken.

Wenn niemand zusieht, wird dann unter Umständen aber doch der heimlichen Vibe-Coding-Leidenschaft gefröhnt: Unausgereifte Gedanken und ein Drink, sind alles was man braucht, um entspannt dabei zusehen zu können, wie die KI ihre “Coding-Magie” entfaltet.

Daraus entsteht dann vielleicht endlich ein funktionierender Ultima-V-Klon oder eine App, um Krypto-Protfolios zu tracken, die nach dem Interface aus „Neuromancer“ aussieht. Und zwar in 30 Sekunden. Das berauscht. Und kann süchtig machen. Leider ganz besonders, wenn man tief in der harten, altmodischen Realität des Programmierhandwerks verwurzelt ist.

7. Prompts als Allheilmittel betrachten

Ahnlich wie die Figur von Adam Sandler in „Der schwarze Diamant“ sind manche Devs davon überzeugt, dass mit der nächsten Runde alles besser wird – nur bezogen auf Prompts. Wenn die Dinge aus dem Ruder laufen, bevorzugen diese regelmäßig, den KI-Prompt zu verfeinern – statt sich selbst dem Komplexitätsdickicht zu widmen.

Der gleiche fehlerbehaftete Stack Trace wird dann unerbittlich immer und immer wieder in den Chat gehämmert, das Modell auf einen immer schmaleren Pfad gezwungen – solange, bis der Code endlich keine Fehler mehr ausgibt. Debugging und Variablen-Tracing sind so gut wie nicht mehr existent, Funktionen werden nicht mehr schrittweise geprüft. Stattdessen wird unermüdlich iterativer Druck auf die KI ausgeübt, bis diese kapituliert. Und dann geht’s ab in die Produktion.

So fließt am Ende ähnlich viel Zeit und Energie in den Kampf mit dem Bot, wie früher in die manuelle Syntaxerstellung. (fm)

Dieser Artikel ist im Original bei unserer Schwesterpublikation Infoworld.com erschienen.

Ein Freelance-Entwickler präsentiert sich mit tadellosem Lebenslauf, sauberem Portfolio und überzeugendem Video-Interview. Trotzdem sitzt am anderen Ende kein einzelner Kandidat, sondern ein Glied in einem staatlich gelenkten Betrugsnetzwerk. Was nach Spionagefilm klingt, hat sich zu einem konkreten Insider-Risiko für Unternehmen entwickelt.

Seit Jahren schleusen nordkoreanische Netzwerke IT-Fachkräfte mit falschen, gestohlenen oder geliehenen Identitäten in westliche Unternehmen ein, meist als Remote-Freelancer für Softwareentwicklung, Datenbanken, Cloud-Administration oder App-Projekte. Behörden sprechen von Tausenden weltweit eingesetzten Arbeitskräften.

Wie groß einzelne Netzwerke werden können, zeigen inzwischen abgeschlossene Strafverfahren: In einem Fall wurden 309 US-Unternehmen und zwei internationale Firmen getäuscht; das Netzwerk erwirtschaftete mehr als 17 Millionen US-Dollar. Im April 2026 wurden zwei weitere Helfer verurteilt, deren Struktur mit gestohlenen Identitäten Jobs bei mehr als 100 Unternehmen erlangte und über fünf Millionen US-Dollar einnahm.

Für CIOs ist das kein akademisches Risiko. Wer regulär eingestellt wurde, erhält reguläre Zugangsdaten und damit unter Umständen Zugriff auf Quellcode, Kundendaten, Entwicklungsumgebungen oder interne Wissensbestände. Genau das macht den Fall gefährlich: Technisch sieht der Zugriff zunächst legitim aus, obwohl Identität, Standort und Zweck der Tätigkeit falsch sein können.

Wie das Schema funktioniert

Die Struktur ist arbeitsteilig. IT-Fachkräfte übernehmen die eigentliche Projektarbeit. Rekruter suchen passende Stellen, Mittelsleute beschaffen Identitäten und Konten, andere Personen treten in Interviews auf oder wickeln Verträge und Zahlungen ab. Hinzu kommen lokale Helfer, die Firmenhardware entgegennehmen. Ein Unternehmen kann daher im Bewerbungsgespräch, beim Versand des Laptops und während der täglichen Zusammenarbeit jeweils mit einer anderen Person oder Rolle aus demselben Netzwerk interagieren.

Eine Schlüsselrolle spielen sogenannte Laptop Farms. Firmenrechner stehen physisch im Land des vermeintlichen Mitarbeiters, werden aber über Fernwartungssoftware oder KVM-Technik (Kernel-based Virtual Machine) aus dem Ausland bedient. Für einfache Standortkontrollen wirkt der Zugriff damit lokal. Gleichzeitig helfen Scheinfirmen, Zahlungsaccounts, Profile auf Jobplattformen und professionell gestaltete Portfolios dabei, die erfundene Biografie konsistent erscheinen zu lassen.

Generative KI erhöht die Qualität und Geschwindigkeit dieser Täuschung. Microsoft hat unter anderem KI-bearbeitete Profilbilder, verbesserte Bewerbungsunterlagen und den Einsatz von Stimmveränderungssoftware beobachtet. Ein fehlerfreier Lebenslauf oder ein plausibles Profil ist deshalb kein belastbarer Identitätsnachweis mehr.

Warum klassische Prüfungen zu kurz greifen

Ein einmaliger, dokumentenbasierter Background-Check kann bei dieser Betrugsform ins Leere laufen. Er bestätigt im besten Fall, dass die vorgelegten Daten zu einer realen Identität passen. Der Check beantwortet aber nicht automatisch, ob diese Identität der Person im Interview gehört, ob später dieselbe Person arbeitet oder ob dieselben Kontaktdaten bereits in anderen Bewerbungen aufgetaucht sind. Identitätsprüfung muss deshalb als Prozess gedacht werden: vom Recruiting über das Onboarding bis zu risikobasierten Kontrollen während der Beschäftigung.

Zusätzliche Blindstellen entstehen bei externen Entwicklern und Personaldienstleistern. Wer das Recruiting an einen Dritten auslagert, gibt damit nicht die Verantwortung für den Systemzugang ab. Unternehmen sollten vertraglich und operativ sicherstellen, dass Dienstleister vergleichbare Prüfstandards anwenden und relevante Auffälligkeiten melden.

Warnsignale im Bewerbungsprozess

Behörden und Sicherheitsforscher beschreiben wiederkehrende Muster. Kein einzelnes Merkmal beweist einen Betrug; entscheidend ist die Kombination mehrerer voneinander unabhängiger Signale:

• Kontaktdaten, hier besonders VoIP-Nummern, E-Mail-Adressen oder Zahlungsinformationen, tauchen bei mehreren angeblich unabhängigen Bewerbungen identisch auf.
• Lebenslauf, Portfolio und öffentliches Profil passen zeitlich oder inhaltlich nicht zusammen; ganze Textpassagen oder Arbeitsproben finden sich bei anderen Personen wieder.
• Der Kandidat weicht einem stabilen Video-Interview aus, Bild und Stimme wirken wiederholt asynchron oder die Person im späteren Arbeitsalltag unterscheidet sich auffällig vom Interview.
• Antworten zum aktuellen Standort, zu Ausbildung oder früheren Projekten bleiben trotz fachlicher Nachfragen ungewöhnlich vage oder widersprüchlich.
• Kurz vor oder nach Vertragsstart ändern sich Lieferadresse, Bankverbindung oder Zahlungsplattform; Hardware soll an eine andere als die verifizierte Adresse gehen.
• Der Kandidat drängt auf einen sehr schnellen Start, fordert weitreichende Rechte vor Abschluss der Prüfungen oder bevorzugt ungewöhnliche Zahlungswege.

Warnsignale nach dem ersten Arbeitstag

Mit der Einstellung endet die Prüfung nicht. Technische Indikatoren können zeigen, dass der Firmenrechner nur als Zwischenstation dient oder dass mehrere Personen ein Konto nutzen:

• Mehrere Anmeldungen desselben Kontos aus weit auseinanderliegenden Ländern oder IP-Bereichen innerhalb kurzer Zeit.
• Nicht genehmigte Fernwartungs- oder Remote-Desktop-Software, auffällige KVM-Geräte sowie Versuche, lokale Administratorrechte zu erhalten.
• Ungewöhnliche Browser-Sitzungen, wechselnde Gerätefingerabdrücke oder Arbeitsaktivität, die dauerhaft nicht zum angegebenen Standort und zur Zeitzone passt.
• Großflächiges Kopieren von Quellcode oder Dokumenten in private Cloudspeicher, persönliche Repositories oder nicht freigegebene Filesharing-Dienste.
• Mehrere parallele Audio- oder Videoverbindungen und wiederkehrende Probleme, die darauf hindeuten, dass Meetings durch Dritte unterstützt werden.

Auch hier gilt: VPN-Nutzung, Remote-Tools oder ein ungewöhnlicher Arbeitsrhythmus sind für sich genommen kein Beweis. Sie werden erst im Zusammenhang mit Auffälligkeiten aus Recruiting, Hardwareversand und Zahlungsdaten aussagekräftig.

Warum der Schaden weit über das Gehalt hinausgeht

Die erste Motivation ist häufig die Einnahme regulärer Gehälter. Doch aus dem legitimen Zugang kann ein zweites Geschäftsmodell entstehen. Das FBI warnt vor dem Abfluss proprietärer Daten und Quellcode sowie vor Erpressung nach der Enttarnung.

Hinzu kommen Kosten für Forensik, Rechtsberatung, Wiederherstellung von Systemen und mögliche Meldepflichten. Bei sensiblen Technologien können außerdem Exportkontrollen, Sanktionen und vertragliche Geheimhaltungspflichten berührt sein.

Was CIOs konkret tun können

Wirksam ist kein einzelnes Tool, sondern ein Kontrollmodell, das HR, IT, Security, Einkauf und Compliance verbindet. Fünf Maßnahmen reduzieren das Risiko deutlich:

• Rollen nach Risiko staffeln. Für Tätigkeiten mit Zugriff auf Quellcode, Produktionssysteme, Forschungsdaten oder privilegierte Konten gelten stärkere Prüf- und Freigabeschritte als für risikoarme Rollen.
• Identität mehrfach verifizieren. Dokumente, Kontaktangaben, Ausbildung und frühere Beschäftigung werden über unabhängige Quellen geprüft. Bei Remote-Rollen sollte die Identität beim Interview, beim Onboarding und bei begründetem Anlass erneut bestätigt werden.
• Hardware und Zahlungen kontrollieren. Firmenrechner gehen nur an die verifizierte Adresse. Änderungen von Lieferort, Bankverbindung oder Zahlungsplattform lösen eine erneute Prüfung aus. Systemzugänge werden erst nach Abschluss der vorgesehenen Kontrollen freigeschaltet.
• Least Privilege technisch durchsetzen. Neue Mitarbeitende erhalten zunächst nur die Rechte, die sie tatsächlich benötigen. Nicht freigegebene Fernwartungssoftware wird blockiert; Identitäts-, Endpoint- und Cloud-Logs werden risikobasiert auf ungewöhnliche Muster geprüft.
• Dienstleister und Eskalation einbeziehen. Für Freelancer und Staffing-Partner gelten dieselben Mindeststandards. Ein gemeinsamer Eskalationsweg legt fest, wer bei Auffälligkeiten entscheidet, Beweise sichert und Zugriffe begrenzt.

Für Unternehmen in Deutschland, Österreich und der Schweiz muss dieses Vorgehen verhältnismäßig und datenschutzkonform ausgestaltet sein. Ziel ist nicht die möglichst umfassende Sammlung von Personendaten, sondern die nachvollziehbare Prüfung relevanter Risiken für eine konkrete Rolle, mit klaren Kriterien, begrenzten Aufbewahrungsfristen und menschlicher Bewertung von Treffern.

Wenn sich der Verdacht erhärtet

Ein Verdachtsfall gehört nicht allein ins Recruiting. HR, Security, Legal beziehungsweise Datenschutz und gegebenenfalls Compliance sollten koordiniert vorgehen. Dazu gehören die Sicherung relevanter Protokolle, die kontrollierte Begrenzung von Zugängen, der Wechsel exponierter Schlüssel oder Tokens und die Prüfung, ob Daten in private Repositories oder Cloudkonten abgeflossen sind.

Welche Behörden oder Vertragspartner informiert werden müssen, hängt vom Sitz des Unternehmens, den betroffenen Daten und regulatorischen Pflichten ab. Entscheidend ist ein vorbereiteter Incident-Plan, nicht eine improvisierte Konfrontation.

Wer sensible Systeme oder Daten verantwortet, kommt an dieser Form von Personalrisiko nicht mehr vorbei. Die Fälle zeigen: Cybersicherheit beginnt nicht erst an der Firewall. Sie beginnt dort, wo eine digitale Identität erstmals Vertrauen, Hardware und Zugriffsrechte erhält und sie endet nicht mit dem ersten Arbeitstag. (jd)

Einen peinlichen Moment im Arbeitsleben hat sicher jeder schon einmal erlebt. Vielleicht hat man sich durch eine sehr wichtige Präsentation gestammelt oder auf einer Unternehmensfeier lautstark ein volles Glas umgeworfen und mit der verschütteten Flüssigkeit im schlimmsten Fall auch noch einen Kollegen getroffen. Besonders schwer wiegen peinliche Fehler dann, wenn man den Wunschjob noch nicht einmal in der Tasche hat. Gerade beim Bewerbungsgespräch kommt es darauf an, einen starken ersten Eindruck zu hinterlassen.

Das Online-Karriereportal Careerbuilder hat mehr als 3.000 Arbeitgeber und Personal-Experten sechs häufige Fehler im Bewerbungsgespräch danach bewerten lassen, wie sehr sie dem Kandidaten schaden. Den größten Fehler begehen Kandidaten dann, wenn sie im Gespräch ein Handygespräch annehmen oder eine SMS schreiben, 77 Prozent der Umfrage-Teilnehmer stören sich an diesem Verhalten. Das zweitschlimmste Vergehen ist es, kein Interesse an der ausgeschriebenen Stelle zu zeigen (75 Prozent), das drittschlimmste, sich unangemessen zu kleiden (72 Prozent).

Auf Rang vier der schlimmsten Fehler in Bewerbungsgesprächen liegt arrogantes Auftreten, daran stören sich 72 Prozent der befragten Personal-Experten. 67 Prozent der Personaler stören sich daran, wenn ein Bewerber im Gespräch schlecht über den jetzigen oder über frühere Arbeitgeber spricht. Für 63 Prozent der Umfrageteilnehmer ist es ein schlimmes Vergehen, wenn ein Kandidat im Bewerbungsgespräch Kaugummi kaut.

Darüber hinaus befragte Careerbuilder die Personal-Experten nach ihren ungewöhnlichsten Erlebnissen bei Bewerbungsgesprächen. Die Umfrageteilnehmer berichteten von den folgenden Gesprächssituationen:

• 1. Ein Kandidat brachte einen Bewerbungsratgeber zum Gespräch mit.
• 2. Ein anderer Bewerber fragte: “Wie heißt ihr Unternehmen noch mal?”
• 3. Bei einem Telefoninterview wurde ein Personaler von der Kandidatin in die Warteschleife gestellt. Als die Kandidatin das Gespräch in die Leitung zurückholte, erzählte sie, sie hätte sich in der Zwischenzeit für Freitag für ein Date verabredet.
• 4. Ein Bewerber trug zum Bewerbungsgespräch eine Pfadfinderuniform und erklärte im Laufe des Gesprächs nicht, weshalb er das tat.
• 5. Ein Kandidat sprach während des gesamten Bewerbungsgesprächs von sich in der dritten Person.
• 6. Ein anderer Bewerber zog sich während des Jobinterviews seine Schuhe aus.
• 7. Ein Bewerber fragte, ob er einen Schluck vom Kaffee des Personalers trinken dürfe.
• 8. Und schließlich berichtet ein Personaler von einer Kandidatin, die im Gespräch sagte, sie sei sich nicht sicher, ob der angebotene Job es wert sei, dafür das Auto zu starten.

3 Tipps für ein erfolgreiches Bewerbungsgespräch

“Man mag ja denken, dass ein Bewerber nie und nimmer während eines Jobinterviews einen Anruf annehmen würde, aber wir hören diese Geschichten immer wieder, wenn wir mit Personalern sprechen”, sagt Rosemary Haefner von Careerbuilder. Bei der Masse der Bewerber gehe es jedoch nicht darum, solche Fehler zu vermeiden sondern sich von den anderen Bewerbern abzuheben. Haefner gibt die folgenden Ratschläge für ein erfolgreiches Bewerbungsgespräch:

1. Intensiv vorbereiten: Um auf Fragen zum Unternehmen souverän zu antworten, sollte man sich gut über den Wunscharbeitgeber informieren. Geeignete Quellen dafür sind die Selbstdarstellung auf der Unternehmenswebsite, aktuelle Pressemeldungen und die Vorstellung angebotener Produkte und Dienstleistungen.

2. Optimistisch bleiben: Egal, wie die Stimmung im Bewerbungsgespräch auf einen wirkt. Haefner rät, positiv zu bleiben und auf keinen Fall schlecht über frühere Arbeitgeber zu sprechen.

3. Beispiele und Ideen vorbereiten: Am besten überlegt man sich bereits vor dem Interview Anekdoten, die den eigenen Lebenslauf veranschaulichen und zum Beispiel erläutern, wie man in früheren Jobs mit herausfordernden Situationen umgegangen ist. Auch mit Ideen und Vorschlägen für den Wunschjob kann man aus der Masse der Bewerber hervorstechen.

Das Online-Karriereportal Careerbuilder sprach für diese Umfrage mit mehr als 3.000 Arbeitgebern und Personal-Experten in den USA.

Erzählen Sie mir von einem Vorgang, den Sie für andere dokumentiert haben.

Die Antwort zeigt, wie wichtig dem Bewerber Teamwork ist und ob er sein Wissen anderen zugänglich macht.

Erzählen Sie mir von einem ihrer bisherigen Projekte.

Hier können Bewerber punkten, wenn sie auch auf Herausforderungen, komplexe Aufgaben und Einschränkungen eingehen.

Was könnten Sie mir über Details zur Programmierung von … sagen?

Die soll zeigen, ob ein Kandidat zu einer Wissenslücke steht oder blufft.

Wie würden Sie dieses Thema einem Kollegen erläutern, der kein IT-Experte ist?

Hier kann man zeigen, wieviel einem an einem guten Verhältnis von Business und IT liegt.

Sie können ein Projekt entweder rechtzeitig und unvollständig oder vollständig, jedoch nach der Deadline, abschließen. Wofür entscheiden Sie sich?

Eine gute Antwort wäre zum Beispiel, gemeinsam mit Projektleiter und Team nach der besten Lösung zu suchen.

Modern attacks increasingly begin with the web application.

Customer portals, partner platforms, APIs, external business applications, and AI-powered services have become the front door to the enterprise. The systems organizations build to create value are now the same systems attackers target for initial access.

For years, security teams have invested heavily in protecting networks, endpoints, identities, and cloud infrastructure. Those investments remain essential, but the way attackers gain initial access has changed. Business-critical applications are internet-facing, constantly evolving, deeply connected to enterprise systems, and often changing faster than organizations can continuously validate them.

Artificial intelligence is accelerating this shift. The time between vulnerability discovery and exploitation continues to shrink, allowing attackers to identify and weaponize weaknesses at machine speed. Yet while attacks have evolved, much of security validation still reflects yesterday’s architecture.

That shift is exactly why we built NodeZero WebApp, extending autonomous attack validation to where modern attacks increasingly begin.

Validation still reflects yesterday’s architecture

Most organizations still organize security by technology. Application security teams test web applications. Identity teams validate authentication and access controls. Cloud teams secure cloud infrastructure, while infrastructure teams assess networks and endpoints. Each discipline performs valuable work.

The problem is that attackers don’t organize themselves the same way. They move across technologies, chaining weaknesses together until they reach their objective. A vulnerable application becomes compromised credentials. Compromised credentials become identity abuse. Identity abuse becomes access to cloud resources, infrastructure, and eventually the business systems they were after all along.

Taken together, this means security validation often stops where the next stage of the attack begins.

Attack paths don’t stop at the web application

A SQL injection isn’t the outcome. It’s the beginning of an attack path. An authentication weakness isn’t the breach. It’s simply the first opportunity to move deeper into the environment.

The question isn’t whether a vulnerability exists. Security teams already have plenty of ways to answer that. The real question is what an attacker can do after exploiting it.

Can they compromise identities? Reach sensitive data? Pivot into cloud resources? Move laterally into critical business systems?

Security teams don’t lose because they missed a vulnerability. They lose because they never validated where it could lead. Modern attacks don’t unfold within a single technology stack. They move across applications, identities, infrastructure, and cloud environments until they create business impact. Security validation has to reflect that reality.

Security validation has to change

For years, organizations validated individual technologies because that’s how enterprise environments were built. That approach made sense when applications, identities, infrastructure, and cloud platforms operated more independently and attackers moved more slowly.

Today’s attacks don’t respect those boundaries. Validation shouldn’t either.

It has to begin where attackers begin and continue until business impact is understood.

Asking the right question

Many security tools begin with privileged knowledge. They analyze source code, configuration files, or other internal artifacts before identifying weaknesses. Those approaches answer important questions during software development and secure coding, and they remain an important part of building secure software.

Attackers begin with what they can reach, interacting with an application as it exists in production, scouring exposed source code looking for novel vulnerabilities and stored identities, authenticating when they can, observing how it behaves, and looking for opportunities to move deeper into the environment. Every decision is driven by what the application reveals, not what its developers intended.

Security validation should begin with the same perspective an attacker has, and answer the same question every attacker is trying to answer:

What can I actually reach from here?

That shift changes more than where testing starts. It fundamentally changes what security teams learn from the exercise.

src="https://b2b-contenthub.com/wp-content/uploads/2026/08/configurationimages.png" alt="horizon3">Security validation shouldn’t stop at anonymous pages. NodeZero WebApp safely validates authenticated application workflows, helping organizations assess the same privileged experiences attackers seek after gaining initial access.

Click here to discover how NodeZero WebApp addresses modern attacks.

See NodeZero WebApp in action

Modern attacks start with web applications — but they rarely end there. Join our live webinar to see how NodeZero WebApp safely validates real attack paths from authenticated applications into identity, cloud, and infrastructure, helping you understand the business impact of exploitable weaknesses before attackers do.

Register for our webinar

The memory crisis is getting worse for Apple, which is struggling to get enough memory chips together for its upcoming iPhone 18 Pro series smartphones. That’s according to tech journalist Tim Culpan.

As he details it, Apple and its assembly partners are still attempting to secure sufficient quantities of memory, and though they’re confident they can meet initial demand once the devices are introduced, they apparently remain concerned that wait times could rapidly extend as retail inventory evaporates.

Apple’s manufacturing process compounds the problem. The A20 processor is packaged with memory using a new TSMC process, meaning processors are reportedly piling up while manufacturers wait for memory chips. You should read Culpan’s report to get the full picture.

What’s the frequency?

You don’t need to read between the lines to see the challenge. Despite demand for TSMC’s new processors, Apple seems to have been able to secure the supply it needs. But when it comes to churning out the final packaged chips memory, supply constraints have created significant obstacles to producing in quantity.

This is bad for Apple, particularly as the challenge doesn’t appear to be confined to iPhones; customers are experiencing delays getting new Macs. “Many new orders are now not arriving until September,” Bloomberg’s Mark Gurman wrote earlier this week. 

It isn’t just Apple that will be impacted by the AI-driven memory drought. The scale of Apple’s orders is among the greatest in the industry, and if its product plans are feeling the pain, every other manufacturer will be feeling it as well.

Conscious uncoupling

This is certainly in tune with expectations voiced at the beginning of the year when Ranjit Atwal, senior director analyst at Gartner, warned: “This is the steepest contraction in device shipments witnessed in over a decade. Higher prices will narrow the range of devices available, prompting buyers to hold on to devices for longer, fundamentally altering upgrade cycles.”

Gartner in February predicted a 10.4% decline in global PC shipments and an 8.4% drop in smartphone shipments as a result. The analyst also predicted a 130% surge in combined memory and SSD storage prices by the end of this year, with steep product price increases to follow. Recent data from IDC, Gartner, Counterpoint, and Omdia confirm PC market declines, but only at around 4% (the estimates vary).

Today’s report from Culpan suggests we’ve not yet experienced the full extent of this decline — hinting that while the initial fall reflected price, the next impact will be defined by lack of supply. While this hurts big brands like Apple, smaller entities could be left high and dry. 

When the chips are down

It is interesting to reprise Atwal’s warning in February that, “the sub-$500 entry-level PC segment will disappear by 2028,” as this seems to be what’s happening. That’s something long-time Mac users like me find particularly ironic, given it was only this year Apple briefly offered up its superbly priced $499 MacBook Neo. The industry direction we’re seeing now suggests we’ll never see that again, though the success of that device gave Apple a phenomenal 28.7% increase in sales in its just-revealed June quarter.

Despite memory supply challenges, Apple seems to be faring fairly well, with market share increasing across its business. Counterpoint data reveals that Apple has achieved an astonishing 65% share of the premium smartphone market. In part, that’s because as an existing premium brand, Apple was able to better absorb rising memory costs through higher margins and reduced promotions. Realistically, this means we can expect an overall increase in iPhone prices when the new range is announced up to $300 more, Jeff Pu, of GF Securities, recently claimed. 

Building the moat

Once again, what’s sustainable but difficult for larger brands such as Apple is existential disaster for smaller players — and it’s only now a matter of time before we see some real blood. That’s particularly true in smart home and device markets, where manufacturers lack the margins to sustain higher memory prices while delivering products customers can afford. A recent Global Electronics Association report tells us 62% of electronics manufacturers are already experiencing constrained availability or extended lead times. It also tells us 82% expect rising prices, including 33% who cite a “significant increase.”

This is already being felt by consumer and business users, as networking equipment is experiencing significant shipping delays. So, while we may find ourselves waiting a month or more for an iPhone, the wait for new routers, external storage devices, and home automation systems could be even longer once available inventories disappear. 

This doesn’t appear to be a short-term challenge; a recent Digitimes report warns that vendors have already sold their entire allocation of memory capacity for 2027.

Don’t even get me started on the likely impact on the military and defense markets as high-performance memory, storage, and processor supplies become constrained. Just like declining river levels in Europe, lack of memory threatens severe disruption. With so much turbulence impacting the tech economy, all we need now is for one or more of theinvestor-supported AI companies that have helped create the memory shortages to default on loan payments.

Got to keep the customer satisfied

Eager to protect sales, Apple recently introduced the Apple Upgrade leasing service in the US. This should enable consumers to purchase new devices at prices more sustainable to them over time. Apple isn’t alone in taking such action, which will inevitably extend beyond America.

“OEMs are expanding financing, trade-in and buyback programs to improve affordability,” said Counterpoint’s Harshit Rastogi. “Samsung has also expanded its Galaxy Forever program to several markets to make flagship devices more accessible.” 

Such schemes are all well and good, of course. Consumers will embrace them in hopes of a better tomorrow. But the tech industry is not immune to the wider constellation of existential challenges impacting economic environments.

In the end, if Apple, the industry’s biggest buyer of advanced components, is struggling to secure memory, the rest of the electronics sector is likely to face even greater challenges. For consumers, the initial impacts will be longer waits and higher prices. But the longer term consequences could be slower innovation and increased consolidation across the industry.

You can follow me on social media! Join me on BlueSky,  LinkedIn, Mastodon and subscribe to The Core.

The memory crisis is getting worse for Apple, which is struggling to get enough memory chips together for its upcoming iPhone 18 Pro series smartphones. That’s according to tech journalist Tim Culpan.

As he details it, Apple and its assembly partners are still attempting to secure sufficient quantities of memory, and though they’re confident they can meet initial demand once the devices are introduced, they apparently remain concerned that wait times could rapidly extend as retail inventory evaporates.

Apple’s manufacturing process compounds the problem. The A20 processor is packaged with memory using a new TSMC process, meaning processors are reportedly piling up while manufacturers wait for memory chips. You should read Culpan’s report to get the full picture.

What’s the frequency?

You don’t need to read between the lines to see the challenge. Despite demand for TSMC’s new processors, Apple seems to have been able to secure the supply it needs. But when it comes to churning out the final packaged chips memory, supply constraints have created significant obstacles to producing in quantity.

This is bad for Apple, particularly as the challenge doesn’t appear to be confined to iPhones; customers are experiencing delays getting new Macs. “Many new orders are now not arriving until September,” Bloomberg’s Mark Gurman wrote earlier this week. 

It isn’t just Apple that will be impacted by the AI-driven memory drought. The scale of Apple’s orders is among the greatest in the industry, and if its product plans are feeling the pain, every other manufacturer will be feeling it as well.

Conscious uncoupling

This is certainly in tune with expectations voiced at the beginning of the year when Ranjit Atwal, senior director analyst at Gartner, warned: “This is the steepest contraction in device shipments witnessed in over a decade. Higher prices will narrow the range of devices available, prompting buyers to hold on to devices for longer, fundamentally altering upgrade cycles.”

Gartner in February predicted a 10.4% decline in global PC shipments and an 8.4% drop in smartphone shipments as a result. The analyst also predicted a 130% surge in combined memory and SSD storage prices by the end of this year, with steep product price increases to follow. Recent data from IDC, Gartner, Counterpoint, and Omdia confirm PC market declines, but only at around 4% (the estimates vary).

Today’s report from Culpan suggests we’ve not yet experienced the full extent of this decline — hinting that while the initial fall reflected price, the next impact will be defined by lack of supply. While this hurts big brands like Apple, smaller entities could be left high and dry. 

When the chips are down

It is interesting to reprise Atwal’s warning in February that, “the sub-$500 entry-level PC segment will disappear by 2028,” as this seems to be what’s happening. That’s something long-time Mac users like me find particularly ironic, given it was only this year Apple briefly offered up its superbly priced $499 MacBook Neo. The industry direction we’re seeing now suggests we’ll never see that again, though the success of that device gave Apple a phenomenal 28.7% increase in sales in its just-revealed June quarter.

Despite memory supply challenges, Apple seems to be faring fairly well, with market share increasing across its business. Counterpoint data reveals that Apple has achieved an astonishing 65% share of the premium smartphone market. In part, that’s because as an existing premium brand, Apple was able to better absorb rising memory costs through higher margins and reduced promotions. Realistically, this means we can expect an overall increase in iPhone prices when the new range is announced up to $300 more, Jeff Pu, of GF Securities, recently claimed. 

Building the moat

Once again, what’s sustainable but difficult for larger brands such as Apple is existential disaster for smaller players — and it’s only now a matter of time before we see some real blood. That’s particularly true in smart home and device markets, where manufacturers lack the margins to sustain higher memory prices while delivering products customers can afford. A recent Global Electronics Association report tells us 62% of electronics manufacturers are already experiencing constrained availability or extended lead times. It also tells us 82% expect rising prices, including 33% who cite a “significant increase.”

This is already being felt by consumer and business users, as networking equipment is experiencing significant shipping delays. So, while we may find ourselves waiting a month or more for an iPhone, the wait for new routers, external storage devices, and home automation systems could be even longer once available inventories disappear. 

This doesn’t appear to be a short-term challenge; a recent Digitimes report warns that vendors have already sold their entire allocation of memory capacity for 2027.

Don’t even get me started on the likely impact on the military and defense markets as high-performance memory, storage, and processor supplies become constrained. Just like declining river levels in Europe, lack of memory threatens severe disruption. With so much turbulence impacting the tech economy, all we need now is for one or more of theinvestor-supported AI companies that have helped create the memory shortages to default on loan payments.

Got to keep the customer satisfied

Eager to protect sales, Apple recently introduced the Apple Upgrade leasing service in the US. This should enable consumers to purchase new devices at prices more sustainable to them over time. Apple isn’t alone in taking such action, which will inevitably extend beyond America.

“OEMs are expanding financing, trade-in and buyback programs to improve affordability,” said Counterpoint’s Harshit Rastogi. “Samsung has also expanded its Galaxy Forever program to several markets to make flagship devices more accessible.” 

Such schemes are all well and good, of course. Consumers will embrace them in hopes of a better tomorrow. But the tech industry is not immune to the wider constellation of existential challenges impacting economic environments.

In the end, if Apple, the industry’s biggest buyer of advanced components, is struggling to secure memory, the rest of the electronics sector is likely to face even greater challenges. For consumers, the initial impacts will be longer waits and higher prices. But the longer term consequences could be slower innovation and increased consolidation across the industry.

You can follow me on social media! Join me on BlueSky,  LinkedIn, Mastodon and subscribe to The Core.

Generative AI is notoriously eager to help, to the point that if it can’t find something matching what you ask for, it’ll create it. So the problem with relying on guardrails is that all too often, a model will be wrong, showing a high confidence score for an incorrect answer because it’s relying on stale or non-canonical data.

Not only do you need to be able to track the lineage of data your model uses from source to token, something the EU AI Act requires, you also need to be able to take into account where the data came from, whether it’s out of date, if it changed in a way that affects the result, or if it was never really relevant or authoritative in the first place.

Gartner expects organizations will abandon 60% of AI projects because they don’t have the right metadata management, data quality, and data observability. IBM’s acquisition of Confluent also highlights the importance of real-time data with lineage, governance, and policy for AI agents, and one of IBM’s 2026 predictions was the importance of smarter data.

The usual approach is adding metadata and validation later in the data pipeline. That’s similar to the way the bronze, silver, and gold tiers of typical lakehouse architecture are supposed to represent how filtering, cleaning, and augmenting data improves structure and quality until it’s ready to use. That can mean an enormous amount of work since nearly three quarters of the CPU work in training a frontier model is data cleansing and validation.

But that can also remove a lot of the context crucial for gen AI. Rather than cleaning data and losing the original context, it’s often more effective to keep as much information about the original state of the data, says David Aronchick, open-source platform Kubeflow founder, and CEO of distributed data pipeline vendor Expanso. “You can’t pursue exactly purely clean data; that’s just not possible,” he says. “As you pull data into your ML model, every line should have some mechanism saying where it came from. Otherwise, you’re never really going to know because you can’t mix them together and tease them apart later. You can search your raw content, your raw logs, but it’s just not going to be there.”

IoT digital twin systems often tag data all the way back to the device capturing it so you can see whether a temperature spike is a critical failure, which you want to react to, or a routine calibration, which you don’t. But that information may well be relevant down the line when you want to use that data more broadly. So unless you capture at least some elements about the source of data before you move it, you’re not going to be able to easily reconstruct the context later, or at all sometimes.

Ulrik Hansen, co-CEO of Encord, a platform for managing and annotating data, calls this in-stream labelling and cautions it’s not an alternative to cleansing data. “Dirty conflates two things: actual corruption you should fix, and context dependence, where a reading only looks anomalous because you threw away the frame that explained it,” he says. “Cleansing kills both. The point isn’t to stop cleaning, it’s to stop normalizing away context you can never recover.”

Context can be cheap to capture at the source and nearly impossible to recover after, he adds. “The question isn’t whether to keep it,” he says, “it’s about curating what actually helps.”

Raw but not rancid

Aronchick characterizes the state of most bronze tiers as toxic waste because raw data doesn’t get validated before ingestion, or have a metadata wrapper on each data point. “You’ve taken raw data and stripped it of context,” he says.

Take a wind farm operator, for instance. When sensor data about the turbines is generated, it comes from a particular turbine at a particular position in a specific wind farm at a known location, running at a specific speed in specific weather conditions, at a particular time. “If you have other turbines also working in the field, the performance of your turbine will go down, but the field performance will go up,” says Aronchick. “The performance of your turbine going down isn’t a negative, but unless you have the context at the point of data collection, you’re going to make your life much harder later on, when someone asks about the efficiency.”

Metadata needs to be much richer, and it needs to be added as early in your data pipeline as possible when you have the most detail available to make sense of the structure and complexity of the data, Aronchick adds. “You want to capture as much about the data you’re collecting as possible, where it doesn’t require insane activity to do so.”

But not all the metadata you need will be generated with the data, he says. You almost certainly need to augment and annotate your data, and provide extra structure, especially for something like a point of sale system with very light metadata. “Data comes off these things in poor structure,” he says. “It’s not OpenLineage, it’s often a CSV or a text record, and you have to reconstruct them into a full structured log. So do smart things where you’re creating data. That might be compressing, sampling, converting, appending metadata to it, and enforcing schema and lineage all before you start moving anything.”

That doesn’t have to mean bloating your data, Hansen points out. He suggests capturing what’s free and unrecoverable. “The system of origin is the label,” he says. “You don’t tag HR policy, you capture that it came from the HR system. Anything a model can derive later, you can skip.”

Structure isn’t static

Routine changes to APIs, schemas, and how data is collected or stored happen in every organization, and need to be reflected in metadata that lives alongside the data or added as data is collected, not reconstructed later in a fragile process that depends on knowing about all those changes. Google’s research into these data cascades shows how easily context gets lost and how badly it affects data quality.

Shifting schema enforcement further left in your data pipeline so you deal with it as soon as possible allows you to make more effective downstream decisions. For a sensor recording temperature and humidity, you need to know the temperature scale it uses, readings, and how the timestamp is recorded. Checking that against the schema before ingesting the data lets you route it differently depending on whether it validates or triggers alerts about data quality.

“Maybe I’ll delete it, or send it off to some place where a human being or other tooling can reconstruct it into something valuable,” says Aronchick. “But what it doesn’t do is allow the polluted or bad data into my pipeline. Saying whether or not something passed your schema makes your downstream systems much more reliable.”

Sensing structure

Unstructured and semistructured data needs more augmentation. A PDF or Word document has an author and a creation date, but doesn’t necessarily include any context about the job title and department of the author, whether it’s up to date, only applies to a particular group of customers, or is based on accounting regulations that can change. If that information is available, it needs to travel with the document, not be left in a compliance spreadsheet.

Data platforms like DataHub and SurrealDB both capture and create context. The latter can analyze a photo, for instance, using vision AI to understand what’s in the image. “From completely unstructured data, we get as much structure as possible,” says the company’s CEO Tobie Morgan Hitchcock.

That’s paired with other data potentially useful for an AI agent down the line. “Understanding what happened around an event becomes a lot easier if you’re tracking the conversation, telemetry, tool and model usage, geospatial data, and the vector search and relationships,” he says. “You’re going to have a far better chance of getting an accurate understanding of that data, which started off completely unstructured, than if you weren’t capturing anything.”

Metadata about document authors, which might come from the company directory, can show how much authority a document has. He describes that as building an understanding of what trust and provenance is over time by the weight and authority of who’s updating the information. After all, he says, company-generated information has more trust or can have traced provenance compared to conversational inputs from a user.

Incentives for annotating

DataHub CTO Shirshanka Das saw how much of a mess data can be even with strong guidelines as former architect of LinkedIn’s GDPR strategy. “The data was a swamp, despite us having had pretty good data-first and schema-first practices,” he says. As well as cleaning up the data governance, they added in the first nuggets of the DevOps’ ‘shift left’ approach.

LinkedIn already required data checked in to its Kafka ecosystem to have a schema, and ran CI/CD pipelines to check backward compatibility. “I attached metadata attribution and collection around compliance metadata into that pipeline, where developers weren’t able to check in a schema until they had declared what every column meant.”

The extra work was unpopular until teams who didn’t participate saw the flood of tickets that came their way, which allowed him to extend that same proactive governance and annotation at source approach to pretty much every data set being produced.

“The starting point of data at most companies is a lot more swampy,” he says. “Many people are using Kafka, which is a very schema forward system, and yet they’re just shoving in JSON and unstructured stuff.”

That’s common, agrees Megha Kumar, research VP for analytics and AI at IDC, because while collecting more metadata provides better context and cleaner data lineage, it’s hard in practice. “Most organizations batch process data, so real-time context capture rarely happens,” she says. “Even the ones that process in real-time tend to have pre-defined schemas, so adding context requires changes to the data, which unfortunately happens later.”

People don’t know how to start, says Das, so DataHub Cloud tries to add back context by collecting operational metadata from multiple systems, including queries and BI tools to extrapolate a semantic model. “We confront the mess by giving them something they can react to,” he says. “They can quickly validate, and then it starts becoming a governance layer on top where humans annotate at source.”

Online whiteboard provider Miro, for example, dramatically improved AI agent query accuracy from about 50% to 90% using DataHub. Then they applied GitOps principles on top of what was inferred with a human in the loop for approvals.

So getting people to do the work happened the same way at LinkedIn, says Das. “When a data scientist gets 10 times more requests because they didn’t document their work well, resulting in the AI making lots of mistakes and stakeholders constantly pinging them for answers, they have the incentive to add the annotation when they produce an analysis, because then they get out of the critical path.”

DBOMs and data contracts

Provenance and lineage of data is critical, Aronchick says, so you can preserve details like who collected the data, when, from where, if the source was authoritative or canonical, what transformations were run, and exactly what the model saw.

“It’s not just about the version and the metadata,” he says. “Where things really start to change is when you can say along the way this data has gone through these steps, this is the root source, and these were the other elements.” You want to be able to find out if there were any experimental flags, like a new customer campaign running when it was collected, as well as what claims the data contributes to.

Aronchick advocates for a SLSA-style data bill of materials using a tool like Makoto, which can add signed provenance and attestation to simplify applying central concepts of governance and structure to upstream data.

The notion of a data contract or a data product spec is starting to become common in the financial sector says Das, defining it as a data set, or a group of data sets, bound together by a contract that defines expectations which aren’t just cosmetic but machine verifiable. They can also include operational SLOs for APIs as contracts describe not just the shape of the data but operational characteristics and guarantees.

Document graph markup language (DGML), a new open source specification from Docugami, promises provenance down to individual data points automatically extracted from documents.

“It’s critical to know the validity and provenance of the information your AI is relying on,” Docugami CEO and XML co-creator Jean Paoli says. “Establishing the validity of data right from the start, at scale, is vital and far more efficient than trying to clean up bad data later.” DGML combines semantic tags describing what content means in its business context with bounding boxes showing exactly where in the document the content comes from, with attestation to prove it.

AI demands provenance

All this context is the kind of metadata Anthropic’s context engineering guide recommends feeding to agents for accuracy. Developers are already used to giving coding agents more context, Das argues. “The same thing is happening with data, as when people realize when AI agents can’t make sense of what they’re doing, hallucinations happen,” he says.

Kumar agrees that organizations realize agents need context to provide better insights. “In many cases, it has to do with ensuring the existing data had clear semantics and relationships,” she says.

If you want to make sure the purchase return window an AI chatbot promises customers is based on your own policy, not a wish list from a user forum, you need rich context. It’s not just metadata. Organizations need to have semantics, data lineage, and ontologies. “Many are also building knowledge and ontology graphs,” adds Kumar. “By ensuring the systems understand what the data means, it’ll be able to provide a better response.”

And if you’re going to the expense of fine tuning, which needs relevant and domain- or task-specific examples, you don’t want noise, duplication, or irrelevant content in your data. You can, of course, exclude poor data if it’s annotated and verified earlier, but you can also improve model performance with extra information, Aronchick points out. “The augmentation of the existing data makes the data you pull out more valuable,” he says.

Expanso recently won an Edge AI award for fine tuning a base level model with only about 3,200 images by augmenting them with metadata. “The reason it worked on that few is because I could tell it deterministically what was in the frame,” he adds. “It’s labeling at the point of capture instead of paying somebody to label it later. What if I developed models for predictive analytics of store behavior on a per city, region, or country basis? If I’m able to take the raw point of sale information and augment it with additional metadata, I’m turning this into a much easier thing to fine tune.”

Or you might even avoid the expense of fine tuning entirely, suggests Das. “You get the short-term advantage by fine-tuning and getting great performance at much cheaper cost on a smaller model, and it gets stripped away in a couple of months as a new model shows up,” he says. “You have to always run that calculus of when’s the right threshold to fine tune an existing model, distil it, and then run it for a fair amount of time to recoup the costs of fine tuning.”

Although regulated or slow-moving industries will see benefits from fine tuning a model they can run for six to 12 months on data with higher quality and better provenance, many organizations may use the improved data quality to get good results without fine tuning.

“We’re taking a more knowledge graph-oriented approach to grounding the model, and betting on the fact that because the knowledge graph is changing often, it’s better to keep it as a runtime artifact than a baked-in one.”

Generative AI is notoriously eager to help, to the point that if it can’t find something matching what you ask for, it’ll create it. So the problem with relying on guardrails is that all too often, a model will be wrong, showing a high confidence score for an incorrect answer because it’s relying on stale or non-canonical data.

Not only do you need to be able to track the lineage of data your model uses from source to token, something the EU AI Act requires, you also need to be able to take into account where the data came from, whether it’s out of date, if it changed in a way that affects the result, or if it was never really relevant or authoritative in the first place.

Gartner expects organizations will abandon 60% of AI projects because they don’t have the right metadata management, data quality, and data observability. IBM’s acquisition of Confluent also highlights the importance of real-time data with lineage, governance, and policy for AI agents, and one of IBM’s 2026 predictions was the importance of smarter data.

The usual approach is adding metadata and validation later in the data pipeline. That’s similar to the way the bronze, silver, and gold tiers of typical lakehouse architecture are supposed to represent how filtering, cleaning, and augmenting data improves structure and quality until it’s ready to use. That can mean an enormous amount of work since nearly three quarters of the CPU work in training a frontier model is data cleansing and validation.

But that can also remove a lot of the context crucial for gen AI. Rather than cleaning data and losing the original context, it’s often more effective to keep as much information about the original state of the data, says David Aronchick, open-source platform Kubeflow founder, and CEO of distributed data pipeline vendor Expanso. “You can’t pursue exactly purely clean data; that’s just not possible,” he says. “As you pull data into your ML model, every line should have some mechanism saying where it came from. Otherwise, you’re never really going to know because you can’t mix them together and tease them apart later. You can search your raw content, your raw logs, but it’s just not going to be there.”

IoT digital twin systems often tag data all the way back to the device capturing it so you can see whether a temperature spike is a critical failure, which you want to react to, or a routine calibration, which you don’t. But that information may well be relevant down the line when you want to use that data more broadly. So unless you capture at least some elements about the source of data before you move it, you’re not going to be able to easily reconstruct the context later, or at all sometimes.

Ulrik Hansen, co-CEO of Encord, a platform for managing and annotating data, calls this in-stream labelling and cautions it’s not an alternative to cleansing data. “Dirty conflates two things: actual corruption you should fix, and context dependence, where a reading only looks anomalous because you threw away the frame that explained it,” he says. “Cleansing kills both. The point isn’t to stop cleaning, it’s to stop normalizing away context you can never recover.”

Context can be cheap to capture at the source and nearly impossible to recover after, he adds. “The question isn’t whether to keep it,” he says, “it’s about curating what actually helps.”

Raw but not rancid

Aronchick characterizes the state of most bronze tiers as toxic waste because raw data doesn’t get validated before ingestion, or have a metadata wrapper on each data point. “You’ve taken raw data and stripped it of context,” he says.

Take a wind farm operator, for instance. When sensor data about the turbines is generated, it comes from a particular turbine at a particular position in a specific wind farm at a known location, running at a specific speed in specific weather conditions, at a particular time. “If you have other turbines also working in the field, the performance of your turbine will go down, but the field performance will go up,” says Aronchick. “The performance of your turbine going down isn’t a negative, but unless you have the context at the point of data collection, you’re going to make your life much harder later on, when someone asks about the efficiency.”

Metadata needs to be much richer, and it needs to be added as early in your data pipeline as possible when you have the most detail available to make sense of the structure and complexity of the data, Aronchick adds. “You want to capture as much about the data you’re collecting as possible, where it doesn’t require insane activity to do so.”

But not all the metadata you need will be generated with the data, he says. You almost certainly need to augment and annotate your data, and provide extra structure, especially for something like a point of sale system with very light metadata. “Data comes off these things in poor structure,” he says. “It’s not OpenLineage, it’s often a CSV or a text record, and you have to reconstruct them into a full structured log. So do smart things where you’re creating data. That might be compressing, sampling, converting, appending metadata to it, and enforcing schema and lineage all before you start moving anything.”

That doesn’t have to mean bloating your data, Hansen points out. He suggests capturing what’s free and unrecoverable. “The system of origin is the label,” he says. “You don’t tag HR policy, you capture that it came from the HR system. Anything a model can derive later, you can skip.”

Structure isn’t static

Routine changes to APIs, schemas, and how data is collected or stored happen in every organization, and need to be reflected in metadata that lives alongside the data or added as data is collected, not reconstructed later in a fragile process that depends on knowing about all those changes. Google’s research into these data cascades shows how easily context gets lost and how badly it affects data quality.

Shifting schema enforcement further left in your data pipeline so you deal with it as soon as possible allows you to make more effective downstream decisions. For a sensor recording temperature and humidity, you need to know the temperature scale it uses, readings, and how the timestamp is recorded. Checking that against the schema before ingesting the data lets you route it differently depending on whether it validates or triggers alerts about data quality.

“Maybe I’ll delete it, or send it off to some place where a human being or other tooling can reconstruct it into something valuable,” says Aronchick. “But what it doesn’t do is allow the polluted or bad data into my pipeline. Saying whether or not something passed your schema makes your downstream systems much more reliable.”

Sensing structure

Unstructured and semistructured data needs more augmentation. A PDF or Word document has an author and a creation date, but doesn’t necessarily include any context about the job title and department of the author, whether it’s up to date, only applies to a particular group of customers, or is based on accounting regulations that can change. If that information is available, it needs to travel with the document, not be left in a compliance spreadsheet.

Data platforms like DataHub and SurrealDB both capture and create context. The latter can analyze a photo, for instance, using vision AI to understand what’s in the image. “From completely unstructured data, we get as much structure as possible,” says the company’s CEO Tobie Morgan Hitchcock.

That’s paired with other data potentially useful for an AI agent down the line. “Understanding what happened around an event becomes a lot easier if you’re tracking the conversation, telemetry, tool and model usage, geospatial data, and the vector search and relationships,” he says. “You’re going to have a far better chance of getting an accurate understanding of that data, which started off completely unstructured, than if you weren’t capturing anything.”

Metadata about document authors, which might come from the company directory, can show how much authority a document has. He describes that as building an understanding of what trust and provenance is over time by the weight and authority of who’s updating the information. After all, he says, company-generated information has more trust or can have traced provenance compared to conversational inputs from a user.

Incentives for annotating

DataHub CTO Shirshanka Das saw how much of a mess data can be even with strong guidelines as former architect of LinkedIn’s GDPR strategy. “The data was a swamp, despite us having had pretty good data-first and schema-first practices,” he says. As well as cleaning up the data governance, they added in the first nuggets of the DevOps’ ‘shift left’ approach.

LinkedIn already required data checked in to its Kafka ecosystem to have a schema, and ran CI/CD pipelines to check backward compatibility. “I attached metadata attribution and collection around compliance metadata into that pipeline, where developers weren’t able to check in a schema until they had declared what every column meant.”

The extra work was unpopular until teams who didn’t participate saw the flood of tickets that came their way, which allowed him to extend that same proactive governance and annotation at source approach to pretty much every data set being produced.

“The starting point of data at most companies is a lot more swampy,” he says. “Many people are using Kafka, which is a very schema forward system, and yet they’re just shoving in JSON and unstructured stuff.”

That’s common, agrees Megha Kumar, research VP for analytics and AI at IDC, because while collecting more metadata provides better context and cleaner data lineage, it’s hard in practice. “Most organizations batch process data, so real-time context capture rarely happens,” she says. “Even the ones that process in real-time tend to have pre-defined schemas, so adding context requires changes to the data, which unfortunately happens later.”

People don’t know how to start, says Das, so DataHub Cloud tries to add back context by collecting operational metadata from multiple systems, including queries and BI tools to extrapolate a semantic model. “We confront the mess by giving them something they can react to,” he says. “They can quickly validate, and then it starts becoming a governance layer on top where humans annotate at source.”

Online whiteboard provider Miro, for example, dramatically improved AI agent query accuracy from about 50% to 90% using DataHub. Then they applied GitOps principles on top of what was inferred with a human in the loop for approvals.

So getting people to do the work happened the same way at LinkedIn, says Das. “When a data scientist gets 10 times more requests because they didn’t document their work well, resulting in the AI making lots of mistakes and stakeholders constantly pinging them for answers, they have the incentive to add the annotation when they produce an analysis, because then they get out of the critical path.”

DBOMs and data contracts

Provenance and lineage of data is critical, Aronchick says, so you can preserve details like who collected the data, when, from where, if the source was authoritative or canonical, what transformations were run, and exactly what the model saw.

“It’s not just about the version and the metadata,” he says. “Where things really start to change is when you can say along the way this data has gone through these steps, this is the root source, and these were the other elements.” You want to be able to find out if there were any experimental flags, like a new customer campaign running when it was collected, as well as what claims the data contributes to.

Aronchick advocates for a SLSA-style data bill of materials using a tool like Makoto, which can add signed provenance and attestation to simplify applying central concepts of governance and structure to upstream data.

The notion of a data contract or a data product spec is starting to become common in the financial sector says Das, defining it as a data set, or a group of data sets, bound together by a contract that defines expectations which aren’t just cosmetic but machine verifiable. They can also include operational SLOs for APIs as contracts describe not just the shape of the data but operational characteristics and guarantees.

Document graph markup language (DGML), a new open source specification from Docugami, promises provenance down to individual data points automatically extracted from documents.

“It’s critical to know the validity and provenance of the information your AI is relying on,” Docugami CEO and XML co-creator Jean Paoli says. “Establishing the validity of data right from the start, at scale, is vital and far more efficient than trying to clean up bad data later.” DGML combines semantic tags describing what content means in its business context with bounding boxes showing exactly where in the document the content comes from, with attestation to prove it.

AI demands provenance

All this context is the kind of metadata Anthropic’s context engineering guide recommends feeding to agents for accuracy. Developers are already used to giving coding agents more context, Das argues. “The same thing is happening with data, as when people realize when AI agents can’t make sense of what they’re doing, hallucinations happen,” he says.

Kumar agrees that organizations realize agents need context to provide better insights. “In many cases, it has to do with ensuring the existing data had clear semantics and relationships,” she says.

If you want to make sure the purchase return window an AI chatbot promises customers is based on your own policy, not a wish list from a user forum, you need rich context. It’s not just metadata. Organizations need to have semantics, data lineage, and ontologies. “Many are also building knowledge and ontology graphs,” adds Kumar. “By ensuring the systems understand what the data means, it’ll be able to provide a better response.”

And if you’re going to the expense of fine tuning, which needs relevant and domain- or task-specific examples, you don’t want noise, duplication, or irrelevant content in your data. You can, of course, exclude poor data if it’s annotated and verified earlier, but you can also improve model performance with extra information, Aronchick points out. “The augmentation of the existing data makes the data you pull out more valuable,” he says.

Expanso recently won an Edge AI award for fine tuning a base level model with only about 3,200 images by augmenting them with metadata. “The reason it worked on that few is because I could tell it deterministically what was in the frame,” he adds. “It’s labeling at the point of capture instead of paying somebody to label it later. What if I developed models for predictive analytics of store behavior on a per city, region, or country basis? If I’m able to take the raw point of sale information and augment it with additional metadata, I’m turning this into a much easier thing to fine tune.”

Or you might even avoid the expense of fine tuning entirely, suggests Das. “You get the short-term advantage by fine-tuning and getting great performance at much cheaper cost on a smaller model, and it gets stripped away in a couple of months as a new model shows up,” he says. “You have to always run that calculus of when’s the right threshold to fine tune an existing model, distil it, and then run it for a fair amount of time to recoup the costs of fine tuning.”

Although regulated or slow-moving industries will see benefits from fine tuning a model they can run for six to 12 months on data with higher quality and better provenance, many organizations may use the improved data quality to get good results without fine tuning.

“We’re taking a more knowledge graph-oriented approach to grounding the model, and betting on the fact that because the knowledge graph is changing often, it’s better to keep it as a runtime artifact than a baked-in one.”

I hope you’ll indulge me this week as I take a break from my usual rantings about agentic coding and meander down memory lane.

I learned to code BASIC in the mid-1970s at my progressive junior high school. In math class. We took Fridays to learn about line numbers, loops, statements, and the amazing GOSUB, which was as close as we got to a function call. It strikes me that it was pretty early in the whole tech world to be teaching seventh graders to program, and I feel lucky.

Coding faded into the background for me through high school, but soon afterward the arrival of Windows 3.0 and modems made writing software fun again. You could even earn a little profit. CompuServe, AOL, and bulletin board systems (BBS) created a market for shareware.

I bought a copy of Turbo Pascal for Windows 1.0 from Borland and a copy of Mastering Turbo Pascal 6 by the great Tom Swan, and I learned the Pascal syntax. I remember being delighted to discover that Swan had also written a book specifically for Turbo Pascal for Windows, and I devoured that too. 

In search of SYSBACK

I soon came up with an idea for a shareware project — System Backup. Any of you who can remember back to the DOS and Windows 3.x days will remember that there were four files — AUTOEXEC.BAT, CONFIG.SYS, WIN.INI, and SYSTEM.INI — that were crucial to one’s setup. You’ll also remember that it wasn’t uncommon to twiddle with these files to eke out an extra measure of performance from the system. Backing those files up was critical to the tweaking, so I wrote SYSBACK.EXE to do the job quickly and easily. 

Windows 3.1 introduced the amazing feature of *.wav files — sound through your tinny PC speaker! That led me to write WAVSHELL.EXE, which listed all your sound files and made them easy to play.

I guess I didn’t have much faith in the value of my shareware because I released it into the wild of the pre-internet shareware market for a measly $2. People soon started sending me checks in the mail — my address was in the About Box, with a plea to pay for the software. Soon I added a licensing scheme and a “nag screen” that would go away if the user entered a valid license key. I actually made a bit of money.

Eventually both programs became unnecessary as Windows grew more functional, and I abandoned things. I’m sure all that code is on a hard drive in a landfill somewhere. 

But that doesn’t mean that SYSBACK and WAVSHELL don’t live on!

Last week, on a whim, I went searching to see if I could find any remnants of my glory days. Although it took a while, I was delighted to discover that both programs had clung to life in the dark crevices of the internet. 

I found WAVSHELL.ZIP and SYSBACK.ZIP and downloaded them. Sure enough, there were the files — the 16-bit Windows executables, along with the accompanying READMEs formatted for Windows Write, the simple word processor that came with Windows 3.1.

Return to Windows 3.1

So, what to do? Naturally I fired up Claude and asked how to get all this running. It suggested I give Oracle VirtualBox a try. At first I tried an open-source DOS version, but soon ran into conflict with memory managers and Windows. Tweaking CONFIG.SYS like the old days didn’t seem to make a difference.

This led to downloading a set of *.img files of MS-DOS 6.22. I mounted the first disk in the A: drive of the virtual machine. (For you youngsters, the A: drive was a floppy disk — maybe you remember those?) I had to do a virtual version of the old disk shuffle for the three floppies, and then do the same to install Windows. Everything installed and ran like clockwork, and soon enough, Windows 3.1 was up and running. 

Then, of course, I had to figure out how to get the files from my modern system to this ancient OS. This led me to WinImage, a shareware program (!) that builds floppy disk images for you. I built an image, copied the files onto the “disk,” and mounted it in the A: drive in the VirtualBox machine. I copied the files to the virtual hard drive, and behold!

There they are, in all their glory. I have to say, it was quite a thrill. And they actually work!

Anyway, it was fun to remember all those halcyon days of CompuServe, 2400 BAUD modems, and getting checks from strangers in the mail. It seems strange to me that 35 years from now, some software developer will be writing a column about the deep dark past when people used to actually write code, argue about what programming languages were best, and, who knows, even had to type things out by hand.

Malicious AI use and threats to AI systems are requiring cyber teams to double down on security fundamentals and rethink the future of their approaches to defense.

Newly emerging AI-enabled attacks, proofs of concept, and in-the-wild techniques, as well as the latest AI vulnerability and risk research, present inklings not only about what enterprises presently face but also how security leaders need to adjust for what may soon come to their systems.

The following report aims to help inform and provide a gateway to insights into what we’ve seen evolving on the AI threat horizon of late.

AI goes rogue

The most impactful recent event signaling what’s here and ahead for CISOs was the revelation of OpenAI’s agents attacking Hugging Face.

The attack, executed by sandboxed OpenAI models, shows that prompt guardrails cannot serve as a reliable, primary security boundary for AI agents, putting pressure on enterprises to establish more sophisticated agentic infrastructure controls to limit access and prevent lateral movement. CSO’s Prasanth Aby Thomas breaks down how OpenAI’s agent containment strategy failed.

Further investigation of the OpenAI incident uncovered additional breached trust boundaries, prompting the Cloud Security Alliance’s CISO Community to issue emergency guidance for strengthening controls around autonomous AI agents, CSO’s Gyana Swain reports. The incident also prompted Anthropic to analyze its own cybersecurity evaluations, finding that its Claude models had also escaped their test environments to encounter real-world systems, with one such incident resulting in Claude publishing a malicious Python package to the public PyPI repository, which was downloaded and executed by 15 real systems.

With frontier labs not yet required to provide kill switches for AI agents, enterprise CISOs are encouraged to investigate architecting their own.

The Hugging Face incident also shows how important it is for incident response teams to have a multi-modal AI strategy, including open-weighted models, to ensure viable operations under fire, writes CSO’s Lucian Constantin.

Attacking the AI workflow

CISOs should also be aware that attackers are turning attention to agent workflows, seeking ways to infect AI agents with malicious rules, configuration, and instruction files to do their bidding. CSO’s Constantin reports on the trend, which includes a recently revealed backdoor attack technique dubbed “PromptLogger.”

According to researchers from Mitiga, PromptLogger tricks AI agents into exfiltrating prompts and responses through maliciously crafted instruction files (e.g., CLAUDE.md). The technique has also been observed attempting to influence agents into injecting backdoor code into Python files that could be copied to other systems. Because agents would be performing these tasks on criminals’ behalf, detection is an uphill battle.

Enterprise workflows could also potentially be corrupted via self-propagating document-borne AI worms, according to a recent report from Norwegian AI researcher Håkon Måløy centered on Microsoft Copilot. As CSO’s Evan Schuman reports, by concealing instructions in files used as source material for Copilot-assisted workflows, Måløy demonstrated how attackers could use Copilot as a transmission mechanism for corrupting data and propagating malware, something that could sidestep nearly every defense mechanism in place today.

Development in the crosshairs

Software development remains the workflow most impacted by AI threats today, with recent reports underscoring established attack modalities, including a critical vulnerability in Ruflo MCP infrastructure and the potential for slopsquatting on nonexistent PyPI and npm packages that top AI coding tools collectively and consistently hallucinate, report CSO’s Swain and Maxwell Cooter.

Moreover, security flaws in automated workflows in Google’s ADK for Python GitHub repository, now since hardened, could induce agents to post commands and remove review requests, making a malicious pull request appear ready to merge. Pillar Security, which discovered the flaws, called it the “first practical, real-world case of agent-to-agent exploitation” involving a production multi-agent system, CSO’s Thomas reports.

The insider threat

A recently patched OpenAI flaw shows another means by which attackers could enlist rogue AI agents to operate on their behalf. Dubbed “AgentForger,” this phishing-based attack, reported by Zenity Labs, could have enabled attackers to silently create and launch fully autonomous AI agents within OpenAI workspaces. Broad, unfettered access to systems would then turn the agent into a “persistent operator,” capable of performing reconnaissance, harvesting data and credentials, and impersonating victims, CSO’s Taryn Plumb writes.

Meanwhile, Pathfinder’s 2026 AI Governance Gap Report finds that 53% of organizations cannot verify what AI agents do across their business systems — not great news when 36% have deployed or are implementing AI agents within finance and accounting environments, CSO’s Shweta Sharma notes.

And if you need any more fodder for tighter restrictions on that other insider threat, CSO’s Grant Gross sheds light on how senior executives are killing your shadow AI strategy.

In-depth:

• AI is making cybersecurity fundamentals more important than ever
• OpenAI model escape puts enterprise AI defenses on notice
• Hugging Face breach shows why incident response needs a multi-model AI strategy
• Attackers are crafting malicious AI instruction files to turn agents into criminal helpers
• AgentForger proves AI agents can become persistent insider threats
• Senior executives are killing your shadow AI strategy

40 Jahre lang drehte sich in Sachen Tools für die Softwareentwicklung alles um die integrierte Entwicklungsumgebung – kurz IDE. Sie wurde vor allem durch die Borland Software Corporation massentauglich gemacht und revolutionierte die Entwicklungsarbeit, indem sie Editor, Compiler und Debugger zu einer Einheit verschmolz. Tools wie Turbo Pascal (das ich bis heute verehre) stellten für Devs in den 1980er Jahren insofern eine echte Revolution dar.

Knapp ein halbes Jahrhundert später ist der kometenhafte Aufstieg von Agentic Development dabei, der Vorherrschaft der IDE ein jähes Ende zu setzen. Es wird immer deutlicher, dass die integrierte Entwicklungsumgebung zunehmend aufs Abstellgleis gerät: Entwickler nutzen sie immer seltener – und widmen sich stattdessen anderen Tasks. Zum Beispiel managen sie die KI-Agenten, die heute für sie den Code schreiben.

Der Umschwung verläuft dabei rasant: Noch vor wenigen Monaten habe ich selbst mit Unterstützung eines KI-Agenten in meiner IDE gearbeitet. Dabei durfte ich schnell feststellen, dass das – je nach Anzahl der eingesetzten Agenten und der zu bearbeitenden Tasks – schnell ziemlich unübersichtlich wird oder driftet direkt ins Chaos abdriftet.

An dieser Stelle wurde auch mir klar, dass Entwickler, die mit KI-Agenten arbeiten, ein Next-Generation-Tool benötigen, um alle Agentic-Development-Aspekte ordentlich managen zu können – ein Agentic Development Environment (ADE).

Die IDE stirbt – lang lebe die ADE

Auf meinem Weg zu dieser Erkenntnis war vor allem ein weitgehend unbekanntes und ungenutztes Feature von Git bedeutsam – Worktrees. Damit lassen sich mehrere Zweige desselben Repository aus einer einzigen Git-Datenbank in verschiedene Verzeichnisse auschecken. Diese Funktion eignet sich in besonderem Maße für die neue Agentic-Development-Welt.

Traditionellerweise würde ein Entwickler jeweils ein Ticket bearbeiten, wofür ein simpler Git-Checkout ausreicht. Das setzt allerdings die Annahme voraus, dass nur ein Akteur, nämlich der Dev, an der Codebasis arbeitet.

Im Zeitalter der KI-Agenten ist es jedoch längst nicht mehr undenkbar, dass diese parallel an drei Jira-Tickets werkeln. In diesem Szenario werden Worktrees zum Enabler: Sie weisen jedem Entwickler – respektive Agenten – einen eigenen Zweig und ein eigenes Verzeichnis zu. Quasi eine Art simple Isolierung ohne den ganzen Overhead, der entsteht, wenn separate Repository-Instanzen geklont und geforkt werden müssen.

Allerdings wirft der Aufwand, der durch die Kombination von Worktrees und KI-Agenten entsteht, Herausforderungen auf. Und genau an dieser Stelle kommt die ADE ins Spiel. Sie koordiniert und managt sämtliche Vorgänge, wenn mehrere Coding-Agenten an verschiedenen Issues innerhalb mehrerer Repository-Zweige arbeiten sollen.

Entwickler befähigt das zu mühelosem Multitasking – und dazu, viele Tasks zeitgleich im Blick zu behalten. Um die Logistik um Worktrees herum müssen sie sich mit einer ADE nicht mehr kümmern. Stattdessen können sie ihre Zeit nutzen, um die Agenten zu steuern und sicherzustellen, dass diese ihre Aufgaben korrekt erledigen.

Der Abschied von der IDE mag für manchen Dev emotional sein. Aber wahrscheinlich müssen auch wehmütige Entwickler zugeben, dass sie ihre IDE inzwischen gar nicht mehr so oft einsetzen. Und wer mit Agenten arbeitet, wird sie künftig auch nicht vermissen. (fm)

Dieser Artikel ist im Original bei unserer Schwesterpublikation Infoworld.com erschienen.