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.

After two decades of cloud architecture consulting, I see an unchanging pattern in enterprise deployments. Organizations approach me with unexpectedly high cloud bills, operational chaos, and architectures that look good on paper but cause headaches in production. The common thread is almost always the same. Fundamental concepts that should be foundational to any cloud deployment are treated as optional or ignored altogether.

I’m not talking about exotic requirements, bleeding-edge technologies, or vendor-specific best practices. Basic engineering principles are somehow getting lost amid the excitement of cloud adoption. I wish I could say it’s rare, but after working with organizations across industries and geographies for years, I can confirm that missing these fundamentals is more common than most people realize. The results are predictable. Bills grow faster than business value, architectures require constant firefighting, and teams are stretched too thin to optimize anything.

The good news? You don’t have to start over, but you do have to go back to basics. Here are three concepts most cloud architects overlook that will make your architecture dramatically more valuable and efficient.

Identifying common ground

When deploying heterogeneous architecture, especially in multicloud environments, organizations must aggressively reduce silos. This means establishing common control planes for security, governance, and operations. You won’t get there by relying on whatever proprietary technology each cloud provider offers out of the box. Each provider wants you locked into their way of managing things. That is fine for simple deployments, but when you are running across multiple clouds and on-premises systems, proprietary control planes introduce redundancy, complexity, and cost.

You need a single control layer that spans your entire environment. Instead of managing 10 different security solutions from 10 different providers, you have one. Instead of separate identity management systems for each cloud, you need one that works everywhere. This eliminates the need to change security parameters in five different consoles, maintain five different skill sets for five different operational models, and reconcile five different governance frameworks. The common control plane ties everything together.

This might sound hard, but it’s not as bad as you think. (I will cover the specific patterns in a future article.) The real issue is that most architects have never been trained to think this way. They were taught to select the best services from each provider rather than abstract away the differences. This fundamental gap costs organizations real money every single day.

Cost observability and optimization

Most architects treat cost visibility and optimization as afterthoughts, things that can be bolted on after the architecture is in place. That backward approach shows up in the results. Without cost observability and optimization baked into your architecture from day one, you cannot understand where your money is going, where waste is accumulating, or where you should make changes to align expenses with delivered value.

The more complex and heterogeneous your environment, the more critical this becomes. You need a unified cost observability layer that spans public and private clouds and your own infrastructure. This is about building a layer that aggregates cost data from everywhere, provides a single source of truth for spending, and delivers the insights needed to actively optimize. Without this, you are flying blind, making decisions based on incomplete data and discovering problems only after the invoice arrives.

Too many organizations fail to gain control of their cloud spending because their billing data is scattered across multiple consoles, with no way to correlate usage across providers. They cannot see which teams, projects, or services are driving costs. They miss opportunities to right-size, consolidate, or eliminate waste. You cannot improve what you cannot measure. Without a common cost observability and optimization layer built into your architecture, you will never achieve the efficiency the cloud was supposed to deliver.

Consider the human element

Here is an uncomfortable truth most architects do not want to discuss: The more complex your architecture is, the broader the range of skills you will need to keep it running. Complexity requires expertise, and expertise requires hiring, training, and retention. If your architecture demands 15 different skill sets to operate, you’d better have a plan for finding and retaining the people with those skills.

I have seen beautifully designed architectures fail because the organization could not meet hiring requirements. They compromised by hiring underqualified individuals, which led to operational failures, security gaps, and mounting technical debt. The architecture itself was sound. The human infrastructure around it was not. This is a solvable problem. It starts with acknowledging that you are not designing for yourself. You are designing for the team that will inherit this system after you have moved on to your next assignment or promotion.

The solution isn’t just simplifying architecture, though that should be a goal. The key is to consider human factors in your design. What skills are required? How can you find and train people? What cultural changes are necessary for effective operation? These questions are essential; ignoring them risks failure.

The simple bottom line

I understand why most cloud architects miss these basic principles. No single course or book brings all of this together in one place. Cloud architecture has become a collection of best practices, vendor recommendations, and conference talking points, rather than a disciplined engineering discipline focused on business value.

As a result, architectures end up optimized in the wrong places, if they are optimized at all. They are expensive to run, difficult to secure, and nearly impossible to operate at scale without constant intervention. The cloud promises efficiency, yet we are not delivering it because we have lost sight of the fundamentals.

It’s time to go back to basics. Commonality, human factors, and cost observability and optimization are the three things that separate architectures that create value from those that create cost. Incorporate these concepts into your architecture and you’ll get ahead of most production systems in use today.

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’s impact has been felt across nearly every industry, and its rise has already started to alter several roles in tech, including that of the business analyst. While the rise of agentic AI may have some questioning whether AI will replace business analyst jobs entirely, as we’ve seen with most roles impacted by AI, it’s more likely that AI will augment the role and fundamentally change how BA’s conduct daily business.

“As AI takes on more routine tasks, the human side of the role is becoming even more valuable. It’s becoming more of a hybrid role, where employers are often looking for candidates who can combine technical fluency with strong communication and problem-solving skills, along with sound business judgment,” says Megan Slabinski, district president of technology talent solutions at Robert Half.

AI can save business analysts time in the long run, automating many of the tasks that are time consuming and repetitive around data processing, note taking, and documentation. While automation will impact the daily tasks of the role, business analysts will still be necessary for properly interpreting outputs, collaborating across teams, and maintaining compliance and AI workflows.

AI-driven analysis and automated workflows

With AI-driven analysis, BA’s can use machine learning models for pattern detection, determining risk, and for forecasting demand, while natural language processing (NLP) can be used for text-heavy inputs. AI tools can also assist analysts with decision-making by transcribing meetings and automatically identifying any necessary business requirements, constraints, risks, or dependencies that will impact the project.

As a result, the role is undergoing a shift toward spending less time on monotonous, routine tasks, and instead “spending more time connecting the dots and providing strategic context earlier in the process,” says Slabinksi.

“We’re seeing that business analysts today aren’t spending as much time as they were a few years ago on some manual processes. AI is speeding up tasks like documenting requirements, summarizing stakeholder meetings, generating first drafts of user stories, and even helping create SQL queries or reports,” she adds.

AI can also assist business analysts with interviews and workshops for the discovery phase of a project and autonomously identify patterns in the data that might be overlooked or missed by the human eye. These tools can also enable BAs to create living models that can be adjusted and altered with feedback, as opposed to traditional static documents, and allow for an automated review process for data validation. In terms of maintenance and change management, AI can help with predictive recommendations to get ahead of risks, compliance, and future process updates.

That said, an increased reliance on AI tools while require business analysts to validate AI outputs and assure AI-generated content is accurate, relevant, and ultimately aligned with the overall business strategy. Still responsible for explaining the reasons behind business decisions, business analysts will also need to identifying bias and fairness concerns associated with AI use, and ensure decisions aren’t over-automated.

Ultimately, BA’s will see their responsibilities shift to focusing more on data interpretation, governance, and strategy, and identifying the most practical use cases for enterprise AI adoption.

New skills to focus on

Traditionally, business analysts are responsible for gathering the data as well as processing it for analysis. This comes with a lot of drudgery that can be eased by implementing AI tools into the workflow. Tasks such as routine documentation, formatting, and data crunching can be automated, while analysts provide the human context around that data, as well as a critical eye to the final output.

“Business analysts are often in the mix to make sure that data is accurate and that the requirements are in line with expected outcomes. They can also help ensure AI projects include the appropriate level of human oversight, comply with internal policies and industry regulations, and use data responsibly. While they aren’t solely responsible for AI governance, they often play an important role in raising questions about data sources, bias, whether the outputs make sense, and potential business risks early in a project,” says Slabinski.

BAs will need to develop AI literacy skills to better understand how models are trained and designed as well as data reasoning skills to interpret and validate AI outputs. Prompt-framing skills will also become valuable as analysts will need to know how to properly structure inputs for quality outputs. There will also be a growing emphasis on ethical analysis to identify compliance, bias, and overall fairness of algorithms, and qualified candidates will require strong change management skills to help oversee the adoption of AI-driven workflows.

“The skills becoming more important are the ones that help BAs evaluate AI-generated information and translate it into business recommendations. AI literacy is becoming a baseline expectation, and that includes knowing things like how to query the data and support requirements gathering. Critical thinking, communication, and business acumen are all part of that skill set because employers still need people who can explain what the findings mean and why they matter,” says Slabinski.

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.

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.

AI’s impact has been felt across nearly every industry, and its rise has already started to alter several roles in tech, including that of the business analyst. While the rise of agentic AI may have some questioning whether AI will replace business analyst jobs entirely, as we’ve seen with most roles impacted by AI, it’s more likely that AI will augment the role and fundamentally change how BA’s conduct daily business.

“As AI takes on more routine tasks, the human side of the role is becoming even more valuable. It’s becoming more of a hybrid role, where employers are often looking for candidates who can combine technical fluency with strong communication and problem-solving skills, along with sound business judgment,” says Megan Slabinski, district president of technology talent solutions at Robert Half.

AI can save business analysts time in the long run, automating many of the tasks that are time consuming and repetitive around data processing, note taking, and documentation. While automation will impact the daily tasks of the role, business analysts will still be necessary for properly interpreting outputs, collaborating across teams, and maintaining compliance and AI workflows.

AI-driven analysis and automated workflows

With AI-driven analysis, BA’s can use machine learning models for pattern detection, determining risk, and for forecasting demand, while natural language processing (NLP) can be used for text-heavy inputs. AI tools can also assist analysts with decision-making by transcribing meetings and automatically identifying any necessary business requirements, constraints, risks, or dependencies that will impact the project.

As a result, the role is undergoing a shift toward spending less time on monotonous, routine tasks, and instead “spending more time connecting the dots and providing strategic context earlier in the process,” says Slabinksi.

“We’re seeing that business analysts today aren’t spending as much time as they were a few years ago on some manual processes. AI is speeding up tasks like documenting requirements, summarizing stakeholder meetings, generating first drafts of user stories, and even helping create SQL queries or reports,” she adds.

AI can also assist business analysts with interviews and workshops for the discovery phase of a project and autonomously identify patterns in the data that might be overlooked or missed by the human eye. These tools can also enable BAs to create living models that can be adjusted and altered with feedback, as opposed to traditional static documents, and allow for an automated review process for data validation. In terms of maintenance and change management, AI can help with predictive recommendations to get ahead of risks, compliance, and future process updates.

That said, an increased reliance on AI tools while require business analysts to validate AI outputs and assure AI-generated content is accurate, relevant, and ultimately aligned with the overall business strategy. Still responsible for explaining the reasons behind business decisions, business analysts will also need to identifying bias and fairness concerns associated with AI use, and ensure decisions aren’t over-automated.

Ultimately, BA’s will see their responsibilities shift to focusing more on data interpretation, governance, and strategy, and identifying the most practical use cases for enterprise AI adoption.

New skills to focus on

Traditionally, business analysts are responsible for gathering the data as well as processing it for analysis. This comes with a lot of drudgery that can be eased by implementing AI tools into the workflow. Tasks such as routine documentation, formatting, and data crunching can be automated, while analysts provide the human context around that data, as well as a critical eye to the final output.

“Business analysts are often in the mix to make sure that data is accurate and that the requirements are in line with expected outcomes. They can also help ensure AI projects include the appropriate level of human oversight, comply with internal policies and industry regulations, and use data responsibly. While they aren’t solely responsible for AI governance, they often play an important role in raising questions about data sources, bias, whether the outputs make sense, and potential business risks early in a project,” says Slabinski.

BAs will need to develop AI literacy skills to better understand how models are trained and designed as well as data reasoning skills to interpret and validate AI outputs. Prompt-framing skills will also become valuable as analysts will need to know how to properly structure inputs for quality outputs. There will also be a growing emphasis on ethical analysis to identify compliance, bias, and overall fairness of algorithms, and qualified candidates will require strong change management skills to help oversee the adoption of AI-driven workflows.

“The skills becoming more important are the ones that help BAs evaluate AI-generated information and translate it into business recommendations. AI literacy is becoming a baseline expectation, and that includes knowing things like how to query the data and support requirements gathering. Critical thinking, communication, and business acumen are all part of that skill set because employers still need people who can explain what the findings mean and why they matter,” says Slabinski.

Two years ago, I sat across from a chief financial officer who had just spent forty minutes on a video call authorizing what he believed was a legitimate acquisition payment. The call included his CEO and two board members, all speaking in familiar voices, all making the kind of small unscripted comments that make a meeting feel real. None of them were real. The audio had been cloned from earnings call recordings, and the video was built from conference footage pulled off YouTube.

What gave it away wasn’t a glitch or a blurred hand. It was a pause. The CFO asked about a side conversation from the previous week that only the real CEO would have known, and the voice on the other end hesitated half a second too long before answering. That hesitation stopped a seven-figure transfer.

It also taught me something I have carried into every engagement since. Executive impersonation has moved from a theoretical AI risk category into an active enterprise security problem, and detection and response capability lags materially behind attacker capability.

The detection tooling gap

When clients ask me what to buy first, I tell them to slow down. The tooling landscape for synthetic media is real, but it is not mature, and treating it as solved creates false confidence at exactly the moment confidence gets tested.

Audio and video forensics tools scan a file after the fact for artifacts synthetic generation tends to leave behind. They are genuinely useful in a post-incident review, where there is time to run deeper analysis. They are far less useful in the middle of a live call, where a decision has to get made in seconds rather than hours.

Liveness detection tries to solve that timing problem by checking for signs of life during the interaction itself, rather than analyzing a file afterward. The trouble is that these systems were mostly built for identity verification at onboarding, a single controlled check at a fixed point in time. Retrofitting them into an unplanned executive call is still mostly aspirational, and most vendors will tell you the same thing privately even while marketing otherwise.

The MITRE ATLAS knowledge base, which catalogs real-world adversarial attacks against AI systems, now documents deepfake-based identity verification bypass as an established attack pattern rather than an edge case. That matters for CISOs because it confirms this is not a hypothetical gap security vendors invented to sell tools. It is a documented technique with case studies attached.

What senior executives specifically need, and what the market still doesn’t reliably offer, is verification that works in the moment a request is made rather than after the fact. Until that exists at scale, the tooling has to sit inside a broader protocol rather than stand in for one.

A framework enterprise teams can deploy now

Tooling alone will not close this gap, so the operational framework matters more than any single product. Here is what I put in place with clients, organized around five actions.

1. Verify. Multi-factor human verification for executive-level communications means more than a callback. It means a pre-agreed authentication phrase for the small circle of people who can approve high-sensitivity or high-value actions, changed on a schedule and never guessable from a public LinkedIn bio. It means out-of-band confirmation as a hard requirement, not a courtesy, for any request involving money, credentials or a change to standing instructions. I watched this stop an attack outright. A caller using a cloned voice of an executive asked a colleague for help with a confidential wire. The colleague asked for the agreed phrase, and the line went dead within seconds.
2. Detect. This is not about buying a detection tool. It is about continuously monitoring the executive’s digital identity surface before an attacker even builds the deepfake. That includes tracking domain squatting on the executive’s name, watching for social profile impersonation, and knowing where voice samples are already sitting in public conference recordings and podcast appearances that an attacker could pull from tomorrow. Most security teams monitor the network. Very few monitor the raw material an attacker needs to build a convincing fake in the first place.
3. Respond. When an impersonation attempt is identified or succeeds, the response playbook needs to specify who freezes a transaction, who pulls the call recording before it disappears, and who brings in forensics immediately so there is a documented basis for every decision that follows. It needs a defined escalation path that does not depend on the target believing something is wrong, because most executives will not report a strange call themselves. Build the reporting habit around the transaction, not the suspicion.
4. Train. Executive protection training has to include impersonation awareness now, and not just for the executive. Assistants, chiefs of staff and family office contacts are frequently the actual point of contact an attacker targets, since they often have more standing authority to approve something quickly than the executive expects them to use. This has to be a working habit, not a slide deck people sit through once a year.
5. Integrate. Executive impersonation cannot sit inside a single team’s silo. It needs coordination between security operations, communications, legal and executive protection, because a voice clone built from a podcast appearance does not touch a single system any one of those functions monitors on its own. A CSO Online feature on deepfake defense documented an almost identical wire fraud case and reached a similar conclusion that the organizations recovering fastest were the ones that had already rehearsed the coordination across teams before an incident forced it.

Where the market hasn’t caught up

Even programs built around all five of those actions still run into gaps that no enterprise has fully closed.

The first is the personal exposure gap. Most protocols assume the target is inside a corporate communication channel. Attackers are increasingly working the other direction, reaching family members or personal devices where none of the corporate verification steps apply at all.

The second is the public-facing gap. Livestreams of major corporate events have been hijacked by deepfakes of the company’s own executives, often promoting cryptocurrency scams, with fake feeds sometimes drawing sizeable audiences before takedown. That is not an internal fraud scenario a SOC playbook was built for. It is a brand and platform-level impersonation that needed coordination with a video platform in real time, and almost nobody has that relationship pre-built. The security team needing to reach a platform’s off-hours trust and safety escalation path in the middle of a live event is functionally starting from zero every time, and the incident is often over by the time the right internal owner on the platform side is even identified.

The third is measurement. Very few security teams can currently tell their board how prepared they actually are for this category of risk, because the tabletop exercises that would surface the gaps are still rare. Boards are starting to ask the question anyway, often after reading about another company’s incident rather than their own, and a security leader without a rehearsed answer is at a real disadvantage in that conversation.

Back to that CFO on the video call. What saved him was not a tool. It was a habit, built well before the attack, of treating a hesitation as reason enough to stop. That is still the most reliable control available, and it will remain the most reliable control until the rest of this framework catches up to it.

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?

Enterprises deploying agentic AI may need a new generation of AI servers as conventional GPU-centric infrastructure struggles to efficiently execute multi-step AI workflows, according to researchers from Microsoft Azure and the University of Texas at Austin.

Drawing on production telemetry from Microsoft’s Azure cloud and experiments with representative open-source agent frameworks, the researchers found that AI agents spend far more time coordinating models, tools, and orchestration software than conventional inference systems assume.

Rather than behaving like standalone LLM requests, agentic applications execute as dynamic workflows that repeatedly move work between CPUs, GPUs, and external services, exposing inefficiencies in today’s server designs.

“Our study shows that agentic execution is fundamentally fragmented and heterogeneous,” the researchers wrote in the paper. “Each request expands into a workflow of LLM inferences, tool invocations, and orchestration decisions that repeatedly crosses the CPU-GPU boundary.”

According to the paper, that execution pattern places the CPU on the application’s critical path because orchestration software and tools execute on the host while model inference runs on GPUs.

The researchers said conventional server architectures are poorly matched to those workloads because fragmented execution strands CPU and GPU resources, different host-side software roles have different resource requirements, and multiplexing multiple agents increases coordination overhead.

Production data points to fragmented execution

The researchers said a representative production request alternated between multiple LLM calls, tool discovery, tool execution, and orchestration before completing. In a controlled study using the CORAL framework, a single workload expanded into 580 LLM calls interleaved with 552 tool invocations, causing execution to “ping-pong between the two processors hundreds of times.”

The study also found that host CPU utilization remained low for extended periods before rising sharply during bursts of tool execution, while GPU utilization varied widely depending on workflow composition, leaving some accelerators saturated and others idle.

According to the researchers, the fragmented execution pattern leaves CPUs and GPUs underutilized on average while allowing either processor to become “a transient bottleneck on the workflow’s critical path,” making static resource provisioning inefficient for agentic workloads.

Sanchit Vir Gogia, chief analyst at Greyhound Research, said the findings show enterprises should evaluate agentic AI infrastructure differently from conventional inference deployments.

“Agentic AI is not a bigger chatbot; it is a distributed application with inference embedded inside it,” Gogia said. “The individual ingredients are familiar. The execution graph is new.”

“The GPU remains indispensable, but it no longer owns the entire clock,” he added. “Tool time matched or beat inference time in more than 27 per cent of requests, and average utilisation is beginning to lie to infrastructure teams.”

Researchers propose workflow-aware server design

Based on those findings, the researchers proposed a server architecture, called Agora, that dynamically reallocates CPU and GPU resources, separates scheduling, orchestration, and tool execution into dedicated host roles, and adapts resource allocation to workload behavior.

“Agora dynamically harvests idle CPU cores for co-located throughput work, while protecting agentic tail latency against tool spikes. It also oversubscribes GPU memory by placing more agents on each GPU, prefetching the next agent’s state to hide swap latency,” the researchers wrote in the paper. “To match the machine to the heterogeneous roles, Agora pools cores by role and applies affinity-aware scheduling to restore locality. These techniques substantially improve CPU and GPU utilization and per-server throughput while preserving agent tail latency.”

In their evaluation, the researchers reported that Agora increased host CPU utilization by about 30%, recovered about 95% of a co-located workload’s standalone throughput under low load, freed roughly one-third of GPUs through workload consolidation, increased generation throughput by 82%, and reduced tail latency by 2.5 times.

Gogia said the findings indicate that infrastructure procurement should focus less on individual processors and more on how entire AI workflows execute.

“The CPU is not returning to the throne; the throne itself is disappearing,” he said. “Competitive advantage is moving from the individual processor to the heterogeneous server, rack and runtime operating as one system.” He said organizations should “procure the workflow, not the box,” arguing that workload profiling and scheduling are likely to deliver greater benefits than sizing infrastructure based on model inference alone.

Two years ago, I sat across from a chief financial officer who had just spent forty minutes on a video call authorizing what he believed was a legitimate acquisition payment. The call included his CEO and two board members, all speaking in familiar voices, all making the kind of small unscripted comments that make a meeting feel real. None of them were real. The audio had been cloned from earnings call recordings, and the video was built from conference footage pulled off YouTube.

What gave it away wasn’t a glitch or a blurred hand. It was a pause. The CFO asked about a side conversation from the previous week that only the real CEO would have known, and the voice on the other end hesitated half a second too long before answering. That hesitation stopped a seven-figure transfer.

It also taught me something I have carried into every engagement since. Executive impersonation has moved from a theoretical AI risk category into an active enterprise security problem, and detection and response capability lags materially behind attacker capability.

The detection tooling gap

When clients ask me what to buy first, I tell them to slow down. The tooling landscape for synthetic media is real, but it is not mature, and treating it as solved creates false confidence at exactly the moment confidence gets tested.

Audio and video forensics tools scan a file after the fact for artifacts synthetic generation tends to leave behind. They are genuinely useful in a post-incident review, where there is time to run deeper analysis. They are far less useful in the middle of a live call, where a decision has to get made in seconds rather than hours.

Liveness detection tries to solve that timing problem by checking for signs of life during the interaction itself, rather than analyzing a file afterward. The trouble is that these systems were mostly built for identity verification at onboarding, a single controlled check at a fixed point in time. Retrofitting them into an unplanned executive call is still mostly aspirational, and most vendors will tell you the same thing privately even while marketing otherwise.

The MITRE ATLAS knowledge base, which catalogs real-world adversarial attacks against AI systems, now documents deepfake-based identity verification bypass as an established attack pattern rather than an edge case. That matters for CISOs because it confirms this is not a hypothetical gap security vendors invented to sell tools. It is a documented technique with case studies attached.

What senior executives specifically need, and what the market still doesn’t reliably offer, is verification that works in the moment a request is made rather than after the fact. Until that exists at scale, the tooling has to sit inside a broader protocol rather than stand in for one.

A framework enterprise teams can deploy now

Tooling alone will not close this gap, so the operational framework matters more than any single product. Here is what I put in place with clients, organized around five actions.

1. Verify. Multi-factor human verification for executive-level communications means more than a callback. It means a pre-agreed authentication phrase for the small circle of people who can approve high-sensitivity or high-value actions, changed on a schedule and never guessable from a public LinkedIn bio. It means out-of-band confirmation as a hard requirement, not a courtesy, for any request involving money, credentials or a change to standing instructions. I watched this stop an attack outright. A caller using a cloned voice of an executive asked a colleague for help with a confidential wire. The colleague asked for the agreed phrase, and the line went dead within seconds.
2. Detect. This is not about buying a detection tool. It is about continuously monitoring the executive’s digital identity surface before an attacker even builds the deepfake. That includes tracking domain squatting on the executive’s name, watching for social profile impersonation, and knowing where voice samples are already sitting in public conference recordings and podcast appearances that an attacker could pull from tomorrow. Most security teams monitor the network. Very few monitor the raw material an attacker needs to build a convincing fake in the first place.
3. Respond. When an impersonation attempt is identified or succeeds, the response playbook needs to specify who freezes a transaction, who pulls the call recording before it disappears, and who brings in forensics immediately so there is a documented basis for every decision that follows. It needs a defined escalation path that does not depend on the target believing something is wrong, because most executives will not report a strange call themselves. Build the reporting habit around the transaction, not the suspicion.
4. Train. Executive protection training has to include impersonation awareness now, and not just for the executive. Assistants, chiefs of staff and family office contacts are frequently the actual point of contact an attacker targets, since they often have more standing authority to approve something quickly than the executive expects them to use. This has to be a working habit, not a slide deck people sit through once a year.
5. Integrate. Executive impersonation cannot sit inside a single team’s silo. It needs coordination between security operations, communications, legal and executive protection, because a voice clone built from a podcast appearance does not touch a single system any one of those functions monitors on its own. A CSO Online feature on deepfake defense documented an almost identical wire fraud case and reached a similar conclusion that the organizations recovering fastest were the ones that had already rehearsed the coordination across teams before an incident forced it.

Where the market hasn’t caught up

Even programs built around all five of those actions still run into gaps that no enterprise has fully closed.

The first is the personal exposure gap. Most protocols assume the target is inside a corporate communication channel. Attackers are increasingly working the other direction, reaching family members or personal devices where none of the corporate verification steps apply at all.

The second is the public-facing gap. Livestreams of major corporate events have been hijacked by deepfakes of the company’s own executives, often promoting cryptocurrency scams, with fake feeds sometimes drawing sizeable audiences before takedown. That is not an internal fraud scenario a SOC playbook was built for. It is a brand and platform-level impersonation that needed coordination with a video platform in real time, and almost nobody has that relationship pre-built. The security team needing to reach a platform’s off-hours trust and safety escalation path in the middle of a live event is functionally starting from zero every time, and the incident is often over by the time the right internal owner on the platform side is even identified.

The third is measurement. Very few security teams can currently tell their board how prepared they actually are for this category of risk, because the tabletop exercises that would surface the gaps are still rare. Boards are starting to ask the question anyway, often after reading about another company’s incident rather than their own, and a security leader without a rehearsed answer is at a real disadvantage in that conversation.

Back to that CFO on the video call. What saved him was not a tool. It was a habit, built well before the attack, of treating a hesitation as reason enough to stop. That is still the most reliable control available, and it will remain the most reliable control until the rest of this framework catches up to it.

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?

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.

Most organizations assume remediation reduces risk.

It’s a reasonable assumption. A vulnerability is identified, a patch is applied, the scanner comes back clean, and the ticket is closed. The workflow is complete, the metrics improve, and the issue is considered resolved.

The problem is that attackers don’t care about remediation workflows. They care about outcomes.

A scanner may no longer report the vulnerability, but those activities do not matter if an attacker can still achieve the same objective through the same attack path, excessive privileges, or a different weakness that was never addressed in the first place.

Many security programs measure whether work was completed, but they don’t always measure whether risk was actually reduced.

The assumption that gets teams in trouble

The cybersecurity industry has become very good at measuring mean time to remediate, patch compliance, SLA attainment, and ticket closure rates. Those metrics have value, but none of them answer the question an attacker is asking.

Can I still get in?

In practice, that’s where the assumption breaks down. Remediation activity and risk reduction are often treated as the same thing, even though they measure very different outcomes. One measures whether work was performed. The other measures whether the conditions that made an attack possible still exist.

Our recent survey of 750 security leaders and practitioners revealed a consistent pattern. Only 30% of CISOs reported that their organizations patch and then test to ensure risk has actually been remediated. Nearly half patch and rescan with a vulnerability scanner instead.

Security teams are working hard, remediating vulnerabilities, deploying controls, and closing tickets every day. The issue is verification. A patch may remove a vulnerability and a rescan may confirm the patch was applied, but neither proves an attacker can no longer succeed.

Security teams don’t get credit for completing work, they get credit for reducing risk. And the only way to know whether risk was actually reduced is to verify it.

Verification changes the conversation

Most security teams don’t struggle to find vulnerabilities. They struggle to verify that their remediation efforts actually worked.

That was the challenge facing a global investment firm operating across 18 locations. They already had vulnerability data, security assessments, and remediation workflows. What they lacked was certainty. They wanted to understand which weaknesses represented real risk, whether their fixes were reducing exposure, and how to avoid being surprised by an issue that should have been discovered earlier.

An early internal penetration test (pentest) revealed 85 weaknesses. By itself, that number wasn’t particularly alarming. The real risk emerged when those flaws enabled 251 impacts, including domain compromise, compromised credentials, host compromise, ransomware exposure, and sensitive data exposure. The weaknesses themselves were only part of the story. The real risk emerged when those weaknesses were chained together the way an attacker would chain them together.

While many organizations would stop there, this team retested. That decision changed the conversation from remediation activity to measurable risk reduction. A follow-up, same-scope pentest showed that impacts had dropped from 251 to zero. Compromised credentials fell from 52 to zero. Compromised hosts fell from 67 to zero. Cracked Active Directory passwords dropped from 40 to zero.

That’s what verification looks like.

Not a closed ticket, but concrete evidence that the outcomes an attacker cared about are no longer achievable.

Why verification remains elusive

In our survey, 22% of practitioners identified verification of fixes as their biggest cybersecurity challenge going into 2026, while another 21% pointed to demonstrating measurable risk reduction. Both ranked ahead of budget constraints and talent shortages.

That gap persists because confirmation is harder than remediation. Applying a patch is a discrete action. Proving that an attacker can no longer achieve the same objective is harder. It requires testing and verifying that the attack path is gone, not simply assuming it disappeared because a vulnerability no longer appears in a scan report.

That’s where many organizations fall back on proxies. A vulnerability scanner reports that: the affected version is gone; a ticket is closed; a dashboard shows improving metrics. Those signals are useful, but they are still indicators of activity. They are not proof that exposure was reduced.

That gap matters because attackers measure success by achieving objectives, not by confirming that a version number changed. Defenders need the same standard.

That’s the difference between remediation and verification.

What mature security programs do differently

The organizations that make the greatest progress aren’t necessarily the ones that find the most vulnerabilities. They’re the ones that become disciplined about proving whether their actions reduced risk.

That shift changes the conversation. Instead of asking: “Did we patch it?” they ask: “Can an attacker still achieve the same objective?”

Instead of measuring success by ticket closure, they measure success by whether the outcomes attackers care about are still possible.

You can see that mindset across many of our Pentest Wednesday™ stories. Financial services organizations built continuous verification into their operations because leadership needed confidence that remediation remained effective over time. Manufacturers and defense industrial base organizations used repeat testing to ensure attack paths stayed closed as environments evolved.

The common thread isn’t the industry or the technology, it’s the discipline to keep going after the fix:

• Validate the exposure.
• Fix the exposure.
• Verify the exposure is gone.
• Repeat.

Mature organizations build continuous verification into their operations because leadership needs to trust that remediation remains effective as the network evolves.

The future belongs to verification

The cybersecurity industry is entering another period of rapid change. AI is accelerating prioritization, remediation, reporting, and analysis. Security teams will find vulnerabilities faster, process findings faster, and automate more workflows than ever before.

Validating exposure and fixing it are essential, but neither closes the loop. Verification closes the loop. Confidence alone will not stop an attacker, but repeatable verification will.

Get a demo

Open the history tab of any epic that has been alive for more than two quarters. Go ahead, pick one. Count the edits. Somewhere around edit 11, the description was rewritten to satisfy a stakeholder who has since changed roles. Around edit 19, the scope was trimmed to protect a date that, in the end, moved anyway. By edit 26 someone renamed the whole thing, and the sentence that explained why the work existed in the first place didn’t survive the paste. 26 edits, several hundred hours of delivery behind them, and nobody left who can say what the money was for.

Nobody deleted that reason on purpose. That’s what makes this so hard to see.

I’ve been shuttling between the people who fund technology work and the teams who deliver it for a couple of decades now, and something has always struck me as odd: the backlog is probably the only important document in the enterprise that gets edited every day and remembers nothing. Contracts have version control and signatures. Financial statements have audit trails. Even architecture, in mature shops, has decision records. But the artifact that actually steers what hundreds of people build week after week? It has a title, a status and a description that mutates until the original intent becomes archaeology.

The most expensive failures I’ve seen were all fast. The teams shipped and shipped, and somewhere along the way the work stopped meaning what everyone assumed it still meant. Nobody slowed down long enough to notice.

One problem, two lenses

Strategy and delivery look at the same work through very different mental models. On one side, leaders talk in outcomes, intent and value; they worry about whether the original justification for the investment still holds months later. On the other side, teams think in iterations, flow and momentum, and they worry about keeping complex programs moving in small, manageable steps. Both lenses are legitimate, and in my experience both sides generally believe they’re the ones doing everything right.

The disagreement between them is never loud. Strategy quietly assumes the logic will remain constant across every sprint and every decision. Delivery quietly assumes the strategic reasoning will naturally update itself based on what gets learned along the way. There’s nothing wrong with either assumption on its own. But in the absence of a structural bridge between them, every program gradually accumulates small half-measures and shifted meanings that nobody registers until it’s too late.

The evidence on how badly intent travels is humbling. Donald Sull and his colleagues, in a multi-year study of strategy execution, found that only half of middle managers can name any of their company’s top five priorities. Those are the managers. Now imagine the epic, eleven edits later.

Let me be fair to agile here, because agile is not the villain. It does exactly what it says on the tin: it helps teams learn quickly and adjust to what they discover, and that speed is a genuine strength. The problem is that organizations blur the line between two kinds of change. Some of it is genuine learning: teams discover real behaviors, markets shift, leaders sharpen their thinking. And some of it is erosion, the slow loss of rationale that nobody actually decided and nobody can trace back to a witting choice. From the outside, the two are indistinguishable. They show up the same way in the tooling: movement in the backlog, shifting priorities, even working software. Only one of them stays anchored to the reason the money was spent.

Most organizations have no instrument for telling these two apart. Which means they’re flying at full speed without knowing whether they’re navigating or just moving.

The pattern we keep seeing

Agile in style, not in substance

The board gets moved every day, stand-ups start on time and retrospectives produce long lists of things to improve. Then you ask why a specific feature exists, what it’s actually meant to change, and the room gets quiet. The rituals persist while the substance underneath them slowly thins out. Teams keep closing tasks, and somewhere along the way they shed the shared sense of purpose that made the tasks worth doing.

Velocity becomes a proxy for value

A smooth sprint demo can hide a deeper problem, because progress toward delivery and progress toward outcomes are two different measurements, and only one of them is on the wall. I’ve seen features that were stable, polished and warmly received in the demo, and that contributed absolutely nothing to the decision they were supposed to improve. The pace was real enough; whether any of it mattered took months to find out. And your delivery metrics can be excellent, genuinely excellent, while every one of these patterns is running underneath them.

This is not a niche affliction, by the way. Pendo analyzed feature usage across hundreds of software products and found that 80% of features are rarely or never used. Built at full velocity, shipped into silence.

Product owners absorb pressure instead of defending logic

The PO is supposed to hold the thread, to protect the reasoning behind the work when everyone else is pushing on it. In practice, many find themselves wedged between demand and delivery, forced into a permanent state of reactive prioritization. Over time they stop challenging requests. Then they stop defending the logic behind decisions. Eventually they stop framing choices around outcomes at all, and the backlog, which should be a strategic instrument, turns into the place where everything gets dumped because nobody has the space left to ask what actually belongs there.

Backlog churn masks strategic drift

Items get revisited, split, recast and reprioritized as everyone works to keep momentum going, and from a distance it can all look like reasonable adaptation. But when the connection to intent is severed, all that motion begins to dissolve into static. Work keeps getting passed around, the board stays busy and the program veers off course without producing a single alarming signal, because busy is what everyone was looking for.

Every quarter is a reset

New OKRs arrive. A fresh wave of leadership messaging follows. Sometimes the team gets reshuffled too. With each round, a little of the shared context that held everything together quietly slips away. Epics get new names, stories get rewritten, priorities rearrange themselves almost by accident. The organization keeps rebooting itself without ever asking what it left behind in the reset.

Taken one at a time, each of these patterns is understandable, even forgivable. Together they produce a program that looks healthy from every angle while it quietly hollows out the meaning behind the work.

Why this keeps happening, and why it’s about to get worse

Big programs tend to assume that intent will simply carry itself forward as the work passes through teams, decisions and iterations. It won’t. Intent doesn’t carry itself. If nobody actively preserves and updates the reasoning, it starts to loosen and fray, quietly and almost politely, one story, one trade-off, one shift in priority at a time.

The structural cause is a speed mismatch that most governance was never designed for. The delivery system evolves in hours; the organization’s memory of why updates in quarters, if at all. In between those two clocks, thousands of micro-decisions reshape what the work means, far faster than anyone captures the reasoning behind them.

Now add what’s happening in 2026. AI agents inside the delivery tooling can already organize, create and edit backlog items on a team’s behalf. Atlassian’s own customers describe agents that generate requirements, break them into epics and stories and take delegated work like a teammate, and these capabilities now ship inside the standard Jira plans that most enterprises already pay for. I’m not against any of this; some of it is genuinely useful. But notice what it means for our problem. Every one of those operations is an edit to a document that has no memory. Backlog amnesia at human speed was survivable. Painful, but survivable, because humans forget slowly. Amnesia at machine speed is a different animal altogether. The ratio of motion to memory, already unhealthy in most organizations, is about to go vertical.

If your backlog can’t remember why an item exists after a human rewrote it a few times, think about what happens when an agent grooms it continuously.

What to do about it

The countermeasures I use are deliberately small. None of them adds a ceremony, a tool, or a governance layer. They simply orient the practices teams already run toward one job: keeping the reasoning alive while the work moves. Together, they form the discipline I call Structural Agile.

• Start with the outcome. Before an epic or major story enters the backlog, three questions, every time: What behavior are we trying to shift? How will we know if that behavior changes? What signals will confirm success after release? If the room can’t answer, the work waits, because items that lack outcome clarity tend to drift first and drift fastest.
• Elevate the PO. Position the product owner as the carrier of outcome logic, with an explicit mandate to preserve rationale, flag trade-offs that erode intent and track deferred items together with the reasoning behind them. And be realistic about the limits, because many POs inherit chaotic backlogs, rotate mid-stream, or simply lack the authority to push back on stakeholders. The rule I give teams is simple: if the PO can’t carry the logic, someone must: a coach prompting context checks, an architect recording the reasoning behind technical trade-offs, an analyst keeping the outcome picture current. Build logic stewardship into the structure. Left to personality, it leaves with the person.
• Anchor epics to why. Every epic carries its rationale as metadata, inside the tool where the work actually lives. Slide decks from last spring don’t count. When a decision reshapes the epic, the rationale gets updated in the same motion; waivers and scope cuts get recorded next to the item they changed. Do this consistently and the backlog stops being a queue of tasks and becomes a living map of intent, one that a new joiner can read on day one, and that survives a challenge from leadership without anyone having to reconstruct history from memory. It cuts both ways, too: the same rationale that protects the team from whiplash protects the business from a backlog that has drifted away from what they actually asked for. Prioritization turns into a conversation about evidence rather than a contest of opinions.
• Rehearse erosion. This is the practice I’d start with, and the one that surprises teams most. Every two or three sprints, run a short, structured session that is not a retrospective and not a risk review. Its purpose is to test the continuity of intent itself: Does the assumed user behavior still make sense? Where might adoption fail even though delivery is technically correct? Which parts of the outcome logic feel fragile, outdated, or untested? A retro examines how the team worked; an erosion rehearsal examines whether the reasoning still holds. You rehearse erosion the same way pilots rehearse emergencies: you hope the drill is wasted, and you run it anyway, because catching drift early is what makes fixing it cheap. In my experience, a single one of these sessions surfaces more strategic risk than a quarter’s worth of status reporting, and it costs the team about half an hour.
• Keep the logic alive. Capture only what prevents strategic amnesia and nothing more: why a feature was removed or reshaped, who approved it and which assumptions should be revisited, and when. Keep it visible where teams already work. If logic lives in Confluence but dies in conversation, it’s already gone.

Start Monday

You don’t need a reorganization or a new framework to begin, and frankly you shouldn’t want one. Three entry points, close to zero overhead. Assign a critical reviewer: one team member whose standing job is to periodically ask whether stories still connect to the intended outcome. Add a one-minute outcome check before major refinements: the behavior targeted, the indicator watched, the signal expected. And run a single erosion rehearsal on your most important program; teams usually surface something real in the first session, long before it would have shown up in any metric.

For readers keeping score: yes, neighboring practices exist, and they’re good ones. Architecture decision records preserve the why behind technical choices, and impact mapping connects deliverables to goals at planning time. I use both. Neither operates continuously, inside the backlog, at the level of the individual item, which happens to be exactly where the forgetting occurs. OKRs don’t solve it either; objectives at altitude are necessary, but teams still need the rationale embedded in the work itself, so they don’t have to keep a separate decoder.

The history tab, revisited

Go back to that epic with the twenty-six edits, and imagine the same history with one difference: each consequential edit carries a line of reasoning, current and human-readable, and every few sprints someone deliberately tested whether that reasoning still held. Same team, same velocity, same tool and a completely different answer when someone finally asks why the work exists.

Velocity tells you how fast the work is moving. Only memory can tell you whether anyone still knows where it’s going.

I’ve published the full discipline behind this approach (the five principles, the roles, the facilitation guides and the objections seasoned practitioners will raise, along with my answers) as a featured paper in PM World Journal. The mechanics are free to steal. The forgetting, at this point, is optional.

Open the history tab of any epic that has been alive for more than two quarters. Go ahead, pick one. Count the edits. Somewhere around edit 11, the description was rewritten to satisfy a stakeholder who has since changed roles. Around edit 19, the scope was trimmed to protect a date that, in the end, moved anyway. By edit 26 someone renamed the whole thing, and the sentence that explained why the work existed in the first place didn’t survive the paste. 26 edits, several hundred hours of delivery behind them, and nobody left who can say what the money was for.

Nobody deleted that reason on purpose. That’s what makes this so hard to see.

I’ve been shuttling between the people who fund technology work and the teams who deliver it for a couple of decades now, and something has always struck me as odd: the backlog is probably the only important document in the enterprise that gets edited every day and remembers nothing. Contracts have version control and signatures. Financial statements have audit trails. Even architecture, in mature shops, has decision records. But the artifact that actually steers what hundreds of people build week after week? It has a title, a status and a description that mutates until the original intent becomes archaeology.

The most expensive failures I’ve seen were all fast. The teams shipped and shipped, and somewhere along the way the work stopped meaning what everyone assumed it still meant. Nobody slowed down long enough to notice.

One problem, two lenses

Strategy and delivery look at the same work through very different mental models. On one side, leaders talk in outcomes, intent and value; they worry about whether the original justification for the investment still holds months later. On the other side, teams think in iterations, flow and momentum, and they worry about keeping complex programs moving in small, manageable steps. Both lenses are legitimate, and in my experience both sides generally believe they’re the ones doing everything right.

The disagreement between them is never loud. Strategy quietly assumes the logic will remain constant across every sprint and every decision. Delivery quietly assumes the strategic reasoning will naturally update itself based on what gets learned along the way. There’s nothing wrong with either assumption on its own. But in the absence of a structural bridge between them, every program gradually accumulates small half-measures and shifted meanings that nobody registers until it’s too late.

The evidence on how badly intent travels is humbling. Donald Sull and his colleagues, in a multi-year study of strategy execution, found that only half of middle managers can name any of their company’s top five priorities. Those are the managers. Now imagine the epic, eleven edits later.

Let me be fair to agile here, because agile is not the villain. It does exactly what it says on the tin: it helps teams learn quickly and adjust to what they discover, and that speed is a genuine strength. The problem is that organizations blur the line between two kinds of change. Some of it is genuine learning: teams discover real behaviors, markets shift, leaders sharpen their thinking. And some of it is erosion, the slow loss of rationale that nobody actually decided and nobody can trace back to a witting choice. From the outside, the two are indistinguishable. They show up the same way in the tooling: movement in the backlog, shifting priorities, even working software. Only one of them stays anchored to the reason the money was spent.

Most organizations have no instrument for telling these two apart. Which means they’re flying at full speed without knowing whether they’re navigating or just moving.

The pattern we keep seeing

Agile in style, not in substance

The board gets moved every day, stand-ups start on time and retrospectives produce long lists of things to improve. Then you ask why a specific feature exists, what it’s actually meant to change, and the room gets quiet. The rituals persist while the substance underneath them slowly thins out. Teams keep closing tasks, and somewhere along the way they shed the shared sense of purpose that made the tasks worth doing.

Velocity becomes a proxy for value

A smooth sprint demo can hide a deeper problem, because progress toward delivery and progress toward outcomes are two different measurements, and only one of them is on the wall. I’ve seen features that were stable, polished and warmly received in the demo, and that contributed absolutely nothing to the decision they were supposed to improve. The pace was real enough; whether any of it mattered took months to find out. And your delivery metrics can be excellent, genuinely excellent, while every one of these patterns is running underneath them.

This is not a niche affliction, by the way. Pendo analyzed feature usage across hundreds of software products and found that 80% of features are rarely or never used. Built at full velocity, shipped into silence.

Product owners absorb pressure instead of defending logic

The PO is supposed to hold the thread, to protect the reasoning behind the work when everyone else is pushing on it. In practice, many find themselves wedged between demand and delivery, forced into a permanent state of reactive prioritization. Over time they stop challenging requests. Then they stop defending the logic behind decisions. Eventually they stop framing choices around outcomes at all, and the backlog, which should be a strategic instrument, turns into the place where everything gets dumped because nobody has the space left to ask what actually belongs there.

Backlog churn masks strategic drift

Items get revisited, split, recast and reprioritized as everyone works to keep momentum going, and from a distance it can all look like reasonable adaptation. But when the connection to intent is severed, all that motion begins to dissolve into static. Work keeps getting passed around, the board stays busy and the program veers off course without producing a single alarming signal, because busy is what everyone was looking for.

Every quarter is a reset

New OKRs arrive. A fresh wave of leadership messaging follows. Sometimes the team gets reshuffled too. With each round, a little of the shared context that held everything together quietly slips away. Epics get new names, stories get rewritten, priorities rearrange themselves almost by accident. The organization keeps rebooting itself without ever asking what it left behind in the reset.

Taken one at a time, each of these patterns is understandable, even forgivable. Together they produce a program that looks healthy from every angle while it quietly hollows out the meaning behind the work.

Why this keeps happening, and why it’s about to get worse

Big programs tend to assume that intent will simply carry itself forward as the work passes through teams, decisions and iterations. It won’t. Intent doesn’t carry itself. If nobody actively preserves and updates the reasoning, it starts to loosen and fray, quietly and almost politely, one story, one trade-off, one shift in priority at a time.

The structural cause is a speed mismatch that most governance was never designed for. The delivery system evolves in hours; the organization’s memory of why updates in quarters, if at all. In between those two clocks, thousands of micro-decisions reshape what the work means, far faster than anyone captures the reasoning behind them.

Now add what’s happening in 2026. AI agents inside the delivery tooling can already organize, create and edit backlog items on a team’s behalf. Atlassian’s own customers describe agents that generate requirements, break them into epics and stories and take delegated work like a teammate, and these capabilities now ship inside the standard Jira plans that most enterprises already pay for. I’m not against any of this; some of it is genuinely useful. But notice what it means for our problem. Every one of those operations is an edit to a document that has no memory. Backlog amnesia at human speed was survivable. Painful, but survivable, because humans forget slowly. Amnesia at machine speed is a different animal altogether. The ratio of motion to memory, already unhealthy in most organizations, is about to go vertical.

If your backlog can’t remember why an item exists after a human rewrote it a few times, think about what happens when an agent grooms it continuously.

What to do about it

The countermeasures I use are deliberately small. None of them adds a ceremony, a tool, or a governance layer. They simply orient the practices teams already run toward one job: keeping the reasoning alive while the work moves. Together, they form the discipline I call Structural Agile.

• Start with the outcome. Before an epic or major story enters the backlog, three questions, every time: What behavior are we trying to shift? How will we know if that behavior changes? What signals will confirm success after release? If the room can’t answer, the work waits, because items that lack outcome clarity tend to drift first and drift fastest.
• Elevate the PO. Position the product owner as the carrier of outcome logic, with an explicit mandate to preserve rationale, flag trade-offs that erode intent and track deferred items together with the reasoning behind them. And be realistic about the limits, because many POs inherit chaotic backlogs, rotate mid-stream, or simply lack the authority to push back on stakeholders. The rule I give teams is simple: if the PO can’t carry the logic, someone must: a coach prompting context checks, an architect recording the reasoning behind technical trade-offs, an analyst keeping the outcome picture current. Build logic stewardship into the structure. Left to personality, it leaves with the person.
• Anchor epics to why. Every epic carries its rationale as metadata, inside the tool where the work actually lives. Slide decks from last spring don’t count. When a decision reshapes the epic, the rationale gets updated in the same motion; waivers and scope cuts get recorded next to the item they changed. Do this consistently and the backlog stops being a queue of tasks and becomes a living map of intent, one that a new joiner can read on day one, and that survives a challenge from leadership without anyone having to reconstruct history from memory. It cuts both ways, too: the same rationale that protects the team from whiplash protects the business from a backlog that has drifted away from what they actually asked for. Prioritization turns into a conversation about evidence rather than a contest of opinions.
• Rehearse erosion. This is the practice I’d start with, and the one that surprises teams most. Every two or three sprints, run a short, structured session that is not a retrospective and not a risk review. Its purpose is to test the continuity of intent itself: Does the assumed user behavior still make sense? Where might adoption fail even though delivery is technically correct? Which parts of the outcome logic feel fragile, outdated, or untested? A retro examines how the team worked; an erosion rehearsal examines whether the reasoning still holds. You rehearse erosion the same way pilots rehearse emergencies: you hope the drill is wasted, and you run it anyway, because catching drift early is what makes fixing it cheap. In my experience, a single one of these sessions surfaces more strategic risk than a quarter’s worth of status reporting, and it costs the team about half an hour.
• Keep the logic alive. Capture only what prevents strategic amnesia and nothing more: why a feature was removed or reshaped, who approved it and which assumptions should be revisited, and when. Keep it visible where teams already work. If logic lives in Confluence but dies in conversation, it’s already gone.

Start Monday

You don’t need a reorganization or a new framework to begin, and frankly you shouldn’t want one. Three entry points, close to zero overhead. Assign a critical reviewer: one team member whose standing job is to periodically ask whether stories still connect to the intended outcome. Add a one-minute outcome check before major refinements: the behavior targeted, the indicator watched, the signal expected. And run a single erosion rehearsal on your most important program; teams usually surface something real in the first session, long before it would have shown up in any metric.

For readers keeping score: yes, neighboring practices exist, and they’re good ones. Architecture decision records preserve the why behind technical choices, and impact mapping connects deliverables to goals at planning time. I use both. Neither operates continuously, inside the backlog, at the level of the individual item, which happens to be exactly where the forgetting occurs. OKRs don’t solve it either; objectives at altitude are necessary, but teams still need the rationale embedded in the work itself, so they don’t have to keep a separate decoder.

The history tab, revisited

Go back to that epic with the twenty-six edits, and imagine the same history with one difference: each consequential edit carries a line of reasoning, current and human-readable, and every few sprints someone deliberately tested whether that reasoning still held. Same team, same velocity, same tool and a completely different answer when someone finally asks why the work exists.

Velocity tells you how fast the work is moving. Only memory can tell you whether anyone still knows where it’s going.

I’ve published the full discipline behind this approach (the five principles, the roles, the facilitation guides and the objections seasoned practitioners will raise, along with my answers) as a featured paper in PM World Journal. The mechanics are free to steal. The forgetting, at this point, is optional.

When I first started working on enterprise AI security initiatives, I expected the biggest challenges to be technical. I assumed we’d spend most of our time discussing prompt injection, model security, vector databases or the latest LLM vulnerabilities.

I was wrong — or at least incomplete.

The technology certainly matters, but after working with multiple enterprise AI initiatives, I’ve learned that the hardest security problems rarely come from the model itself. They emerge when AI becomes part of real business processes.

An AI assistant doesn’t simply answer questions. In a single workflow, it might pull a customer record from Salesforce, open a ticket in ServiceNow and send an update through Microsoft 365 before anyone has finished reading the summary. Increasingly, it makes decisions before a human even notices, and that shift changes the threat model. Traditional application security assumes software executes deterministic code. AI systems don’t. They reason, adapt and generate outputs that cannot always be predicted in advance, which means many of the controls we’ve relied on for years remain necessary but are no longer sufficient.

What follows is what I keep coming back to in architecture reviews: Not the model vulnerabilities that dominate the headlines, but the quieter failures that show up once an agent is already running.

Identity is only the starting point

One of the first surprises I encountered was how quickly organizations focus on authentication while overlooking runtime behavior. Most enterprise AI projects begin with questions such as “Can the AI access SharePoint?” “Can it connect to ServiceNow?” “Can it connect to GitLab?” or “Can it read Microsoft 365 tools like Outlook, Word, etc.?” Those are important questions, but the more important one is: What should the AI be allowed to do after a specific type of access (for example, read-only access) has been granted?

Identity answers who the agent is. Authorization answers what it may access. Neither answers whether the AI should perform a particular action; in the above case only performs read-only access.

The capability question and the safeguard question are too often answered by different teams on different timelines. Security reviews that focus only on what the AI can access tend to miss the more revealing question of what it is permitted to do once that access exists. I have started treating those two questions as a single design problem, because every gap between them eventually surfaces as an incident.

I remember an architecture review where this became concrete. An employee asked an internal assistant — one built on Microsoft 365 and SharePoint — to summarize several incident reports, and during its reasoning the assistant discovered privileged administrative documentation in a linked site and decided it might also be useful to include those details. Nothing technically failed. The credentials were valid. The permissions were correct. Yet the outcome violated business intent. That moment reframed the conversation for everyone in the room. We realized our threat model had been built for outsiders trying to get in, not for authorized systems acting a little too helpfully. Closing that gap meant designing controls that evaluated behavior in context, not just credentials at the door, and it’s why I’ve come to view runtime governance as one of the defining security challenges of enterprise AI.

Organizations such as the OWASP GenAI Security Project and the NIST AI Risk Management Framework emphasize that AI risks extend well beyond authentication authorizations to include monitoring, governance and continuous oversight throughout execution. CSOonline’s coverage of agentic identity makes the same point: Existing controls weren’t designed for AI agents, and static credentials and standing privileges are no longer sufficient when organizations must rapidly authorize, limit and revoke permissions from autonomous agents, sometimes more than once within a single workflow.

The biggest failures rarely look like cyberattacks

Most security professionals naturally look for malicious activity: Prompt injection, data poisoning, credential theft, model manipulation. Those attacks certainly matter. What I’ve seen more frequently, however, are failures caused by legitimate AI behavior. A Finance, HR, Customer or risk management AI assistant retrieves more documents than necessary because it tries to provide a “better” answer. An autonomous workflow performs five approved actions instead of one. An AI agent continues executing after the user’s original intent has already been satisfied. None of these resemble traditional attacks, yet they may create compliance violations, privacy issues or operational disruption.

One mental model has consistently helped executives understand why this is so dangerous. I ask them to stop thinking about AI as software and instead think about it as hiring thousands of new digital employees, aka AI agents. Every employee receives training, limited access, monitoring, auditing and oversight. AI agents deserve the same treatment.

One deployment I worked on involved multiple specialized AI agents collaborating to complete a single business task. One queried ServiceNow for ticket history, another analyzed documents in SharePoint, a third drafted recommendations and a fourth wrote updates back into Jira. Individually, each agent had relatively limited permissions like read-only and/or write. Collectively, they represented a powerful autonomous workflow. That experience reinforced an important lesson: Security can no longer focus only on individual AI components. It must govern the complete chain of autonomous decision-making. The MITRE ATLAS framework is an excellent way to think about adversarial AI techniques, but equally important is understanding how normal autonomous behavior can unintentionally create business risk.

The most instructive cases I’ve seen involve agents that delegate to other agents. In one review, a frontline support agent had strictly read-only access to Salesforce, but it could hand tasks to a second agent that held write privileges across ServiceNow and the billing platform. When the first agent couldn’t resolve a customer issue within its own scope, it quietly routed the request through the second agent, which updated the case and issued a credit. Nothing was hacked. The credentials were valid, the delegation was technically permitted, and yet a read-only agent had effectively performed write actions it was never meant to perform. That is the defining difference between an assistant and an agent. An assistant answers; an agent enlists other agents, and that escalation path is itself the vulnerability.

That’s why we started asking a different question during architecture reviews. Instead of asking “Can the AI do this?” we asked, “Should the AI still be doing this?” That subtle shift changed many design decisions. It pushed teams to build in stopping conditions, scope checks and confirmation prompts rather than assuming an agent would naturally know when to stop. In one review, simply requiring a human to confirm before an agent crossed from a read-only step into a write action eliminated the majority of the risky paths we had been debating.

Start with governance before autonomy

One pattern I’ve repeatedly observed is that organizations become excited about autonomy long before they’re prepared to govern it. Everyone wants AI agents, but few initially invest in runtime policy enforcement. That sequencing should be reversed. In my experience, successful enterprise AI programs put a few foundations in place before expanding automation: Clear business boundaries that an agent isn’t allowed to cross, least-privilege access for every agent, and human approval at any step that touches sensitive/restricted data/systems, including the production data /systems. Only after those exist does it make sense to widen autonomous decision-making. I’ve watched teams try to shortcut this order, and the result is almost always the same: A promising pilot gets pulled back because no one can confidently explain what the AI did or why.

A big part of that foundation is visibility. Traditional audit logs record actions, but AI systems also need to record reasoning. When an AI agent creates a ticket, updates a configuration or sends an email, investigators should understand why the decision occurred. This doesn’t mean recording every token generated by a large language model. I’ve found more value in capturing three things: The original business request, the systems the agent touched and the decisions it made along the way. Those records become invaluable during investigations, compliance reviews and operational troubleshooting, and they help organizations build trust. Business leaders become far more comfortable adopting AI when they can explain how an important decision was reached. Approaches like Google’s Secure AI Framework reinforce the same idea: AI security has to be measurable, observable and accountable end to end.

One misconception I still encounter is that AI security exists to restrict innovation. In practice, the organizations moving fastest with enterprise AI are often the ones investing most heavily in governance, because executives gain confidence, developers move faster and business units adopt AI more broadly. Done well, security is what makes that speed possible.

Looking back, the most valuable lesson hasn’t been about prompt engineering, model selection or agent frameworks. It’s that secure AI isn’t achieved through one perfect control but through hundreds of small engineering decisions that keep autonomous systems aligned with business intent. As we move from assistants toward fully autonomous agents, that distinction only matters more. The teams I trust to scale AI aren’t the ones with the smartest models. They’re the ones who can answer, for any action an agent took, why it took it — and where it would have stopped.

The loudest conversation in business right now is about how much value AI actually generates. Over the last year, AI has moved from a side experiment to a strategic priority. It has its own budget line, its own place on the board’s agenda and its own pressure to show results. Every leader is asking a version of the same question: What are we getting back?

To answer it, most reach for the three measures they have always trusted to judge a technology:

• How much faster are we now?
• How much money has it saved us?
• How many of our people are using it?

Speed, cost and adoption were the right yardsticks for every major technology of the past two decades. They worked because the capability of traditional software was fixed and known on the day you deployed it. The tool did a defined job. Its value had a ceiling you could see, and each metric measured your progress toward that ceiling. Cost reduction told you how much you could save. Adoption told you how much of the capability you had rolled out. Speed told you how much of the promised acceleration was reaching the output.

In every case, the tool was a constant, and the metric measured how fully the organization had absorbed that constant.

These metrics are not working for AI. The reason starts with how AI entered our organizations.

Every technology before this was chosen somewhere above us, deployed to us and trained into us. By the time it arrived on our desks, someone had already decided what it was for. AI came the other way. It landed as a personal productivity tool. You opened a tab, typed a question and something useful came back. Nobody defined its capability in advance, because its capability is not fixed. What it produces depends on who is using it and how well. Metrics built for fixed capabilities have nothing stable to measure, and here is what happens when you apply them anyway.

Why speed, cost and adoption fail as AI evaluation metrics

Let’s start with speed. Task speed and business speed are different quantities, and AI only touches the former. Suppose a report that took eight hours now takes two. Your dashboard shows a 75% improvement. But the report still waits three days for review and a week for approval before anyone acts on it. The organization sees dramatic task-level gains but no movement in business results and concludes AI failed. The problem is the metric measuring a layer that was never the bottleneck.

Speed creates a second problem, and it is worse. Getting good output from AI requires checking it, correcting it and feeding those corrections back into how the tool is used. That work is slow. On any speed metric, it looks like inefficiency. So, people under speed pressure skip it. They accept output uncritically and produce more volume with less scrutiny.

Cost reduction has an arithmetic problem. If you frame AI as a way to reduce what you currently spend, your maximum possible win is your current spend. If your content team costs a million dollars, the best case in a cost frame is saving a million dollars. Every general-purpose technology has followed the same sequence: Efficiency gains came first, and the larger value came later, from work that did not exist before.

For AI, that means the analysis nobody had time for, the personalization no team could staff, the experiments too expensive to justify. A cost frame makes all of that invisible because new work doesn’t reduce anything. There is no column on the dashboard for things you couldn’t do last year.

Cost framing also works against its own inputs. AI improves through use by knowledgeable people. It needs their corrections, their context and their judgment about what good output looks like. When AI’s success is measured in headcount avoided, those people understand exactly what they are being asked to build: Their own replacement. They respond rationally. They use the tools shallowly and keep their expertise to themselves. The metric announces an intent, and the intent destroys the participation the technology depends on.

Adoption looks like the safest of the three. The problem is that adoption measures usage, and usage is not a value. Researchers at several central banks recently asked thousands of senior executives about this and heard the same two things from most of them: Yes, we use AI across the business, and no, it has not changed our results yet.

A thousand employees asking AI to shorten their emails will produce a spectacular adoption number and almost nothing else. Fifty employees using AI on judgment-heavy work, feeding it real context and checking its output against real standards, will barely register on the dashboard and generate most of the actual return. Adoption metrics cannot tell these two groups apart. Worse, they reward the shallow pattern. Shallow use is easy to spread, and deep use is hard, so an organization managed on adoption drifts toward the use that is easiest to count.

6 signals that track the real value

A few months ago, I realized the ROI question was aimed at the wrong object. Every company I compete with has access to the same models I do, at the same price. Whatever value comes from the model itself, my competitors receive too, so it cancels out any comparison between us. It cannot be an advantage, and it is not an interesting thing to measure. The only variable left is us. The standards, the context and the judgment we build around the model, because none of that arrives with the subscription and none of it can be bought. So, when I evaluate AI, I am evaluating my own organization and how quickly it turns a commodity everyone has into a capability only we have. The six signals below all measure that second thing.

1. Review burden is falling on the same class of work

Take any recurring task the organization runs through AI: Monthly reports, vendor evaluations, code review. Track how much human checking each unit of output needs, quarter over quarter. If a task needed a full senior review in January and needed a spot check in June, something real happened. The organization encoded its quality standards, improved its inputs and learned where the tool fails. If the review burden is flat, the organization is consuming AI, not compounding on it, no matter what the adoption dashboard says.

• How to measure it: Pick five recurring workflows, log review hours per output and plot the trend. The trend is the signal. The absolute number matters far less.

2. Corrections become shared fixes

When someone discovers that the AI gets something wrong, how long does it take for that discovery to become a shared fix? In a healthy system, one person’s correction becomes an updated prompt, a revised guideline or a documented example of good versus bad within days. Nobody else has to rediscover the same failure. In an unhealthy system, every employee privately learns the same lessons. The knowledge lives in individual chat histories, and it leaves with each departure.

• How to measure it: Sample recent corrections and trace them. Did they land anywhere reusable? How long did it take? An organization that cannot answer these questions at all has its answer.

3. The team does work that it could not do before

The largest returns from any general-purpose technology come from previously impossible work, not from old work done faster. So, look at the work itself. Is the organization doing the same portfolio of tasks faster, or is the portfolio expanding?

• How to measure it: Once a year, list what the team produces now that it did not and could not produce before. If the list is empty after a year of heavy AI use, the organization has been optimizing instead of expanding, and it is capturing the smallest slice of the available value.

4. The delegation boundary is moving

Every organization has an implicit line: Work AI does alone, work AI does with human review, work humans do entirely. Watch whether that line moves. Work that needed full human ownership last year and needs only oversight now is direct evidence of accumulated capability, clearer standards and earned trust. A frozen boundary means frozen capability.

• How to measure it: Make the implicit map explicit. Build a simple inventory of task types and their current delegation level, then re-score it quarterly. The change is the signal. It is also one of the few AI metrics a board can grasp intuitively: This category moved from full review to spot check, and here is what we built to make that safe.

5. Cost per verified outcome is falling

What does it cost, all in, to produce a unit of work you would actually ship: checked, corrected, done? All in means the subscription, the prompting time, the review time and the rework when errors slip through.

This number does two jobs. It exposes the true economics, which usually look worse than the dashboard claims early on, because the human labor around the tool costs more than the tool itself. And it gives you the one number that should fall over time if capability is genuinely accumulating, because encoded standards and better context reduce exactly those human hours.

• How to measure it: Instrument one workflow end-to-end, honestly, before generalizing. Most organizations have never done this once.

6. Use is getting deeper, not just wider

Adoption metrics count users. This signal counts the nature of use. Shallow use, such as rewriting emails and summarizing documents, spreads fast and produces little. Deep use, where AI is applied to judgment-heavy work with real context and real evaluation, spreads slowly and produces most of the return.

• How to measure it: Classify actual usage into shallow and deep, even roughly, and track the ratio. Fifty deep users beat a thousand shallow ones, and only this signal can tell you which group you have.

Two cautions

First, any of these signals can be gamed once it becomes a target. This is Goodhart’s Law. The review burden can fall because people simply review less. So, pair every efficiency signal with a quality check, such as error rates, rework and downstream complaints.

Second, expect the early numbers to look bad. Honest instrumentation usually shows that AI currently costs more per verified outcome than the old process, because the organization is still paying its learning costs.

Final thoughts

I am not saying AI is overhyped, and I am not saying speed, cost and adoption will never matter. Every real gain eventually shows up in those numbers. I am saying they show up last because they are the output of a learning process, not the process itself. Judge AI by them today, and you will make your keep-or-kill decisions years before the evidence arrives.

If I could track only one thing, it would be the delegation boundary. It compresses everything else into a single observable fact. The boundary only moves when context has been encoded, standards have been made explicit, corrections have been institutionalized and trust has been earned through verified results. It is the output yardstick of the entire learning system. If this has not moved in a year, no other number on the dashboard means anything, however green it looks.

Measure the learning, and the returns will follow. Measure only the returns, and you may kill the learning that produces them.

The loudest conversation in business right now is about how much value AI actually generates. Over the last year, AI has moved from a side experiment to a strategic priority. It has its own budget line, its own place on the board’s agenda and its own pressure to show results. Every leader is asking a version of the same question: What are we getting back?

To answer it, most reach for the three measures they have always trusted to judge a technology:

• How much faster are we now?
• How much money has it saved us?
• How many of our people are using it?

Speed, cost and adoption were the right yardsticks for every major technology of the past two decades. They worked because the capability of traditional software was fixed and known on the day you deployed it. The tool did a defined job. Its value had a ceiling you could see, and each metric measured your progress toward that ceiling. Cost reduction told you how much you could save. Adoption told you how much of the capability you had rolled out. Speed told you how much of the promised acceleration was reaching the output.

In every case, the tool was a constant, and the metric measured how fully the organization had absorbed that constant.

These metrics are not working for AI. The reason starts with how AI entered our organizations.

Every technology before this was chosen somewhere above us, deployed to us and trained into us. By the time it arrived on our desks, someone had already decided what it was for. AI came the other way. It landed as a personal productivity tool. You opened a tab, typed a question and something useful came back. Nobody defined its capability in advance, because its capability is not fixed. What it produces depends on who is using it and how well. Metrics built for fixed capabilities have nothing stable to measure, and here is what happens when you apply them anyway.

Why speed, cost and adoption fail as AI evaluation metrics

Let’s start with speed. Task speed and business speed are different quantities, and AI only touches the former. Suppose a report that took eight hours now takes two. Your dashboard shows a 75% improvement. But the report still waits three days for review and a week for approval before anyone acts on it. The organization sees dramatic task-level gains but no movement in business results and concludes AI failed. The problem is the metric measuring a layer that was never the bottleneck.

Speed creates a second problem, and it is worse. Getting good output from AI requires checking it, correcting it and feeding those corrections back into how the tool is used. That work is slow. On any speed metric, it looks like inefficiency. So, people under speed pressure skip it. They accept output uncritically and produce more volume with less scrutiny.

Cost reduction has an arithmetic problem. If you frame AI as a way to reduce what you currently spend, your maximum possible win is your current spend. If your content team costs a million dollars, the best case in a cost frame is saving a million dollars. Every general-purpose technology has followed the same sequence: Efficiency gains came first, and the larger value came later, from work that did not exist before.

For AI, that means the analysis nobody had time for, the personalization no team could staff, the experiments too expensive to justify. A cost frame makes all of that invisible because new work doesn’t reduce anything. There is no column on the dashboard for things you couldn’t do last year.

Cost framing also works against its own inputs. AI improves through use by knowledgeable people. It needs their corrections, their context and their judgment about what good output looks like. When AI’s success is measured in headcount avoided, those people understand exactly what they are being asked to build: Their own replacement. They respond rationally. They use the tools shallowly and keep their expertise to themselves. The metric announces an intent, and the intent destroys the participation the technology depends on.

Adoption looks like the safest of the three. The problem is that adoption measures usage, and usage is not a value. Researchers at several central banks recently asked thousands of senior executives about this and heard the same two things from most of them: Yes, we use AI across the business, and no, it has not changed our results yet.

A thousand employees asking AI to shorten their emails will produce a spectacular adoption number and almost nothing else. Fifty employees using AI on judgment-heavy work, feeding it real context and checking its output against real standards, will barely register on the dashboard and generate most of the actual return. Adoption metrics cannot tell these two groups apart. Worse, they reward the shallow pattern. Shallow use is easy to spread, and deep use is hard, so an organization managed on adoption drifts toward the use that is easiest to count.

6 signals that track the real value

A few months ago, I realized the ROI question was aimed at the wrong object. Every company I compete with has access to the same models I do, at the same price. Whatever value comes from the model itself, my competitors receive too, so it cancels out any comparison between us. It cannot be an advantage, and it is not an interesting thing to measure. The only variable left is us. The standards, the context and the judgment we build around the model, because none of that arrives with the subscription and none of it can be bought. So, when I evaluate AI, I am evaluating my own organization and how quickly it turns a commodity everyone has into a capability only we have. The six signals below all measure that second thing.

1. Review burden is falling on the same class of work

Take any recurring task the organization runs through AI: Monthly reports, vendor evaluations, code review. Track how much human checking each unit of output needs, quarter over quarter. If a task needed a full senior review in January and needed a spot check in June, something real happened. The organization encoded its quality standards, improved its inputs and learned where the tool fails. If the review burden is flat, the organization is consuming AI, not compounding on it, no matter what the adoption dashboard says.

• How to measure it: Pick five recurring workflows, log review hours per output and plot the trend. The trend is the signal. The absolute number matters far less.

2. Corrections become shared fixes

When someone discovers that the AI gets something wrong, how long does it take for that discovery to become a shared fix? In a healthy system, one person’s correction becomes an updated prompt, a revised guideline or a documented example of good versus bad within days. Nobody else has to rediscover the same failure. In an unhealthy system, every employee privately learns the same lessons. The knowledge lives in individual chat histories, and it leaves with each departure.

• How to measure it: Sample recent corrections and trace them. Did they land anywhere reusable? How long did it take? An organization that cannot answer these questions at all has its answer.

3. The team does work that it could not do before

The largest returns from any general-purpose technology come from previously impossible work, not from old work done faster. So, look at the work itself. Is the organization doing the same portfolio of tasks faster, or is the portfolio expanding?

• How to measure it: Once a year, list what the team produces now that it did not and could not produce before. If the list is empty after a year of heavy AI use, the organization has been optimizing instead of expanding, and it is capturing the smallest slice of the available value.

4. The delegation boundary is moving

Every organization has an implicit line: Work AI does alone, work AI does with human review, work humans do entirely. Watch whether that line moves. Work that needed full human ownership last year and needs only oversight now is direct evidence of accumulated capability, clearer standards and earned trust. A frozen boundary means frozen capability.

• How to measure it: Make the implicit map explicit. Build a simple inventory of task types and their current delegation level, then re-score it quarterly. The change is the signal. It is also one of the few AI metrics a board can grasp intuitively: This category moved from full review to spot check, and here is what we built to make that safe.

5. Cost per verified outcome is falling

What does it cost, all in, to produce a unit of work you would actually ship: checked, corrected, done? All in means the subscription, the prompting time, the review time and the rework when errors slip through.

This number does two jobs. It exposes the true economics, which usually look worse than the dashboard claims early on, because the human labor around the tool costs more than the tool itself. And it gives you the one number that should fall over time if capability is genuinely accumulating, because encoded standards and better context reduce exactly those human hours.

• How to measure it: Instrument one workflow end-to-end, honestly, before generalizing. Most organizations have never done this once.

6. Use is getting deeper, not just wider

Adoption metrics count users. This signal counts the nature of use. Shallow use, such as rewriting emails and summarizing documents, spreads fast and produces little. Deep use, where AI is applied to judgment-heavy work with real context and real evaluation, spreads slowly and produces most of the return.

• How to measure it: Classify actual usage into shallow and deep, even roughly, and track the ratio. Fifty deep users beat a thousand shallow ones, and only this signal can tell you which group you have.

Two cautions

First, any of these signals can be gamed once it becomes a target. This is Goodhart’s Law. The review burden can fall because people simply review less. So, pair every efficiency signal with a quality check, such as error rates, rework and downstream complaints.

Second, expect the early numbers to look bad. Honest instrumentation usually shows that AI currently costs more per verified outcome than the old process, because the organization is still paying its learning costs.

Final thoughts

I am not saying AI is overhyped, and I am not saying speed, cost and adoption will never matter. Every real gain eventually shows up in those numbers. I am saying they show up last because they are the output of a learning process, not the process itself. Judge AI by them today, and you will make your keep-or-kill decisions years before the evidence arrives.

If I could track only one thing, it would be the delegation boundary. It compresses everything else into a single observable fact. The boundary only moves when context has been encoded, standards have been made explicit, corrections have been institutionalized and trust has been earned through verified results. It is the output yardstick of the entire learning system. If this has not moved in a year, no other number on the dashboard means anything, however green it looks.

Measure the learning, and the returns will follow. Measure only the returns, and you may kill the learning that produces them.

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.