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.

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

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

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

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

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

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

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

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

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

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

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

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

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

User consent when recording calls

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

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

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

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

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

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

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

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

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

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

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

That is a security question.

The trust boundary has moved

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

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

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

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

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

The business impact is not theoretical

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

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

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

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

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

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

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

Vendor reputation does not transfer to every AI feature

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

But AI features can change the architecture of risk.

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

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

The ownership gap is the real vulnerability

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

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

In many organizations, the honest answer is unclear.

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

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

What CIOs should require now

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

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

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

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

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

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

The hiring platform is now part of the enterprise attack surface

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

That makes it a CIO concern.

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

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

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

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

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

The product builder: The OG Palantir version

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

The platform operator: Solutions + technical customer success

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

Which FDE is right for you

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

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

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

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

1. You have very large customers (F500 scale)

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

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

2. You have many ICPs and workflows

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

Note: see Palantir Foundry’s architecture here.

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

Who you should hire

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

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

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

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

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

What FDEs should be doing (regardless of archetype)

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

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

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

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

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

From automation to hyperautomation in banking applications

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

Figure: Automation vs. hyperautomation

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

Banking application components suitable for hyperautomation

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

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

Embedded generative AI as an application capability

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

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

Hyperautomating the product development lifecycle

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

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

Role of GitHub Copilot, Claude Cowork and Codex

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

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

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

Integration architecture for hyperautomated banking applications

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

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

Example: Hyperautomated reconciliation and reporting flow

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

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

Governance, risk and control considerations

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

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

Operating model for AI-native PDLC

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

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

Conclusion

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

User consent when recording calls

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

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

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

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

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

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

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

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

The product builder: The OG Palantir version

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

The platform operator: Solutions + technical customer success

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

Which FDE is right for you

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

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

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

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

1. You have very large customers (F500 scale)

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

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

2. You have many ICPs and workflows

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

Note: see Palantir Foundry’s architecture here.

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

Who you should hire

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

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

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

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

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

What FDEs should be doing (regardless of archetype)

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

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

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

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

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

From automation to hyperautomation in banking applications

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

Figure: Automation vs. hyperautomation

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

Banking application components suitable for hyperautomation

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

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

Embedded generative AI as an application capability

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

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

Hyperautomating the product development lifecycle

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

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

Role of GitHub Copilot, Claude Cowork and Codex

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

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

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

Integration architecture for hyperautomated banking applications

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

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

Example: Hyperautomated reconciliation and reporting flow

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

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

Governance, risk and control considerations

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

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

Operating model for AI-native PDLC

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

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

Conclusion

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

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

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

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

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

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

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

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

That is a security question.

The trust boundary has moved

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

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

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

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

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

The business impact is not theoretical

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

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

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

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

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

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

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

Vendor reputation does not transfer to every AI feature

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

But AI features can change the architecture of risk.

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

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

The ownership gap is the real vulnerability

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

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

In many organizations, the honest answer is unclear.

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

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

What CIOs should require now

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

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

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

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

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

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

The hiring platform is now part of the enterprise attack surface

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

That makes it a CIO concern.

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

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

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

Huntress has documented a case where the Oracle database itself became the malware host.

The security firm disclosed a campaign in which threat actors exploited a SQL injection vulnerability to store a custom post-exploitation toolkit, dubbed Khunt, inside an Oracle database using the platform’s built-in Java capabilities.

Huntress became aware of the intrusion after investigating a credential theft activity on a server running Oracle Database. The researchers learned that rather than simply executing commands through SQL injection, the attackers had leveraged Oracle’s embedded Java Virtual Machine (OJVM) to upload, compile, and execute malicious Java code directly from within the database.

The approach reportedly allowed the attackers to blend into legitimate database functionality while maintaining a persistent foothold on the compromised server.

“The attackers managed to gain initial access in this attack thanks to a classic SQL injection,” Huntress researchers said in a blog post. “There was no need for a novel vulnerability because the autocomplete search feature in the public-facing application was enough to reach PL/SQL and then the operating system.”

Exploitation beyond SQL injection

The attack revolved around Khunt, a Java-based toolkit that attackers stored as a database object using Oracle’s “CREATE JAVA SOURCE” functionality. Oracle Database includes an embedded Java Virtual Machine that allows organizations to execute Java code from within the database for legitimate business applications.

Once compiled inside the database, the Java code could be run through SQL statements to execute operating system commands on the underlying host where Oracle was configured. The malware inserted within the database schema would be considerably harder to detect, Huntress noted.

After setting up the code execution path from within the database, the attackers could (and did) carry out post-compromise activities, including credential theft.

In the incident Huntress investigated, the attackers ultimately compromised the Windows server hosting Oracle Database, escalating from SQL injection to SYSTEM-level command execution. With that level of access, they were able to dump the Windows SAM, SECURITY, and SYSTEM registry hives, enabling offline extraction of local account password hashes.

The campaign’s non-reliance on noisy malware binaries and incorporation of the malice entirely within Oracle’s native functionality was flagged by researchers as an evolved operation that calls for targeted detection.

Oracle did not immediately respond to CSO’s requests for comment.

Mitigation focused on post-exploitation toolkit 

While the SQL injection pathway provided the initial foothold, Huntress argues that the more important lesson lies in what happened after exploitation.

The attackers could have simply extracted or manipulated data through SQL injection, but instead, they expanded the exploit to include long-term persistence and remote command execution. Huntress warned that this is a dangerous evolution.

Features such as Oracle’s embedded JVM, while valuable for enterprise workloads, can also expand the blast radius with sufficient database privileges. “To avoid these types of attacks, it is important to ensure the forms aren’t injectable,” the researchers said. “It’s also important to ensure that users with the ability to execute queries aren’t overprovisioned.”

Huntress recommended looking beyond indicators of SQL injection during incident response. Examining Oracle environments for unexpected Java source objects, compiled Java classes, and stored procedures could indicate abuse of the embedded Java Virtual Machine, it said. The firm also shared indicators of compromise (IOCs), including file hashes, malicious Java artifacts, SQL statements, and search terms to help defenders identify affected systems.

The scheduling fallacy and the shift to autonomy

Walk onto almost any manufacturing shop floor, and you will witness the same systemic vulnerability: a brilliantly engineered, multi-million-dollar Advanced Planning and Scheduling (APS) system rendered completely useless by a single delayed delivery truck, an unexpected machine drift or a sudden workforce shortage. Industrial operations do not happen in a sterile room; the moment a perfect plan hits the messy reality of the physical shop floor, real-world variables inevitably shatter it.

This is the scenario (or challenge) that I have been navigating over the past few months and is likely to keep me occupied for the remainder of the year. I began this project believing the scheduling engine was the problem. After months of experimentation, including trying to make LLMs perform optimization, I realized I was solving the wrong problem. The realization that dawned on me was that it wasn’t about a better algorithm; it was about separating mathematical optimization from operational reasoning.

According to the 2026 Gartner Manufacturing Predicts report, factory orchestration is moving rapidly toward a “double helix” model where software-defined enterprise data intricately intertwines with autonomous production orchestration. Gartner also projects that 40% of enterprise applications will feature integrated, task-specific AI agents by the end of 2026 — a massive leap from less than 5% in 2025. For technology leaders, the mandate is clear.

Deconstructing the “reasoning layer”

Let’s first demystify what a “Reasoning Layer” is and what it is not. It is not a Generative AI nor is it a glorified Robotic Process Automation (RPA) script executing static, hardcoded logic. Instead, the Reasoning Layer is a cognitive overlay powered by foundation models. These models have been fine-tuned on operational ontologies, enterprise supply chain strategies and real-time shop-floor data streams. Pretty much everything that happens in your organization and, in many cases, outside as well, as some decisions are impacted by the prevailing external situation.

A reasoning layer continuously answers a complex question: Given this specific disruption, what is the optimal business choice right now?

The dual-engine architecture: Math meets cognition

A common pitfall has been to expect an LLM to handle both. That was the blunder I committed was to assume that a sufficiently trained LLM can get the job done.

The true breakthrough in designing a production-grade scheduling application lies in pairing semantic intelligence with raw mathematical muscle.

To solve this, what I discovered was that you need to split it into two layers. A number-crunching mathematical layer and a qualitative layer. Both working in sync.  

1. The quantitative engine: Global pathfinding, sequence optimization and multi-plant capacity balancing are treated as a highly complex routing problem. Ant Colony Optimization (ACO) algorithm, for example, excels here. It can navigate massive combinatorial data spaces to find optimal/near-optimal scheduling sequences across interdependent lines. A word of caution though: This requires good quality data and lots of it.
2. The qualitative brain (agentic AI): The AI agent serves as the dynamic coordinator. It monitors the operational environment for live telemetry anomalies (such as machine cycle-time drifts or supply chain delays). When an anomaly occurs, the agent evaluates the business impact. Determines whether a re-optimization is required and crucially rewrites the constraints and boundary conditions before triggering the ACO engine.

By using the Agentic Layer to bound the mathematical problem, the system avoids the fatal flaw of traditional advanced planning tools: completely rewriting a global schedule over a minor local exception.

The multi-plant orchestration paradox

When a manufacturing organization expands from a single facility to a distributed, multi-plant network, operational complexity does not scale linearly — it scales exponentially. In theory, a multi-plant footprint should provide an enterprise with built-in resilience, giving leadership the flexibility to shift production loads when disruptions strike. Most manufacturing organizations suffer from the multi-plant orchestration paradox: they possess massive regional capacity but are structurally blind to how to leverage it dynamically.

The root cause of this paradox is the historical legacy corporate silo. If a plant in Chennai faces a sudden logistics bottleneck or a critical machine breakdown, its local team scrambles in isolation. Meanwhile, a sister plant in Pune operates completely unaware that it possesses the excess capacity, specific tooling or material buffers required to absorb the overflow.

By the time information filters up to corporate logistics and decisions are taken, you would have lost precious capacity and time.

Enter MAGS: The rise of agent-to-agent collaboration

To shatter these corporate silos, the reasoning layer must expand past local optimizations and facilitate cross-facility orchestration. This shift is driven by a distinct architectural evolution: Multi-agent generative systems (MAGS). Gartner highlights the rapid acceleration of this trend, predicting that by 2027, one-third of all agentic AI implementations will focus heavily on autonomous agent-to-agent collaboration.

In a MAGS framework, the scheduling agents of individual plants do not operate in a vacuum. Instead, they form an interconnected, distributed network capable of autonomous negotiation. The architectural flow of this cross-facility negotiation occurs across three distinct phases:

• Perception: Local plant agents continuously ingest live IIoT telemetry, tracking real-time machine interdependencies, resource pooling variances and material transit times across physical transport lanes.
• Interpretation: When an anomaly occurs, the local agent instantly evaluates the disruption against localized business constraints.
• Negotiation: Rather than escalating every minor bottleneck to a human director, Plant A’s scheduling agent connects directly to Plant B’s agent over the secure network. The agents cross-negotiate load-balancing options, evaluate transportation lead times and run localized optimization calculations in parallel.

Instead of forcing supply chain teams to manually bridge data gaps during a crisis, the system bypasses legacy functional silos. It presents the COO’s operations team with a pre-validated, end-to-end scheduling solution.

Real-world applications: Grounding autonomy in industrial reality

To understand how this functions in the real world, we must look beyond theoretical multi-agent frameworks and examine how this architecture operates within live factories. The following two case studies—drawn from highly documented, peer-reviewed industrial implementations — demonstrate how multi-agent generative systems (MAGS) actively protect margins and timelines when unexpected disruptions strike.

Case study 1: The discrete architecture (The Festo cyber-physical agent framework)

• The context: This architecture is modeled after the landmark decentralized orchestration frameworks deployed at Festo’s Scharnhausen Technology Plant. Instead of relying on a centralized ERP/MES brain to dictate every move, the facility utilizes cyber-physical systems (CPS) where the physical components and machines operate as an interconnected multi-agent system (MAS).
• The disruption: During a high-volume discrete run of automation components, a critical machining center suffering an unexpected tooling failure, in a traditional centralized setup, would have triggered a cascade of line stoppages.
• The intervention: The affected machine’s resource agent instantly broadcasts its downtime status across the network. The task agents ingest the anomaly and independently query neighboring machining cells. The setup utilizes an underlying ACO routing routine to calculate the most efficient physical path through alternative, under-utilized cells. The Task Agents actively barter for open capacity with these alternative resource agents, dynamically adjusting their own operational sequences.

Case study 2: The process pivot (The TU Dresden battery manufacturing framework)

• The context: This case is drawn directly from a multi-layer agent-based framework engineered for a European lead-acid battery manufacturer in coordination with researchers at TU Dresden. The environment features 31 highly energy-intensive heat-treatment and curing chambers, where localized utility tariff volatility drastically impacts production margins. Continuous chemical process lines cannot simply be shut down without massive material waste and lengthy restart sequences.
• The disruption: A sudden, localized weather event triggers an unpredicted spike in peak-load electricity pricing, threatening to entirely erase the profit margin on a high-volume production run.
• The intervention: To solve this, the plant utilized a multi-layer agent-based framework. An energy-monitoring agent tracking live utility tariff feeds communicated the financial threat directly to the production scheduling agent. Instead of a crude emergency halt, the reasoning layer queried the facility’s computerized maintenance management system (CMMS). The agentic layer identified a mandatory 4-hour preventative maintenance window scheduled for three days later. The agent made an executive operational decision: it pulled that maintenance window forward to occur during the exact hours of peak utility pricing, converting an expensive tariff penalty into required downtime. Simultaneously, lower-level agents representing the individual curing chambers and material pallets recalculated local constraints, instructing the optimization engine to compress and accelerate subsequent production batches during the cheaper, off-peak night shifts.

The business outcome

In both cases, the agents optimized an operational pivot, and optimally utilised production capacity in the former and saved precious cash in the latter.

Governance, trust and the “human-in-the-loop” guardrails

All that seems great and seems like science fiction; it inevitably raises a critical, polarizing question for the C-suite: If the algorithms are making multi-thousand-dollar operational choices in real time, how do we maintain control?

The solution to this executive anxiety is a framework defined as “autonomy within boundaries,” executed through policy-as-code. Under this model, operational leaders stop managing the volatility of daily schedules. Instead, they focus on creating and managing policy boundaries within which the agents are permitted to negotiate and self-heal.

This splits operational exceptions into 2 zones:

• Autonomous execution zone: The multi-agent system has full authority to re-sequence lines, re-route components or shift maintenance windows autonomously, provided the financial & operational impact is under a predefined limit.  
• Expert advisory zone: The moment a proposed optimization breaches either of these metrics, the agent pushes it to an executive dashboard for immediate human intervention, validation and approval.

This dual-layer approach introduces a reliable operational framework to industrial manufacturing: leadership manages strategic intent, while tactical units manage real-time execution.

By establishing clear thresholds, the fear of an algorithmic “runaway train” is entirely mitigated. However, deploying a complete multi-agent governance framework across an entire enterprise footprint cannot happen overnight.

To move this from my serendipitous but compelling discovery to a live, risk-mitigated environment, I need a highly controlled, phased deployment strategy, an actionable roadmap to pilot, test and scale the reasoning layer without disrupting current production baselines.

We often say Industry 4.0 connected machines. I believe Industry 5.0 will connect decisions. The factories that succeed will not simply automate workflows; they will build systems capable of reasoning within clearly defined operational boundaries.

I am therefore not writing a conclusion here. I would probably be back in a few months writing about the outcome of this exercise. Somehow deep-down I suspect it would be less oriented to technology but how the change management progressed. I have a strong feeling that “…operational leaders stop managing the volatility of daily schedules. Instead, they focus on creating and managing policy boundaries …” would be the toughest part of this change.   

The scheduling fallacy and the shift to autonomy

Walk onto almost any manufacturing shop floor, and you will witness the same systemic vulnerability: a brilliantly engineered, multi-million-dollar Advanced Planning and Scheduling (APS) system rendered completely useless by a single delayed delivery truck, an unexpected machine drift or a sudden workforce shortage. Industrial operations do not happen in a sterile room; the moment a perfect plan hits the messy reality of the physical shop floor, real-world variables inevitably shatter it.

This is the scenario (or challenge) that I have been navigating over the past few months and is likely to keep me occupied for the remainder of the year. I began this project believing the scheduling engine was the problem. After months of experimentation, including trying to make LLMs perform optimization, I realized I was solving the wrong problem. The realization that dawned on me was that it wasn’t about a better algorithm; it was about separating mathematical optimization from operational reasoning.

According to the 2026 Gartner Manufacturing Predicts report, factory orchestration is moving rapidly toward a “double helix” model where software-defined enterprise data intricately intertwines with autonomous production orchestration. Gartner also projects that 40% of enterprise applications will feature integrated, task-specific AI agents by the end of 2026 — a massive leap from less than 5% in 2025. For technology leaders, the mandate is clear.

Deconstructing the “reasoning layer”

Let’s first demystify what a “Reasoning Layer” is and what it is not. It is not a Generative AI nor is it a glorified Robotic Process Automation (RPA) script executing static, hardcoded logic. Instead, the Reasoning Layer is a cognitive overlay powered by foundation models. These models have been fine-tuned on operational ontologies, enterprise supply chain strategies and real-time shop-floor data streams. Pretty much everything that happens in your organization and, in many cases, outside as well, as some decisions are impacted by the prevailing external situation.

A reasoning layer continuously answers a complex question: Given this specific disruption, what is the optimal business choice right now?

The dual-engine architecture: Math meets cognition

A common pitfall has been to expect an LLM to handle both. That was the blunder I committed was to assume that a sufficiently trained LLM can get the job done.

The true breakthrough in designing a production-grade scheduling application lies in pairing semantic intelligence with raw mathematical muscle.

To solve this, what I discovered was that you need to split it into two layers. A number-crunching mathematical layer and a qualitative layer. Both working in sync.  

1. The quantitative engine: Global pathfinding, sequence optimization and multi-plant capacity balancing are treated as a highly complex routing problem. Ant Colony Optimization (ACO) algorithm, for example, excels here. It can navigate massive combinatorial data spaces to find optimal/near-optimal scheduling sequences across interdependent lines. A word of caution though: This requires good quality data and lots of it.
2. The qualitative brain (agentic AI): The AI agent serves as the dynamic coordinator. It monitors the operational environment for live telemetry anomalies (such as machine cycle-time drifts or supply chain delays). When an anomaly occurs, the agent evaluates the business impact. Determines whether a re-optimization is required and crucially rewrites the constraints and boundary conditions before triggering the ACO engine.

By using the Agentic Layer to bound the mathematical problem, the system avoids the fatal flaw of traditional advanced planning tools: completely rewriting a global schedule over a minor local exception.

The multi-plant orchestration paradox

When a manufacturing organization expands from a single facility to a distributed, multi-plant network, operational complexity does not scale linearly — it scales exponentially. In theory, a multi-plant footprint should provide an enterprise with built-in resilience, giving leadership the flexibility to shift production loads when disruptions strike. Most manufacturing organizations suffer from the multi-plant orchestration paradox: they possess massive regional capacity but are structurally blind to how to leverage it dynamically.

The root cause of this paradox is the historical legacy corporate silo. If a plant in Chennai faces a sudden logistics bottleneck or a critical machine breakdown, its local team scrambles in isolation. Meanwhile, a sister plant in Pune operates completely unaware that it possesses the excess capacity, specific tooling or material buffers required to absorb the overflow.

By the time information filters up to corporate logistics and decisions are taken, you would have lost precious capacity and time.

Enter MAGS: The rise of agent-to-agent collaboration

To shatter these corporate silos, the reasoning layer must expand past local optimizations and facilitate cross-facility orchestration. This shift is driven by a distinct architectural evolution: Multi-agent generative systems (MAGS). Gartner highlights the rapid acceleration of this trend, predicting that by 2027, one-third of all agentic AI implementations will focus heavily on autonomous agent-to-agent collaboration.

In a MAGS framework, the scheduling agents of individual plants do not operate in a vacuum. Instead, they form an interconnected, distributed network capable of autonomous negotiation. The architectural flow of this cross-facility negotiation occurs across three distinct phases:

• Perception: Local plant agents continuously ingest live IIoT telemetry, tracking real-time machine interdependencies, resource pooling variances and material transit times across physical transport lanes.
• Interpretation: When an anomaly occurs, the local agent instantly evaluates the disruption against localized business constraints.
• Negotiation: Rather than escalating every minor bottleneck to a human director, Plant A’s scheduling agent connects directly to Plant B’s agent over the secure network. The agents cross-negotiate load-balancing options, evaluate transportation lead times and run localized optimization calculations in parallel.

Instead of forcing supply chain teams to manually bridge data gaps during a crisis, the system bypasses legacy functional silos. It presents the COO’s operations team with a pre-validated, end-to-end scheduling solution.

Real-world applications: Grounding autonomy in industrial reality

To understand how this functions in the real world, we must look beyond theoretical multi-agent frameworks and examine how this architecture operates within live factories. The following two case studies—drawn from highly documented, peer-reviewed industrial implementations — demonstrate how multi-agent generative systems (MAGS) actively protect margins and timelines when unexpected disruptions strike.

Case study 1: The discrete architecture (The Festo cyber-physical agent framework)

• The context: This architecture is modeled after the landmark decentralized orchestration frameworks deployed at Festo’s Scharnhausen Technology Plant. Instead of relying on a centralized ERP/MES brain to dictate every move, the facility utilizes cyber-physical systems (CPS) where the physical components and machines operate as an interconnected multi-agent system (MAS).
• The disruption: During a high-volume discrete run of automation components, a critical machining center suffering an unexpected tooling failure, in a traditional centralized setup, would have triggered a cascade of line stoppages.
• The intervention: The affected machine’s resource agent instantly broadcasts its downtime status across the network. The task agents ingest the anomaly and independently query neighboring machining cells. The setup utilizes an underlying ACO routing routine to calculate the most efficient physical path through alternative, under-utilized cells. The Task Agents actively barter for open capacity with these alternative resource agents, dynamically adjusting their own operational sequences.

Case study 2: The process pivot (The TU Dresden battery manufacturing framework)

• The context: This case is drawn directly from a multi-layer agent-based framework engineered for a European lead-acid battery manufacturer in coordination with researchers at TU Dresden. The environment features 31 highly energy-intensive heat-treatment and curing chambers, where localized utility tariff volatility drastically impacts production margins. Continuous chemical process lines cannot simply be shut down without massive material waste and lengthy restart sequences.
• The disruption: A sudden, localized weather event triggers an unpredicted spike in peak-load electricity pricing, threatening to entirely erase the profit margin on a high-volume production run.
• The intervention: To solve this, the plant utilized a multi-layer agent-based framework. An energy-monitoring agent tracking live utility tariff feeds communicated the financial threat directly to the production scheduling agent. Instead of a crude emergency halt, the reasoning layer queried the facility’s computerized maintenance management system (CMMS). The agentic layer identified a mandatory 4-hour preventative maintenance window scheduled for three days later. The agent made an executive operational decision: it pulled that maintenance window forward to occur during the exact hours of peak utility pricing, converting an expensive tariff penalty into required downtime. Simultaneously, lower-level agents representing the individual curing chambers and material pallets recalculated local constraints, instructing the optimization engine to compress and accelerate subsequent production batches during the cheaper, off-peak night shifts.

The business outcome

In both cases, the agents optimized an operational pivot, and optimally utilised production capacity in the former and saved precious cash in the latter.

Governance, trust and the “human-in-the-loop” guardrails

All that seems great and seems like science fiction; it inevitably raises a critical, polarizing question for the C-suite: If the algorithms are making multi-thousand-dollar operational choices in real time, how do we maintain control?

The solution to this executive anxiety is a framework defined as “autonomy within boundaries,” executed through policy-as-code. Under this model, operational leaders stop managing the volatility of daily schedules. Instead, they focus on creating and managing policy boundaries within which the agents are permitted to negotiate and self-heal.

This splits operational exceptions into 2 zones:

• Autonomous execution zone: The multi-agent system has full authority to re-sequence lines, re-route components or shift maintenance windows autonomously, provided the financial & operational impact is under a predefined limit.  
• Expert advisory zone: The moment a proposed optimization breaches either of these metrics, the agent pushes it to an executive dashboard for immediate human intervention, validation and approval.

This dual-layer approach introduces a reliable operational framework to industrial manufacturing: leadership manages strategic intent, while tactical units manage real-time execution.

By establishing clear thresholds, the fear of an algorithmic “runaway train” is entirely mitigated. However, deploying a complete multi-agent governance framework across an entire enterprise footprint cannot happen overnight.

To move this from my serendipitous but compelling discovery to a live, risk-mitigated environment, I need a highly controlled, phased deployment strategy, an actionable roadmap to pilot, test and scale the reasoning layer without disrupting current production baselines.

We often say Industry 4.0 connected machines. I believe Industry 5.0 will connect decisions. The factories that succeed will not simply automate workflows; they will build systems capable of reasoning within clearly defined operational boundaries.

I am therefore not writing a conclusion here. I would probably be back in a few months writing about the outcome of this exercise. Somehow deep-down I suspect it would be less oriented to technology but how the change management progressed. I have a strong feeling that “…operational leaders stop managing the volatility of daily schedules. Instead, they focus on creating and managing policy boundaries …” would be the toughest part of this change.   

Ein Freelance-Entwickler präsentiert sich mit tadellosem Lebenslauf, sauberem Portfolio und überzeugendem Video-Interview. Trotzdem sitzt am anderen Ende kein einzelner Kandidat, sondern ein Glied in einem staatlich gelenkten Betrugsnetzwerk. Was nach Spionagefilm klingt, hat sich zu einem konkreten Insider-Risiko für Unternehmen entwickelt.

Seit Jahren schleusen nordkoreanische Netzwerke IT-Fachkräfte mit falschen, gestohlenen oder geliehenen Identitäten in westliche Unternehmen ein, meist als Remote-Freelancer für Softwareentwicklung, Datenbanken, Cloud-Administration oder App-Projekte. Behörden sprechen von Tausenden weltweit eingesetzten Arbeitskräften.

Wie groß einzelne Netzwerke werden können, zeigen inzwischen abgeschlossene Strafverfahren: In einem Fall wurden 309 US-Unternehmen und zwei internationale Firmen getäuscht; das Netzwerk erwirtschaftete mehr als 17 Millionen US-Dollar. Im April 2026 wurden zwei weitere Helfer verurteilt, deren Struktur mit gestohlenen Identitäten Jobs bei mehr als 100 Unternehmen erlangte und über fünf Millionen US-Dollar einnahm.

Für CIOs ist das kein akademisches Risiko. Wer regulär eingestellt wurde, erhält reguläre Zugangsdaten und damit unter Umständen Zugriff auf Quellcode, Kundendaten, Entwicklungsumgebungen oder interne Wissensbestände. Genau das macht den Fall gefährlich: Technisch sieht der Zugriff zunächst legitim aus, obwohl Identität, Standort und Zweck der Tätigkeit falsch sein können.

Wie das Schema funktioniert

Die Struktur ist arbeitsteilig. IT-Fachkräfte übernehmen die eigentliche Projektarbeit. Rekruter suchen passende Stellen, Mittelsleute beschaffen Identitäten und Konten, andere Personen treten in Interviews auf oder wickeln Verträge und Zahlungen ab. Hinzu kommen lokale Helfer, die Firmenhardware entgegennehmen. Ein Unternehmen kann daher im Bewerbungsgespräch, beim Versand des Laptops und während der täglichen Zusammenarbeit jeweils mit einer anderen Person oder Rolle aus demselben Netzwerk interagieren.

Eine Schlüsselrolle spielen sogenannte Laptop Farms. Firmenrechner stehen physisch im Land des vermeintlichen Mitarbeiters, werden aber über Fernwartungssoftware oder KVM-Technik (Kernel-based Virtual Machine) aus dem Ausland bedient. Für einfache Standortkontrollen wirkt der Zugriff damit lokal. Gleichzeitig helfen Scheinfirmen, Zahlungsaccounts, Profile auf Jobplattformen und professionell gestaltete Portfolios dabei, die erfundene Biografie konsistent erscheinen zu lassen.

Generative KI erhöht die Qualität und Geschwindigkeit dieser Täuschung. Microsoft hat unter anderem KI-bearbeitete Profilbilder, verbesserte Bewerbungsunterlagen und den Einsatz von Stimmveränderungssoftware beobachtet. Ein fehlerfreier Lebenslauf oder ein plausibles Profil ist deshalb kein belastbarer Identitätsnachweis mehr.

Warum klassische Prüfungen zu kurz greifen

Ein einmaliger, dokumentenbasierter Background-Check kann bei dieser Betrugsform ins Leere laufen. Er bestätigt im besten Fall, dass die vorgelegten Daten zu einer realen Identität passen. Der Check beantwortet aber nicht automatisch, ob diese Identität der Person im Interview gehört, ob später dieselbe Person arbeitet oder ob dieselben Kontaktdaten bereits in anderen Bewerbungen aufgetaucht sind. Identitätsprüfung muss deshalb als Prozess gedacht werden: vom Recruiting über das Onboarding bis zu risikobasierten Kontrollen während der Beschäftigung.

Zusätzliche Blindstellen entstehen bei externen Entwicklern und Personaldienstleistern. Wer das Recruiting an einen Dritten auslagert, gibt damit nicht die Verantwortung für den Systemzugang ab. Unternehmen sollten vertraglich und operativ sicherstellen, dass Dienstleister vergleichbare Prüfstandards anwenden und relevante Auffälligkeiten melden.

Warnsignale im Bewerbungsprozess

Behörden und Sicherheitsforscher beschreiben wiederkehrende Muster. Kein einzelnes Merkmal beweist einen Betrug; entscheidend ist die Kombination mehrerer voneinander unabhängiger Signale:

• Kontaktdaten, hier besonders VoIP-Nummern, E-Mail-Adressen oder Zahlungsinformationen, tauchen bei mehreren angeblich unabhängigen Bewerbungen identisch auf.
• Lebenslauf, Portfolio und öffentliches Profil passen zeitlich oder inhaltlich nicht zusammen; ganze Textpassagen oder Arbeitsproben finden sich bei anderen Personen wieder.
• Der Kandidat weicht einem stabilen Video-Interview aus, Bild und Stimme wirken wiederholt asynchron oder die Person im späteren Arbeitsalltag unterscheidet sich auffällig vom Interview.
• Antworten zum aktuellen Standort, zu Ausbildung oder früheren Projekten bleiben trotz fachlicher Nachfragen ungewöhnlich vage oder widersprüchlich.
• Kurz vor oder nach Vertragsstart ändern sich Lieferadresse, Bankverbindung oder Zahlungsplattform; Hardware soll an eine andere als die verifizierte Adresse gehen.
• Der Kandidat drängt auf einen sehr schnellen Start, fordert weitreichende Rechte vor Abschluss der Prüfungen oder bevorzugt ungewöhnliche Zahlungswege.

Warnsignale nach dem ersten Arbeitstag

Mit der Einstellung endet die Prüfung nicht. Technische Indikatoren können zeigen, dass der Firmenrechner nur als Zwischenstation dient oder dass mehrere Personen ein Konto nutzen:

• Mehrere Anmeldungen desselben Kontos aus weit auseinanderliegenden Ländern oder IP-Bereichen innerhalb kurzer Zeit.
• Nicht genehmigte Fernwartungs- oder Remote-Desktop-Software, auffällige KVM-Geräte sowie Versuche, lokale Administratorrechte zu erhalten.
• Ungewöhnliche Browser-Sitzungen, wechselnde Gerätefingerabdrücke oder Arbeitsaktivität, die dauerhaft nicht zum angegebenen Standort und zur Zeitzone passt.
• Großflächiges Kopieren von Quellcode oder Dokumenten in private Cloudspeicher, persönliche Repositories oder nicht freigegebene Filesharing-Dienste.
• Mehrere parallele Audio- oder Videoverbindungen und wiederkehrende Probleme, die darauf hindeuten, dass Meetings durch Dritte unterstützt werden.

Auch hier gilt: VPN-Nutzung, Remote-Tools oder ein ungewöhnlicher Arbeitsrhythmus sind für sich genommen kein Beweis. Sie werden erst im Zusammenhang mit Auffälligkeiten aus Recruiting, Hardwareversand und Zahlungsdaten aussagekräftig.

Warum der Schaden weit über das Gehalt hinausgeht

Die erste Motivation ist häufig die Einnahme regulärer Gehälter. Doch aus dem legitimen Zugang kann ein zweites Geschäftsmodell entstehen. Das FBI warnt vor dem Abfluss proprietärer Daten und Quellcode sowie vor Erpressung nach der Enttarnung.

Hinzu kommen Kosten für Forensik, Rechtsberatung, Wiederherstellung von Systemen und mögliche Meldepflichten. Bei sensiblen Technologien können außerdem Exportkontrollen, Sanktionen und vertragliche Geheimhaltungspflichten berührt sein.

Was CIOs konkret tun können

Wirksam ist kein einzelnes Tool, sondern ein Kontrollmodell, das HR, IT, Security, Einkauf und Compliance verbindet. Fünf Maßnahmen reduzieren das Risiko deutlich:

• Rollen nach Risiko staffeln. Für Tätigkeiten mit Zugriff auf Quellcode, Produktionssysteme, Forschungsdaten oder privilegierte Konten gelten stärkere Prüf- und Freigabeschritte als für risikoarme Rollen.
• Identität mehrfach verifizieren. Dokumente, Kontaktangaben, Ausbildung und frühere Beschäftigung werden über unabhängige Quellen geprüft. Bei Remote-Rollen sollte die Identität beim Interview, beim Onboarding und bei begründetem Anlass erneut bestätigt werden.
• Hardware und Zahlungen kontrollieren. Firmenrechner gehen nur an die verifizierte Adresse. Änderungen von Lieferort, Bankverbindung oder Zahlungsplattform lösen eine erneute Prüfung aus. Systemzugänge werden erst nach Abschluss der vorgesehenen Kontrollen freigeschaltet.
• Least Privilege technisch durchsetzen. Neue Mitarbeitende erhalten zunächst nur die Rechte, die sie tatsächlich benötigen. Nicht freigegebene Fernwartungssoftware wird blockiert; Identitäts-, Endpoint- und Cloud-Logs werden risikobasiert auf ungewöhnliche Muster geprüft.
• Dienstleister und Eskalation einbeziehen. Für Freelancer und Staffing-Partner gelten dieselben Mindeststandards. Ein gemeinsamer Eskalationsweg legt fest, wer bei Auffälligkeiten entscheidet, Beweise sichert und Zugriffe begrenzt.

Für Unternehmen in Deutschland, Österreich und der Schweiz muss dieses Vorgehen verhältnismäßig und datenschutzkonform ausgestaltet sein. Ziel ist nicht die möglichst umfassende Sammlung von Personendaten, sondern die nachvollziehbare Prüfung relevanter Risiken für eine konkrete Rolle, mit klaren Kriterien, begrenzten Aufbewahrungsfristen und menschlicher Bewertung von Treffern.

Wenn sich der Verdacht erhärtet

Ein Verdachtsfall gehört nicht allein ins Recruiting. HR, Security, Legal beziehungsweise Datenschutz und gegebenenfalls Compliance sollten koordiniert vorgehen. Dazu gehören die Sicherung relevanter Protokolle, die kontrollierte Begrenzung von Zugängen, der Wechsel exponierter Schlüssel oder Tokens und die Prüfung, ob Daten in private Repositories oder Cloudkonten abgeflossen sind.

Welche Behörden oder Vertragspartner informiert werden müssen, hängt vom Sitz des Unternehmens, den betroffenen Daten und regulatorischen Pflichten ab. Entscheidend ist ein vorbereiteter Incident-Plan, nicht eine improvisierte Konfrontation.

Wer sensible Systeme oder Daten verantwortet, kommt an dieser Form von Personalrisiko nicht mehr vorbei. Die Fälle zeigen: Cybersicherheit beginnt nicht erst an der Firewall. Sie beginnt dort, wo eine digitale Identität erstmals Vertrauen, Hardware und Zugriffsrechte erhält und sie endet nicht mit dem ersten Arbeitstag. (jd)

Einen peinlichen Moment im Arbeitsleben hat sicher jeder schon einmal erlebt. Vielleicht hat man sich durch eine sehr wichtige Präsentation gestammelt oder auf einer Unternehmensfeier lautstark ein volles Glas umgeworfen und mit der verschütteten Flüssigkeit im schlimmsten Fall auch noch einen Kollegen getroffen. Besonders schwer wiegen peinliche Fehler dann, wenn man den Wunschjob noch nicht einmal in der Tasche hat. Gerade beim Bewerbungsgespräch kommt es darauf an, einen starken ersten Eindruck zu hinterlassen.

Das Online-Karriereportal Careerbuilder hat mehr als 3.000 Arbeitgeber und Personal-Experten sechs häufige Fehler im Bewerbungsgespräch danach bewerten lassen, wie sehr sie dem Kandidaten schaden. Den größten Fehler begehen Kandidaten dann, wenn sie im Gespräch ein Handygespräch annehmen oder eine SMS schreiben, 77 Prozent der Umfrage-Teilnehmer stören sich an diesem Verhalten. Das zweitschlimmste Vergehen ist es, kein Interesse an der ausgeschriebenen Stelle zu zeigen (75 Prozent), das drittschlimmste, sich unangemessen zu kleiden (72 Prozent).

Auf Rang vier der schlimmsten Fehler in Bewerbungsgesprächen liegt arrogantes Auftreten, daran stören sich 72 Prozent der befragten Personal-Experten. 67 Prozent der Personaler stören sich daran, wenn ein Bewerber im Gespräch schlecht über den jetzigen oder über frühere Arbeitgeber spricht. Für 63 Prozent der Umfrageteilnehmer ist es ein schlimmes Vergehen, wenn ein Kandidat im Bewerbungsgespräch Kaugummi kaut.

Darüber hinaus befragte Careerbuilder die Personal-Experten nach ihren ungewöhnlichsten Erlebnissen bei Bewerbungsgesprächen. Die Umfrageteilnehmer berichteten von den folgenden Gesprächssituationen:

• 1. Ein Kandidat brachte einen Bewerbungsratgeber zum Gespräch mit.
• 2. Ein anderer Bewerber fragte: “Wie heißt ihr Unternehmen noch mal?”
• 3. Bei einem Telefoninterview wurde ein Personaler von der Kandidatin in die Warteschleife gestellt. Als die Kandidatin das Gespräch in die Leitung zurückholte, erzählte sie, sie hätte sich in der Zwischenzeit für Freitag für ein Date verabredet.
• 4. Ein Bewerber trug zum Bewerbungsgespräch eine Pfadfinderuniform und erklärte im Laufe des Gesprächs nicht, weshalb er das tat.
• 5. Ein Kandidat sprach während des gesamten Bewerbungsgesprächs von sich in der dritten Person.
• 6. Ein anderer Bewerber zog sich während des Jobinterviews seine Schuhe aus.
• 7. Ein Bewerber fragte, ob er einen Schluck vom Kaffee des Personalers trinken dürfe.
• 8. Und schließlich berichtet ein Personaler von einer Kandidatin, die im Gespräch sagte, sie sei sich nicht sicher, ob der angebotene Job es wert sei, dafür das Auto zu starten.

3 Tipps für ein erfolgreiches Bewerbungsgespräch

“Man mag ja denken, dass ein Bewerber nie und nimmer während eines Jobinterviews einen Anruf annehmen würde, aber wir hören diese Geschichten immer wieder, wenn wir mit Personalern sprechen”, sagt Rosemary Haefner von Careerbuilder. Bei der Masse der Bewerber gehe es jedoch nicht darum, solche Fehler zu vermeiden sondern sich von den anderen Bewerbern abzuheben. Haefner gibt die folgenden Ratschläge für ein erfolgreiches Bewerbungsgespräch:

1. Intensiv vorbereiten: Um auf Fragen zum Unternehmen souverän zu antworten, sollte man sich gut über den Wunscharbeitgeber informieren. Geeignete Quellen dafür sind die Selbstdarstellung auf der Unternehmenswebsite, aktuelle Pressemeldungen und die Vorstellung angebotener Produkte und Dienstleistungen.

2. Optimistisch bleiben: Egal, wie die Stimmung im Bewerbungsgespräch auf einen wirkt. Haefner rät, positiv zu bleiben und auf keinen Fall schlecht über frühere Arbeitgeber zu sprechen.

3. Beispiele und Ideen vorbereiten: Am besten überlegt man sich bereits vor dem Interview Anekdoten, die den eigenen Lebenslauf veranschaulichen und zum Beispiel erläutern, wie man in früheren Jobs mit herausfordernden Situationen umgegangen ist. Auch mit Ideen und Vorschlägen für den Wunschjob kann man aus der Masse der Bewerber hervorstechen.

Das Online-Karriereportal Careerbuilder sprach für diese Umfrage mit mehr als 3.000 Arbeitgebern und Personal-Experten in den USA.

Erzählen Sie mir von einem Vorgang, den Sie für andere dokumentiert haben.

Die Antwort zeigt, wie wichtig dem Bewerber Teamwork ist und ob er sein Wissen anderen zugänglich macht.

Erzählen Sie mir von einem ihrer bisherigen Projekte.

Hier können Bewerber punkten, wenn sie auch auf Herausforderungen, komplexe Aufgaben und Einschränkungen eingehen.

Was könnten Sie mir über Details zur Programmierung von … sagen?

Die soll zeigen, ob ein Kandidat zu einer Wissenslücke steht oder blufft.

Wie würden Sie dieses Thema einem Kollegen erläutern, der kein IT-Experte ist?

Hier kann man zeigen, wieviel einem an einem guten Verhältnis von Business und IT liegt.

Sie können ein Projekt entweder rechtzeitig und unvollständig oder vollständig, jedoch nach der Deadline, abschließen. Wofür entscheiden Sie sich?

Eine gute Antwort wäre zum Beispiel, gemeinsam mit Projektleiter und Team nach der besten Lösung zu suchen.

Java Development Kit (JDK) 28, a non-LTS (Long-Term Support) or “feature release” of standard Java due in March 2027, has started to take shape. Features listed for JDK 28 now include a preview of value objects, switching the default mode of the Shenandoah garbage collector to generational mode, and a preview of strict field initialization in the Java Virtual Machine (JVM).

As a non-LTS release, JDK 28 will be backed by six months of support by Oracle.

The three features currently targeted to JDK 28 include the following:

• Introduce value objects, which are immutable and lack object identity. Value objects are distinguished by the values of their fields, and can be represented by the JVM in ways that improve performance. A goal of the feature is to give developers a programming model for immutable data in which the == operator, and all other operations, distinguish objects by the values of their fields rather than their identities. Value objects is a preview language and VM feature.
• Switch the default mode of the Shenandoah Garbage Collector (GC) to the generational mode and deprecate the non-generational mode, with the intent to remove it in a future release. Goals include signaling the intent that future development will focus on generational mode, and reducing the maintenance cost of supporting two different modes. However, it is not a goal to remove non-generational mode at this time.
• Introduce strictly-initialized fields in the JVM. Such fields must be initialized before they are read, thus default values such as 0 or null are never observed. For strictly-initialized fields that are final, the same value is always observed. A goal is offering designers of JVM-based programming languages a model for field initialization, which has stronger integrity guarantees than the present model. This is a preview VM feature.

The predecessor to JDK 28, JDK 27, is due September 15. JDK 27 also is a non-LTS release that will be backed by six months of support by Oracle.

Data released at this week’s Black Hat security conference suggests the era of manual zero-day hunting and 50-day patch windows is coming to an end. This is a double-edged sword for security professionals: Vulnerabilities can now be found at machine speed, perhaps bringing the discovery time eventually to zero, but it also means that AI-driven threats require autonomous operations to protect the organization.

At the show, Palo Alto Networks unveiled research and platform updates signaling a structural shift in cybersecurity. By deploying an autonomous multi-model AI harness called NOVA (Network and Open-Source Vulnerability Analyzer), Palo Alto demonstrated that frontier AI models can now audit codebases, write proofs of concept, and validate severe security flaws at speeds and scales previously unimaginable. 

To counter that rapidly evolving threat landscape, the vendor simultaneously launched PAN-OS 12.2 Ceres, the operating system for Palo Alto’s firewalls. The release introduces Advanced Virtual Patching, Advanced IP Defense, and autonomous Network Security Agents that neutralize AI-generated exploits at the network level within hours, not months.

The news in brief: scale, speed, and platform defense

The headline numbers from Palo Alto’s research team illustrate the sheer velocity of AI-driven vulnerability discovery:

• 14,090 confirmed vulnerabilities: Identified across 3,915 open-source software (OSS) projects in just two months.
• 99.4% zero-day flaws: Virtually all identified vulnerabilities were previously unreported in public databases.
• 39.7% high or critical severity: Under CVSS 4.0 metrics, nearly 5,600 findings pose severe real-world operational risks.
• PAN-OS 12.2 Ceres rollout: Includes 55+ innovations, highlighted by Advanced Virtual Patching (delivering pre-patch protections via “vaulted protection” engines within hours), Advanced IP Defense (blocking direct-to-IP and proxy evasion attacks), and six role-specific AI Network Security Agents.

The deep dive: challenges of cybersecurity in the frontier era

For years, defenders relied on structural asymmetry. Finding a zero-day flaw was labor-intensive, requiring elite human security researchers to spend weeks or months on manual reverse engineering. That asymmetry has vanished due to the speed of AI advances and the new challenges posed by the frontier era.

1. The death of the patch window

Historically, IT teams had a grace period—an average exposure window of about 55 days to test, stage, and deploy vendor software updates before widespread scanning and exploitation began. Frontier AI has crushed that timeline. Adversaries do not need access to state-of-the-art supercomputers to automate exploit development; off-the-shelf open-weight and proprietary models can analyze public commit logs, reverse-engineer fixes, and generate working weaponized code within hours.

2. Beyond memory corruption: the 92% problem

Traditional automated security scanning relied heavily on fuzzing, which involves pounding a binary with random inputs to trigger memory crashes, null pointer dereferences, or buffer overflows. NOVA’s research reveals that fuzzing-friendly bugs accounted for only 8% of total AI discoveries.

The remaining 92% comprised complex semantic and architectural flaws:

• PHP, Python and Java: Concentrated heavily in broken authorization and access control logic (up to 60% of Python flaws).
• JavaScript/TypeScript: Heavy concentration in code injection, prototype pollution, and Server-Side Request Forgery (SSRF).
• Go: Path traversal and file access issues dominated due to its frequent deployment in microservices and file routing engines.

AI models do not just look for crashes; they analyze the business logic of software, identifying subtle authorization bypasses that static analyzers consistently miss.

2. The power of multi-model complementarity

No single AI model catches everything. NOVA tested an ensemble of frontier models across codebases and found strong model complementarity. In controlled evaluations, Model A found 235 vulnerabilities (185 unique to it), while Model D found 139 (93 unique). Because different models reason about code structures differently, attackers running multiple, distinct AI agents simultaneously will uncover exponentially larger attack surfaces that single-scanner defensive environments miss. 

How Palo Alto Networks flips the script

To survive machine-speed discovery, defensive technology must operate autonomously across the entire vulnerability lifecycle.

• Autonomous agentic discovery (NOVA): NOVA uses an iterative agentic loop. Scoping agents define the scan strategy; discovery agents run parallel code analysis; proof-of-concept agents validate findings deterministically in isolated sandboxes (gVisor/VMs); and gatekeeper agents confirm exploitability before generating remediations. 
• Advanced Virtual Patching: With PAN-OS 12.2 Ceres, Palo Alto Networks deploys inline network protection via its Advanced Threat Prevention (ATP) engines within hours of zero-day discovery. By enforcing network-level filtering before vendor code-level patches are available, organizations achieve a “vaulted protection” shield without forcing system reboots or causing downtime. 
• Ecosystem and supply chain collaboration: Palo Alto Networks proactively reports findings upstream to open-source maintainers, project clearinghouses (such as Project Lightwell and Akrites), and enterprise software partners to address underlying vulnerabilities at the source.

Advice for IT and security professionals

The shift to AI-driven threat discovery means security leaders can no longer rely on traditional patch management cadences. CISOs and IT administrators should take immediate steps to adapt:

• Prioritize network-layer virtual patching: Stop assuming software patches can be tested and deployed quickly enough. Implement inline virtual patching at the firewall, SASE, and perimeter layers to block exploit traffic long before host-level updates are applied.
• Audit open-source supply chains beyond direct imports: Static dependency checking is insufficient. Map deep transitive dependencies. As NOVA proved, a single low-level package flaw (such as an IP parser or zip extractor) can expose thousands of downstream applications.
• Shift focus to identity and access control logic: Because 92% of AI-discovered bugs target application logic and authorization rather than simple memory crashes, re-evaluate application security testing. Prioritize dynamic API testing and identity-centric access rules.
• Prepare for post-quantum and evasive IP threats: Upgrade infrastructure to handle direct-to-IP command-and-control bypasses and use automated management tools to prepare for shorter cryptographic certificate lifecycles.
• Embrace human-in-the-loop automation: Use specialized AI administrative agents for routine network triage and rule configuration, reserving high-value human expertise for complex threat modeling, creative architectural design, and strategic oversight.

The era of AI vulnerability discovery is not a distant future—it is fully operational today. Securing the modern enterprise requires matching machine-speed discovery with machine-speed prevention. It’s time for security pros to stop fearing AI-driven security and embrace it, as the only way to combat AI-driven threats is with AI-enabled defense.

Over the past decade, I have worked through multiple technology transitions, from virtualization and cloud adoption to containers and large-scale automation. Each changed how enterprise IT operated, but they all shared one characteristic: production systems still behaved in broadly predictable ways. AI is the first shift I have seen that changes the behavior of production itself.

In the infrastructure environments I have worked with, production has always depended on a few basic assumptions. Workloads are tied to applications. Applications have owners. Traffic patterns are reasonably predictable. Change windows are planned. Incident response starts with a known service, a known dependency or a known user action.

AI agents challenge each one of those assumptions.

An AI agent may initiate work without a human clicking a button. It may call APIs at machine speed, move across systems to complete a task, retry failed actions aggressively or generate unusual traffic patterns that look nothing like a traditional application flow. The individual action may be legitimate, but the operational behavior is different.

That is the shift CIOs should pay attention to. The question is not only whether AI can be useful in enterprise operations. The harder question is whether production environments are ready for AI-driven activity that behaves less like an application and more like an autonomous participant in the enterprise.

Production was built around predictable workloads

For years, production operations have been built around patterns that are easier to manage because they are relatively stable. A user logs in. An application receives a request. A service calls another service. Monitoring tools evaluate latency, errors, saturation and availability. Incident teams look for deviations from known baselines.

This model worked because most production systems had a recognizable shape. Even in complex environments, teams could usually identify the application owner, the expected request flow, the normal volume range and the rollback path when something failed.

AI workloads do not always behave that way. A single agent completing a business task may generate a burst of API calls, invoke several backend services, open and close sessions quickly and repeat requests in a pattern that looks abnormal when compared with human activity. From a traditional monitoring perspective, this can look like abuse, instability or an integration defect even when the agent is doing exactly what it was asked to do.

The opposite problem is just as serious. If teams relax controls broadly to avoid blocking legitimate AI activity, they may also create room for real abuse to hide inside higher-volume machine traffic. That is not a model issue. It is an operational assumption issue.

The NIST AI Risk Management Framework emphasizes that AI risk must be understood across the full lifecycle of AI systems, including design, deployment, use and evaluation. For CIOs, that lifecycle needs to include production operations, not just model selection or application launch.

In practice, this means AI cannot be treated as a normal application feature once it begins triggering workflows, touching data, generating traffic or interacting with operational systems. It becomes part of the production environment. That requires a different level of readiness.

I have seen similar transitions before with cloud and automation. The first wave is usually tool-focused. Teams ask what the technology can do. The second wave is operational. Teams discover what the technology changes. AI is entering that second phase now.

AI changes incident response and observability

When production breaks, teams need to answer a few basic questions quickly. What changed? What system is affected? What users are impacted? Which dependency is failing? Can we roll back safely?

AI makes those questions harder because the cause of an incident may not be a code deployment, infrastructure outage or human-initiated workflow. It may be an agent making a decision that is technically allowed but operationally unexpected.

For example, an AI-enabled support workflow might retry a failed backend request repeatedly because it is trying to complete a customer task. A human operator may have stopped after one or two failures. The agent may continue until it exhausts a threshold, creates noise across monitoring systems or triggers downstream rate limits. The failure is not that the agent is malicious. The failure is that production systems were not designed to interpret that behavior correctly.

This is where observability becomes critical. Traditional dashboards may show traffic growth, error spikes or latency changes, but they may not explain whether the behavior came from a user, application, script, automation job or AI agent. If those categories are not visible, incident response teams are forced to guess.

Google’s Site Reliability Engineering guidance on monitoring distributed systems is useful because it frames monitoring around symptoms that require action, not just raw system signals. That distinction becomes even more important when AI-driven workflows introduce new behaviors into production.

CIOs should expect AI to change what good observability means. It is no longer enough to monitor infrastructure health and application performance. Teams also need visibility into AI-initiated actions, agent-driven traffic patterns, tool usage, retries, failed task loops and dependency chains.

The operational question becomes simple: when an AI system causes a production symptom, can the organization trace the action from the agent to the service to the business impact? If the answer is no, AI is already ahead of the operating model.

The CNCF observability whitepaper describes observability as a way to understand complex system behavior from external outputs. That idea applies directly here: AI-driven systems will require observability that explains behavior across workflows, not just infrastructure components.

Production readiness needs to change before AI scales

The mistake many organizations make is preparing AI for production without preparing production for AI.

“The mistake many organizations make is preparing AI for production without preparing production for AI.”

A pilot can succeed with limited users, narrow workflows and close supervision. Production is different. Production introduces volume, concurrency, exceptions, outages, retries, partial failures, support queues and business pressure. AI agents will encounter all of that, and they will do so at a speed that traditional operational processes may not be ready to absorb.

This is why CIOs should treat AI readiness as a production discipline. Before scaling AI-enabled workflows, teams should define what normal AI activity looks like, what abnormal behavior looks like and what evidence is required to troubleshoot the difference. They should know which systems an agent can touch, how agent traffic is labeled, how rate limits apply, how errors are escalated and how failed workflows are stopped.

This is not about slowing AI adoption. It is about preventing production from becoming the testing ground for assumptions that were never validated.

The 2024 DORA Accelerate State of DevOps Report noted that AI can improve individual productivity while also creating tradeoffs for delivery stability and throughput. That is a useful warning for CIOs: productivity gains do not automatically translate into operational maturity.

The organizations that will handle this transition well will not be the ones that simply deploy the most AI tools. They will be the ones that adjust production operations early. That means treating AI activity as something to be observed, tested, limited, measured and supported like any other production workload, but with the added recognition that it may behave differently from traditional software.

Capacity planning will also need to change. AI workflows may create irregular demand patterns, especially when agents run multi-step tasks across internal systems. A workload that looks small in a pilot can create meaningful load when hundreds or thousands of users trigger agents throughout the day. The cost impact may appear in compute, API calls, storage, logs, monitoring systems or downstream service usage.

Change management will need to account for model behavior, prompt updates, tool integrations and workflow changes. A small update to an agent’s instructions may alter how it calls systems, how often it retries, which APIs it uses or how it handles exceptions. In production, that is not merely a content update. It is an operational change.

Rollback planning will also need to evolve because reverting an AI-enabled workflow may involve more than restoring application code. It may require disabling agent actions, reverting prompts or temporarily removing tool integrations while preserving business continuity.

Incident response will need clearer playbooks. Teams should know how to pause an agent, isolate a workflow, disable a tool integration, reduce task volume or route activity back to human handling when production behavior becomes unsafe or unstable.

The larger point is that AI is not just entering the enterprise as another user-facing capability. It is entering the operating fabric of the enterprise. That makes it a CIO concern, not only an AI team concern.

Every major technology shift eventually becomes an operational discipline rather than a technology project. AI is reaching that point now. Organizations that recognize this early will be better positioned to scale AI with confidence instead of discovering its operational consequences through production incidents. The next challenge for CIOs is not deploying AI. It is preparing production environments for how AI actually behaves.

Over the past decade, I have worked through multiple technology transitions, from virtualization and cloud adoption to containers and large-scale automation. Each changed how enterprise IT operated, but they all shared one characteristic: production systems still behaved in broadly predictable ways. AI is the first shift I have seen that changes the behavior of production itself.

In the infrastructure environments I have worked with, production has always depended on a few basic assumptions. Workloads are tied to applications. Applications have owners. Traffic patterns are reasonably predictable. Change windows are planned. Incident response starts with a known service, a known dependency or a known user action.

AI agents challenge each one of those assumptions.

An AI agent may initiate work without a human clicking a button. It may call APIs at machine speed, move across systems to complete a task, retry failed actions aggressively or generate unusual traffic patterns that look nothing like a traditional application flow. The individual action may be legitimate, but the operational behavior is different.

That is the shift CIOs should pay attention to. The question is not only whether AI can be useful in enterprise operations. The harder question is whether production environments are ready for AI-driven activity that behaves less like an application and more like an autonomous participant in the enterprise.

Production was built around predictable workloads

For years, production operations have been built around patterns that are easier to manage because they are relatively stable. A user logs in. An application receives a request. A service calls another service. Monitoring tools evaluate latency, errors, saturation and availability. Incident teams look for deviations from known baselines.

This model worked because most production systems had a recognizable shape. Even in complex environments, teams could usually identify the application owner, the expected request flow, the normal volume range and the rollback path when something failed.

AI workloads do not always behave that way. A single agent completing a business task may generate a burst of API calls, invoke several backend services, open and close sessions quickly and repeat requests in a pattern that looks abnormal when compared with human activity. From a traditional monitoring perspective, this can look like abuse, instability or an integration defect even when the agent is doing exactly what it was asked to do.

The opposite problem is just as serious. If teams relax controls broadly to avoid blocking legitimate AI activity, they may also create room for real abuse to hide inside higher-volume machine traffic. That is not a model issue. It is an operational assumption issue.

The NIST AI Risk Management Framework emphasizes that AI risk must be understood across the full lifecycle of AI systems, including design, deployment, use and evaluation. For CIOs, that lifecycle needs to include production operations, not just model selection or application launch.

In practice, this means AI cannot be treated as a normal application feature once it begins triggering workflows, touching data, generating traffic or interacting with operational systems. It becomes part of the production environment. That requires a different level of readiness.

I have seen similar transitions before with cloud and automation. The first wave is usually tool-focused. Teams ask what the technology can do. The second wave is operational. Teams discover what the technology changes. AI is entering that second phase now.

AI changes incident response and observability

When production breaks, teams need to answer a few basic questions quickly. What changed? What system is affected? What users are impacted? Which dependency is failing? Can we roll back safely?

AI makes those questions harder because the cause of an incident may not be a code deployment, infrastructure outage or human-initiated workflow. It may be an agent making a decision that is technically allowed but operationally unexpected.

For example, an AI-enabled support workflow might retry a failed backend request repeatedly because it is trying to complete a customer task. A human operator may have stopped after one or two failures. The agent may continue until it exhausts a threshold, creates noise across monitoring systems or triggers downstream rate limits. The failure is not that the agent is malicious. The failure is that production systems were not designed to interpret that behavior correctly.

This is where observability becomes critical. Traditional dashboards may show traffic growth, error spikes or latency changes, but they may not explain whether the behavior came from a user, application, script, automation job or AI agent. If those categories are not visible, incident response teams are forced to guess.

Google’s Site Reliability Engineering guidance on monitoring distributed systems is useful because it frames monitoring around symptoms that require action, not just raw system signals. That distinction becomes even more important when AI-driven workflows introduce new behaviors into production.

CIOs should expect AI to change what good observability means. It is no longer enough to monitor infrastructure health and application performance. Teams also need visibility into AI-initiated actions, agent-driven traffic patterns, tool usage, retries, failed task loops and dependency chains.

The operational question becomes simple: when an AI system causes a production symptom, can the organization trace the action from the agent to the service to the business impact? If the answer is no, AI is already ahead of the operating model.

The CNCF observability whitepaper describes observability as a way to understand complex system behavior from external outputs. That idea applies directly here: AI-driven systems will require observability that explains behavior across workflows, not just infrastructure components.

Production readiness needs to change before AI scales

The mistake many organizations make is preparing AI for production without preparing production for AI.

“The mistake many organizations make is preparing AI for production without preparing production for AI.”

A pilot can succeed with limited users, narrow workflows and close supervision. Production is different. Production introduces volume, concurrency, exceptions, outages, retries, partial failures, support queues and business pressure. AI agents will encounter all of that, and they will do so at a speed that traditional operational processes may not be ready to absorb.

This is why CIOs should treat AI readiness as a production discipline. Before scaling AI-enabled workflows, teams should define what normal AI activity looks like, what abnormal behavior looks like and what evidence is required to troubleshoot the difference. They should know which systems an agent can touch, how agent traffic is labeled, how rate limits apply, how errors are escalated and how failed workflows are stopped.

This is not about slowing AI adoption. It is about preventing production from becoming the testing ground for assumptions that were never validated.

The 2024 DORA Accelerate State of DevOps Report noted that AI can improve individual productivity while also creating tradeoffs for delivery stability and throughput. That is a useful warning for CIOs: productivity gains do not automatically translate into operational maturity.

The organizations that will handle this transition well will not be the ones that simply deploy the most AI tools. They will be the ones that adjust production operations early. That means treating AI activity as something to be observed, tested, limited, measured and supported like any other production workload, but with the added recognition that it may behave differently from traditional software.

Capacity planning will also need to change. AI workflows may create irregular demand patterns, especially when agents run multi-step tasks across internal systems. A workload that looks small in a pilot can create meaningful load when hundreds or thousands of users trigger agents throughout the day. The cost impact may appear in compute, API calls, storage, logs, monitoring systems or downstream service usage.

Change management will need to account for model behavior, prompt updates, tool integrations and workflow changes. A small update to an agent’s instructions may alter how it calls systems, how often it retries, which APIs it uses or how it handles exceptions. In production, that is not merely a content update. It is an operational change.

Rollback planning will also need to evolve because reverting an AI-enabled workflow may involve more than restoring application code. It may require disabling agent actions, reverting prompts or temporarily removing tool integrations while preserving business continuity.

Incident response will need clearer playbooks. Teams should know how to pause an agent, isolate a workflow, disable a tool integration, reduce task volume or route activity back to human handling when production behavior becomes unsafe or unstable.

The larger point is that AI is not just entering the enterprise as another user-facing capability. It is entering the operating fabric of the enterprise. That makes it a CIO concern, not only an AI team concern.

Every major technology shift eventually becomes an operational discipline rather than a technology project. AI is reaching that point now. Organizations that recognize this early will be better positioned to scale AI with confidence instead of discovering its operational consequences through production incidents. The next challenge for CIOs is not deploying AI. It is preparing production environments for how AI actually behaves.

A self-propagating worm-like attack is hitting the npm registry, having infected 444 packages from more than a dozen publishers so far. The impact is massive, with the packages affected amounting to more than 2 billion monthly downloads combined.

The attack began with the compromise of a GitHub account belonging to Jared Wray, who maintains Keyv, a package with over 150 million weekly downloads that provides an interface for interacting with key-value storage across multiple backends. Version 6.0.0 published at around 9:00 UTC on Tuesday contained a new version of the Shai-Hulud credential stealing malware.

The compromised account is also used to maintain a number of other popular packages, including cacheable, flat-cache, file-entry-cache, cacheable-request, cache-manager, ecto, and more. All of these had trojanized versions published as well.

Soon after, the attack expanded beyond this account, infecting packages from other organizations on npm — @deliveroo/reevent, @or-sdk/invitations , @picsart/ai-sdk, @qlik/embed-runtime, picasso.js, to name a few. As of 18:10 UTC, StepSecurity had detected the malicious code across 444 packages and 2,212 versions.

“Every poisoned version carries the same infection pattern: a preinstall dropper that downloads the legitimate Bun JavaScript runtime, and a 710KB obfuscated second stage that steals credentials, publishes more malicious packages, and burrows into AI developer tooling,” researchers from StepSecurity said.

Although the code appears to be a new variant of Shai-Hulud — a supply-chain credential stealing worm that has plagued the npm and PyPI repositories since last year in different variations — researchers have decided to dub this new attack campaign ChainDrop because this new version uses the Ethereum blockchain for command and control, a technique known as EtherHiding.

“The compromise was carried out by pushing malicious files directly to the main branch and then immediately cutting a new release, meaning the poisoned versions were published to npm with valid provenance signed by GitHub Actions,” researchers from Aikido Security said in a report.

Wray confirmed via X that he uses OpenID Connect (OIDC) with npm and one-time codes for GitHub, so he was not using long-term static tokens. The developer regained access to his GitHub account at around 20:00 UTC and said he’s doing a full audit.

The malware infects AI code assistants

The malicious files added to packages are setup.mjs and Math_Symbol.js — renamed math_init.js in some cases. These get executed by a preinstall script during the npm installation process of the packages and then proceed to download and execute a secondary obfuscated payload on the computer.

The malware searches the local environment for cloud credentials, infrastructure secrets, developer access tokens, AI-related configuration files, and cryptocurrency wallets. It also identifies CI/CD workflows and build runners and tries to scrape their memory for temporary secrets injected during the build process.

New to this variant are persistent mechanisms deployed inside code editors such as VS Code via tasks.json and AI code assistants such as Claude Code through hooks.

“Targets for credential theft have been expanded by almost 70%, with new additions including AI-agent credential stores for Claude, OpenAI, Codex, Cursor and Gemini; cryptocurrency keystores for Foundry, Solana and Monero; self-hosted CI and registry secrets such as Jenkins’ master.key, Argo CD and Harbor; Alibaba Cloud and Tencent Cloud CLI configurations; and system files including /etc/shadow,” researchers from security firm Wiz said in their own analysis.

Mitigation

Unfortunately, enterprise security teams must perform full audits of developer machines. The compromised packages are transient dependencies for thousands of others and if any of the poisoned versions were installed during the attack window, all possible credentials accessible on that machine, or other machines accessible from that machine, need to be rotated.

“Rotate, at minimum: npm automation tokens, GitHub personal access tokens and SSH keys, cloud provider credentials (~/.aws, ~/.config/gcloud, Azure), Kubernetes service accounts, and any secrets in environment variables or .env files present at install time,” the StepSecurity researchers said. “Maintainers of npm packages should treat their publish credentials as exposed. The second wave of this campaign demonstrates exactly why: additional maintainer accounts published the identical payload within the same hour.”

The StepSecurity report includes indicators of compromise, a list of infected packages, as well as defense-in-depth recommendations for developer machines and processes that could have stopped this compromise.

Using the -—ignore-scripts npm flag in CI workflows, a technique known as script gating, would have ignored the preinstall script that delivers the payload. Package managers like npm, pnpm, Yarn and Bun now support minimum release age policies for package installation. Configuring this setting to between 3 to 7 days buys users some time in case a newly released version turns out to be poisoned.

Security companies continuously scan and monitor the npm registry and new supply chain compromises are usually discovered within minutes or hours. In this case the malicious versions began being removed by the npm team within two hours, but being a worm, the attack keeps propagating via newly compromised developer accounts.

AI agents are performing roughly 1 in 3 actions in enterprise IT workflows (but that share is rising quickly), while human analysts are rejecting about one-quarter of AI-proposed actions (but that rate is falling), according to a new study of tens of thousands of human-AI interactions. Operational data, rather than underlying AI infrastructures, is often the culprit when things go wrong.

Human analysts are approving the most consequential actions, managing exceptions, and supervising and shaping agentic systems, while AI agents are carrying out routine tasks and executions, automation platform provider Fixify found in the study.

“That may sound less dramatic than replacing the help desk,” Matt Peters, Fixify’s co-founder and CEO, wrote in a blog post. “It’s also a much more credible path to changing how IT work gets done.”

Building scaffolding

Fixify identified four steps of agentic work: Planning, proposing, approving or declining, then acting on approved steps.

It analyzed nearly 18,000 plans and over 147,000 actions executed by agents across 40 companies over a three-month period, finding that agents are taking over one-third of IT actions, most notably in software, applications, security, and collaboration work where requests tend to be “repeatable and easy to reverse.”

Tasks that are well understood and that present low risk are best suited for the current generation of agents, Peters wrote. Human analysts remain closely involved in higher-stakes areas like identity verification, setting up and removing IT access (onboarding and offboarding), and hardware environments.

However, AI’s share of the work is increasing as feedback loops improve: Over the three-month period, human approval of AI-proposed actions rose from 23% to 41%, and rejection fell from 27% to 16%, Fixify found.

The company identified six types of actions in AI automation. Running a skill — actually doing something — accounted for 39.4% of all actions). Most of the rest were coordination: sending a message to the human requester (27.7% of actions), leaving an initial comment (13.2%), giving instructions to a human analyst (9.8%), or waiting (8.8%). Running entire workflows accounted for just 1.1% of actions.

AI is building “scaffolding” that wraps around meaningful changes, often planning far more scenarios than the agent will execute. Typically, agents map out 15 possible actions but run only two, Fixify said.

“The agent maps the paths a request could take, then walks down the path that makes the most sense as it meets reality,” the study said.

Peters pointed to one example where an AI agent identified which team needed access to process a high-volume type of ticket. Rather than fully automating the process, the agent did the initial triage, asked questions, then routed tickets to the team that had the information to act immediately.

“We didn’t need a world-ending hive mind,” he said. “We just needed to point a little conversational intelligence in the right direction.”

When AI breaks down

IT automation typically involves analyzing tickets and moving them along; in other words, low-risk tasks.

But agents do participate in areas like security (albeit only about 6%), most notably adding and removing people from groups or channels, unlocking accounts, resetting passwords, analyzing multi-factor authentication (MFA), provisioning (or deprovisioning) accounts, and assigning software licenses.

However, this identity-lifecycle work is where agents failed the most, particularly in onboarding and offboarding and identity-access management (IAM), the study found. “Hardware and connectivity changes rarely fail; identity-lifecycle changes fail three-to-nine times as often.”

Why AI breaks down

Thanks to human-in-the-loop controls, Fixify was able to analyze scenarios where agent recommendation diverged from human judgment. This occurred about 23% of the time.

The largest failure category (nearly 50%) was ‘target not found,’ meaning the agent couldn’t uncover what it needed. This typically comes down to poor data: A user, group, account, or resource was not where the system expected it to be. When people change teams, groups are restructured, accounts are renamed, or work has already been done but not reflected in the system, this is more of an identity hygiene problem than an AI problem. The system needs cleaner and more current data.

Invalid inputs accounted for around 29% of failures, followed by unhandled errors, denied permissions, or invalid operations or configurations. The latter signal “real breakage” in integrations, according to Fixify.

AI becomes more sophisticated over time

The good news is that AI automation improves over time, even if it might take a while. In hybrid systems, humans keep the most consequential changes under their own control, and iterative rejection and approval helps AI learn.

Over time, agents’ plans get leaner and they start to re-plan when conditions change, rather than pre-planning all kinds of scenarios that may never occur. “That’s a sign of sophistication,” the study said. “Adapting in the moment is a more advanced behavior than trying to pre-script every contingency.”

In turn, humans second guess the system less often and feel comfortable handing off more work. Instead, they control how agents behave, make high-impact decisions, and handle exceptions. “The hardest requests remain human-heavy, especially those that require repeated replanning or contextual judgment,” the study said.

How teams can adapt to AI agents

As agentic AI becomes embedded in more workflows — and at deeper levels — enterprises must evolve to accommodate, Fixify emphasized.

This means investing in clean identity data and building strong playbooks, review workflows, and reliable integrations.

Teams should judge agentic tools by their supervision loop and view rejections as a training process, Fixify advised. Analyst time, queues, and metrics should be built around reviewing proposals. Agent replanning can be seen as a routing signal: A single replan might indicate healthy adaptation, while repeated replanning means ambiguity, irrelevance, or unclear policies.

“Make the review surface easy to understand so analysts can assess proposed actions and make quick decisions about how to proceed,” the study advised. “This is where the analyst’s attention belongs.”

This article first appeared on Computerworld.

AI agents are performing roughly 1 in 3 actions in enterprise IT workflows (but that share is rising quickly), while human analysts are rejecting about one-quarter of AI-proposed actions (but that rate is falling), according to a new study of tens of thousands of human-AI interactions. Operational data, rather than underlying AI infrastructures, is often the culprit when things go wrong.

Human analysts are approving the most consequential actions, managing exceptions, and supervising and shaping agentic systems, while AI agents are carrying out routine tasks and executions, automation platform provider Fixify found in the study.

“That may sound less dramatic than replacing the help desk,” Matt Peters, Fixify’s co-founder and CEO, wrote in a blog post. “It’s also a much more credible path to changing how IT work gets done.”

Building scaffolding

Fixify identified four steps of agentic work: Planning, proposing, approving or declining, then acting on approved steps.

It analyzed nearly 18,000 plans and over 147,000 actions executed by agents across 40 companies over a three-month period, finding that agents are taking over one-third of IT actions, most notably in software, applications, security, and collaboration work where requests tend to be “repeatable and easy to reverse.”

Tasks that are well understood and that present low risk are best suited for the current generation of agents, Peters wrote. Human analysts remain closely involved in higher-stakes areas like identity verification, setting up and removing IT access (onboarding and offboarding), and hardware environments.

However, AI’s share of the work is increasing as feedback loops improve: Over the three-month period, human approval of AI-proposed actions rose from 23% to 41%, and rejection fell from 27% to 16%, Fixify found.

The company identified six types of actions in AI automation. Running a skill — actually doing something — accounted for 39.4% of all actions). Most of the rest were coordination: sending a message to the human requester (27.7% of actions), leaving an initial comment (13.2%), giving instructions to a human analyst (9.8%), or waiting (8.8%). Running entire workflows accounted for just 1.1% of actions.

AI is building “scaffolding” that wraps around meaningful changes, often planning far more scenarios than the agent will execute. Typically, agents map out 15 possible actions but run only two, Fixify said.

“The agent maps the paths a request could take, then walks down the path that makes the most sense as it meets reality,” the study said.

Peters pointed to one example where an AI agent identified which team needed access to process a high-volume type of ticket. Rather than fully automating the process, the agent did the initial triage, asked questions, then routed tickets to the team that had the information to act immediately.

“We didn’t need a world-ending hive mind,” he said. “We just needed to point a little conversational intelligence in the right direction.”

When AI breaks down

IT automation typically involves analyzing tickets and moving them along; in other words, low-risk tasks.

But agents do participate in areas like security (albeit only about 6%), most notably adding and removing people from groups or channels, unlocking accounts, resetting passwords, analyzing multi-factor authentication (MFA), provisioning (or deprovisioning) accounts, and assigning software licenses.

However, this identity-lifecycle work is where agents failed the most, particularly in onboarding and offboarding and identity-access management (IAM), the study found. “Hardware and connectivity changes rarely fail; identity-lifecycle changes fail three-to-nine times as often.”

Why AI breaks down

Thanks to human-in-the-loop controls, Fixify was able to analyze scenarios where agent recommendation diverged from human judgment. This occurred about 23% of the time.

The largest failure category (nearly 50%) was ‘target not found,’ meaning the agent couldn’t uncover what it needed. This typically comes down to poor data: A user, group, account, or resource was not where the system expected it to be. When people change teams, groups are restructured, accounts are renamed, or work has already been done but not reflected in the system, this is more of an identity hygiene problem than an AI problem. The system needs cleaner and more current data.

Invalid inputs accounted for around 29% of failures, followed by unhandled errors, denied permissions, or invalid operations or configurations. The latter signal “real breakage” in integrations, according to Fixify.

AI becomes more sophisticated over time

The good news is that AI automation improves over time, even if it might take a while. In hybrid systems, humans keep the most consequential changes under their own control, and iterative rejection and approval helps AI learn.

Over time, agents’ plans get leaner and they start to re-plan when conditions change, rather than pre-planning all kinds of scenarios that may never occur. “That’s a sign of sophistication,” the study said. “Adapting in the moment is a more advanced behavior than trying to pre-script every contingency.”

In turn, humans second guess the system less often and feel comfortable handing off more work. Instead, they control how agents behave, make high-impact decisions, and handle exceptions. “The hardest requests remain human-heavy, especially those that require repeated replanning or contextual judgment,” the study said.

How teams can adapt to AI agents

As agentic AI becomes embedded in more workflows — and at deeper levels — enterprises must evolve to accommodate, Fixify emphasized.

This means investing in clean identity data and building strong playbooks, review workflows, and reliable integrations.

Teams should judge agentic tools by their supervision loop and view rejections as a training process, Fixify advised. Analyst time, queues, and metrics should be built around reviewing proposals. Agent replanning can be seen as a routing signal: A single replan might indicate healthy adaptation, while repeated replanning means ambiguity, irrelevance, or unclear policies.

“Make the review surface easy to understand so analysts can assess proposed actions and make quick decisions about how to proceed,” the study advised. “This is where the analyst’s attention belongs.”

AI agents are performing roughly 1 in 3 actions in enterprise IT workflows (but that share is rising quickly), while human analysts are rejecting about one-quarter of AI-proposed actions (but that rate is falling), according to a new study of tens of thousands of human-AI interactions. Operational data, rather than underlying AI infrastructures, is often the culprit when things go wrong.

Human analysts are approving the most consequential actions, managing exceptions, and supervising and shaping agentic systems, while AI agents are carrying out routine tasks and executions, automation platform provider Fixify found in the study.

“That may sound less dramatic than replacing the help desk,” Matt Peters, Fixify’s co-founder and CEO, wrote in a blog post. “It’s also a much more credible path to changing how IT work gets done.”

Building scaffolding

Fixify identified four steps of agentic work: Planning, proposing, approving or declining, then acting on approved steps.

It analyzed nearly 18,000 plans and over 147,000 actions executed by agents across 40 companies over a three-month period, finding that agents are taking over one-third of IT actions, most notably in software, applications, security, and collaboration work where requests tend to be “repeatable and easy to reverse.”

Tasks that are well understood and that present low risk are best suited for the current generation of agents, Peters wrote. Human analysts remain closely involved in higher-stakes areas like identity verification, setting up and removing IT access (onboarding and offboarding), and hardware environments.

However, AI’s share of the work is increasing as feedback loops improve: Over the three-month period, human approval of AI-proposed actions rose from 23% to 41%, and rejection fell from 27% to 16%, Fixify found.

The company identified six types of actions in AI automation. Running a skill — actually doing something — accounted for 39.4% of all actions). Most of the rest were coordination: sending a message to the human requester (27.7% of actions), leaving an initial comment (13.2%), giving instructions to a human analyst (9.8%), or waiting (8.8%). Running entire workflows accounted for just 1.1% of actions.

AI is building “scaffolding” that wraps around meaningful changes, often planning far more scenarios than the agent will execute. Typically, agents map out 15 possible actions but run only two, Fixify said.

“The agent maps the paths a request could take, then walks down the path that makes the most sense as it meets reality,” the study said.

Peters pointed to one example where an AI agent identified which team needed access to process a high-volume type of ticket. Rather than fully automating the process, the agent did the initial triage, asked questions, then routed tickets to the team that had the information to act immediately.

“We didn’t need a world-ending hive mind,” he said. “We just needed to point a little conversational intelligence in the right direction.”

When AI breaks down

IT automation typically involves analyzing tickets and moving them along; in other words, low-risk tasks.

But agents do participate in areas like security (albeit only about 6%), most notably adding and removing people from groups or channels, unlocking accounts, resetting passwords, analyzing multi-factor authentication (MFA), provisioning (or deprovisioning) accounts, and assigning software licenses.

However, this identity-lifecycle work is where agents failed the most, particularly in onboarding and offboarding and identity-access management (IAM), the study found. “Hardware and connectivity changes rarely fail; identity-lifecycle changes fail three-to-nine times as often.”

Why AI breaks down

Thanks to human-in-the-loop controls, Fixify was able to analyze scenarios where agent recommendation diverged from human judgment. This occurred about 23% of the time.

The largest failure category (nearly 50%) was ‘target not found,’ meaning the agent couldn’t uncover what it needed. This typically comes down to poor data: A user, group, account, or resource was not where the system expected it to be. When people change teams, groups are restructured, accounts are renamed, or work has already been done but not reflected in the system, this is more of an identity hygiene problem than an AI problem. The system needs cleaner and more current data.

Invalid inputs accounted for around 29% of failures, followed by unhandled errors, denied permissions, or invalid operations or configurations. The latter signal “real breakage” in integrations, according to Fixify.

AI becomes more sophisticated over time

The good news is that AI automation improves over time, even if it might take a while. In hybrid systems, humans keep the most consequential changes under their own control, and iterative rejection and approval helps AI learn.

Over time, agents’ plans get leaner and they start to re-plan when conditions change, rather than pre-planning all kinds of scenarios that may never occur. “That’s a sign of sophistication,” the study said. “Adapting in the moment is a more advanced behavior than trying to pre-script every contingency.”

In turn, humans second guess the system less often and feel comfortable handing off more work. Instead, they control how agents behave, make high-impact decisions, and handle exceptions. “The hardest requests remain human-heavy, especially those that require repeated replanning or contextual judgment,” the study said.

How teams can adapt to AI agents

As agentic AI becomes embedded in more workflows — and at deeper levels — enterprises must evolve to accommodate, Fixify emphasized.

This means investing in clean identity data and building strong playbooks, review workflows, and reliable integrations.

Teams should judge agentic tools by their supervision loop and view rejections as a training process, Fixify advised. Analyst time, queues, and metrics should be built around reviewing proposals. Agent replanning can be seen as a routing signal: A single replan might indicate healthy adaptation, while repeated replanning means ambiguity, irrelevance, or unclear policies.

“Make the review surface easy to understand so analysts can assess proposed actions and make quick decisions about how to proceed,” the study advised. “This is where the analyst’s attention belongs.”

After more than 30 years the cybersecurity field, Keith Jones recently realized that his role had changed, from being a single contributor to manager of a fairly large team. And this team was getting a lot accomplished — tasks that used to take up a huge chunk of his workday.

No, his company hadn’t hired a group of new employees to work under him. He simply accelerated his use of artificial intelligence tools. Now, instead of grinding through a lot of basic tasks, that work is done for him while he focuses on bigger-picture work.

“It really feels like I have a team behind the scenes, but what I have is Claude [Anthropic’s AI tool],” says Jones, who currently works as a cybersecurity researcher. “I’ve been thinking for the last several months about how much differently I work now than I did a year ago, when I would sit and write all the low-level stuff before I could get to the 10% of the good stuff I really wanted to focus on. Now I can sit back and say, ‘Give me three different ways to solve this problem.’”

Most people working in the technology field, like Jones, have had to figure out how best to work with AI. The technology has come on strong, with many companies making its use mandatory and actively evaluating whether employees are faster and more efficient because of it. And while it is boosting productivity and taking over the burden of repetitive, manual tasks, it’s also creating a new level of stress and a dizzying kind of mental exhaustion.

So what can tech workers do about the heavier mental load that comes with using AI, on top of escalating worries about the safety of their own jobs? AI users and industry analysts say there are specific ways to ease some of those burdens and prepare for a changing job market.

Combating the slop factor

When it comes to working with LLM tools, a well-known issue is dealing with AI workslop and hallucinations. The slop is AI-generated output that is low-quality, buzzword-heavy, and generic. It also can refer to bloated, boilerplate code. Hallucinations are inaccurate or completely made-up results. AI routinely offers this messy or incorrect information with total confidence, giving users a false sense of security.

Using this bad data can lead to anything from minor software bugs to severe liabilities. “Don’t believe the machine is infallible,” says Craig Shue, computer science professor and department head at Worcester Polytechnic Institute (WPI). “That’s when bugs will start working in. There’s a lot of misinformation on the internet, and that could be what the LLM is grabbing and using.”

Here are ways to combat the problem:

• Make AI show its work: Ask it to cite its sources or explain its reasoning. Example prompt: Explain the logic and show the steps before writing the code.
• Give the AI a source of truth: Instead of letting the AI search the internet for information, give it the exact source material (reports, transcripts, data sheets) to base its output on, telling it to use only the information provided.
• Validate. Validate. Validate: Never let AI publish code directly to the main project without first reviewing and running it locally. Similarly, never take AI output and simply move it on to the next person in the project. Every single AI output needs review.
• Don’t be fooled by confidence: As with managing a human, question the output. When you’re busy or tired, it’s easy to just go with the results it gives you. Don’t. Always analyze and question it.

Taking on AI-driven workload creep

Let’s face it: The great promise of AI is that it will take over repetitive, manual tasks, which will save you an incredible amount of time. What isn’t talked about as much is that it also can create a new workload — one that can be exhausting in a whole new way.

“Is AI saving people time? The short answer is yes,” says J.P. Gownder, vice president and principal analyst with Forrester Research. “But people also are being overwhelmed with overproduced things. Everyone wants to look busy and they’re producing more, but not necessarily better. Managers have to push back on that or it’s not really saving you time.”

In a multi-year study by Upwork, the largest online freelance marketplace, 77% of employees reported that AI had increased their workload. The report noted that a boost in productivity comes with a “significant emotional and relational cost,” with 88% of workers who saw the highest productivity gains also feeling burned out. And IDC’s Future of Work 2026 survey reported that 24% of IT workers report increased workload as a top AI concern.

Here are ways to combat the problem:

• Keep it short: Part of the prompt — always — should be to tell any AI tool to be concise.
• Build an anti-slop culture: Don’t simply accept and pass on workslop. It’s insulting for a co-worker to have to deal with pages of largely useless information.
• Filter the noise: When everyone on a team starts using AI, the volume of Slack messages, long-form memos, and data reports skyrockets. Don’t treat it all with equal importance. Practice radical prioritization.
• Manage the transcript deluge: Stop wading through 40-page meeting transcripts that bury action items. Instead, prompt the system to produce a concise summary focused strictly on deliverables or status updates.
• Reduce the AI blast radius: When asked to fix a bug, AI tools often rewrite hundreds of lines of unrelated code, multiplying your code review time. Prevent this by instructing the tool to isolate its changes only to the specific function or file in question.

Managing the AI mental tax

Using AI often necessitates a different kind of mental processing, changing what had been the natural pacing of your day and dramatically increasing context switching. Instead of simply building and testing, someone might be jumping back and forth between auditing, fact-checking, prompting, and re-prompting. To manage strain and protect your focus, new strategies are needed.

Published this past March in the Harvard Business Review, a study by Boston Consulting Group and the University of California, Riverside, surveyed 1,500 workers and coined the term “AI brain fry.” The researchers found that juggling multiple AI tools causes decision fatigue and increases errors.

How to combat the problem:

• Work in batches: Continuously reviewing AI output as it comes in can quickly lead to mental burnout. Dedicate blocks of time throughout your day to interact with your AI tools.
• Create analog islands: Your brain needs time to decompress, and that means taking a break from digital processing… and from screen time in general. Make time in your day to step away from screens, such as taking a 15-minute walk or reading a book instead of watching a video online.
• Know when to step in: Instead of endlessly tweaking prompts to get a perfect result, it is often faster and less mentally taxing to manually write or refactor the final 20% yourself.
• Create base prompts: Writing custom prompts that include everything from guardrails to tone instructions for every new project quickly drains your mental energy. Instead, build two or three reusable system prompts, such as one for refactoring legacy code and another for drafting API docs, and use them as templates.

Proving your human value in a new job market

With companies regularly using AI-based applicant tracking systems to filter resumes, and AI actively shifting job responsibilities and skills requirements, the strategy for how you apply for roles and handle interviews is changing.

Leo Freitas, an analyst and research manager at IDC Research, says it’s critical for job applicants to show potential employers what they can do that machines cannot. “You need demonstrable achievements,” he adds. “It’s good to show highly human skills.”

How to combat the problem:

For your resume:

• Mirror their language: Use the exact language from the job description. Traditional applicant tracking systems rely heavily on structured information and keyword matching, says Teresa Hill, founder and leader of Anchor GTM, a growth marketing consultancy. That means if a posting says “product marketing manager,” don’t just write “PMM.” Write both.
• Keep it simple: Use standard section headers, like “Experience” and “Education.” Creative alternatives and formatting can confuse parsers.
• Avoid AI writing: Use AI to help structure your thinking, then edit until the copy sounds natural and authentically human.
• Swap responsibilities for metrics: To stand out, especially with AI scanners, tie as many bullet points as possible from your work to business outcomes.

For the interview:

• So, how do you use AI? Every interviewer eventually asks some version of this question. The best answers focus on judgment vs. simply name-dropping tools. Explain what you automate, what you never automate, and why.
• Show that you’re a gatekeeper: AI tools can generate code or copy instantly, but they also introduce errors. To stand out, show that you know how to audit, verify, and safeguard quality.
• Focus on learning: Don’t emphasize your expertise with a specific AI tool. Focus on being someone who is adaptable and learns quickly, Hill says. 
• What sets you apart from a machine: Show, don’t tell. Give work examples that demonstrate that you know how to be creative, collaborative, and problem solve. Show metrics whenever possible.
• Demonstrate that you know the limits: Make it clear that you know when to use AI and what not to let it touch without heavy review. 

Future-proofing your career in a shifting tech market

The anxiety echoing through the tech industry is tangible as companies reallocate corporate capital toward automation. While both Gownder and Freitas emphasize that there is far more fear than actual AI-driven layoffs, the shift in corporate spending is undeniably stoking job insecurity.

“There’s this apocalyptical view that AI will take everyone’s job in a few years,” says Freitas. “I don’t see that happening, but many things will change in the nature of how we work. I don’t think the world is going to end tomorrow. But it’s always good to do a self-assessment and look at whether AI can do what you’re doing now.”

How to combat the problem:

• Use this technology to your advantage: Approach AI as a new tool, not a replacement. Use it to make yourself better and faster at your job. “I look at AI like it’s another new tool, and I’m going to learn it like I’ve learned any other tool,” says Jones.
• Don’t bury your head in the sand: Take a look at what you do and consider if it could be done by AI.If your role is highly automatable, think about switching to a more advanced position or to a role, like security, that more clearly needs a human in the loop.
• Take ownership of your career: Expand your knowledge and skills. Find courses and certifications (many are free online) and take advantage of employers’ training programs.
• Work with the business side: Make sure you understand the business — its long-term goals, competitive market, and jargon. Be the bridge between the technical and business sides of the company, giving presentations and solving business problems with technology.
• Highlight your in-house expertise: When you have institutional knowledge, make sure you are openly using it to benefit the business. Your knowledge can be your key differentiator.
• Push the business forward: Think about the next app or customer-facing system that will propel the business forward. Be the one who is advancing the company with tech.
• Continue to adapt: Don’t get stuck in your anxiety. Keep being curious and working your learning muscles. 

More on AI in the workplace:

• Burned out by bots: The rise of prompt fatigue in the workplace
• The AI tech job slaughter gets real
• Increased AI expectations without guidance leads to employee burnout
• ‘Botsitting’: The AI time-savings killer only governance can stop
• Here are the top AI certifications that will get you hired and promoted
• How to curb hallucinations in Copilot (and other genAI tools)

After more than 30 years the cybersecurity field, Keith Jones recently realized that his role had changed, from being a single contributor to manager of a fairly large team. And this team was getting a lot accomplished — tasks that used to take up a huge chunk of his workday.

No, his company hadn’t hired a group of new employees to work under him. He simply accelerated his use of artificial intelligence tools. Now, instead of grinding through a lot of basic tasks, that work is done for him while he focuses on bigger-picture work.

“It really feels like I have a team behind the scenes, but what I have is Claude [Anthropic’s AI tool],” says Jones, who currently works as a cybersecurity researcher. “I’ve been thinking for the last several months about how much differently I work now than I did a year ago, when I would sit and write all the low-level stuff before I could get to the 10% of the good stuff I really wanted to focus on. Now I can sit back and say, ‘Give me three different ways to solve this problem.’”

Most people working in the technology field, like Jones, have had to figure out how best to work with AI. The technology has come on strong, with many companies making its use mandatory and actively evaluating whether employees are faster and more efficient because of it. And while it is boosting productivity and taking over the burden of repetitive, manual tasks, it’s also creating a new level of stress and a dizzying kind of mental exhaustion.

So what can tech workers do about the heavier mental load that comes with using AI, on top of escalating worries about the safety of their own jobs? AI users and industry analysts say there are specific ways to ease some of those burdens and prepare for a changing job market.

Combating the slop factor

When it comes to working with LLM tools, a well-known issue is dealing with AI workslop and hallucinations. The slop is AI-generated output that is low-quality, buzzword-heavy, and generic. It also can refer to bloated, boilerplate code. Hallucinations are inaccurate or completely made-up results. AI routinely offers this messy or incorrect information with total confidence, giving users a false sense of security.

Using this bad data can lead to anything from minor software bugs to severe liabilities. “Don’t believe the machine is infallible,” says Craig Shue, computer science professor and department head at Worcester Polytechnic Institute (WPI). “That’s when bugs will start working in. There’s a lot of misinformation on the internet, and that could be what the LLM is grabbing and using.”

Here are ways to combat the problem:

• Make AI show its work: Ask it to cite its sources or explain its reasoning. Example prompt: Explain the logic and show the steps before writing the code.
• Give the AI a source of truth: Instead of letting the AI search the internet for information, give it the exact source material (reports, transcripts, data sheets) to base its output on, telling it to use only the information provided.
• Validate. Validate. Validate: Never let AI publish code directly to the main project without first reviewing and running it locally. Similarly, never take AI output and simply move it on to the next person in the project. Every single AI output needs review.
• Don’t be fooled by confidence: As with managing a human, question the output. When you’re busy or tired, it’s easy to just go with the results it gives you. Don’t. Always analyze and question it.

Taking on AI-driven workload creep

Let’s face it: The great promise of AI is that it will take over repetitive, manual tasks, which will save you an incredible amount of time. What isn’t talked about as much is that it also can create a new workload — one that can be exhausting in a whole new way.

“Is AI saving people time? The short answer is yes,” says J.P. Gownder, vice president and principal analyst with Forrester Research. “But people also are being overwhelmed with overproduced things. Everyone wants to look busy and they’re producing more, but not necessarily better. Managers have to push back on that or it’s not really saving you time.”

In a multi-year study by Upwork, the largest online freelance marketplace, 77% of employees reported that AI had increased their workload. The report noted that a boost in productivity comes with a “significant emotional and relational cost,” with 88% of workers who saw the highest productivity gains also feeling burned out. And IDC’s Future of Work 2026 survey reported that 24% of IT workers report increased workload as a top AI concern.

Here are ways to combat the problem:

• Keep it short: Part of the prompt — always — should be to tell any AI tool to be concise.
• Build an anti-slop culture: Don’t simply accept and pass on workslop. It’s insulting for a co-worker to have to deal with pages of largely useless information.
• Filter the noise: When everyone on a team starts using AI, the volume of Slack messages, long-form memos, and data reports skyrockets. Don’t treat it all with equal importance. Practice radical prioritization.
• Manage the transcript deluge: Stop wading through 40-page meeting transcripts that bury action items. Instead, prompt the system to produce a concise summary focused strictly on deliverables or status updates.
• Reduce the AI blast radius: When asked to fix a bug, AI tools often rewrite hundreds of lines of unrelated code, multiplying your code review time. Prevent this by instructing the tool to isolate its changes only to the specific function or file in question.

Managing the AI mental tax

Using AI often necessitates a different kind of mental processing, changing what had been the natural pacing of your day and dramatically increasing context switching. Instead of simply building and testing, someone might be jumping back and forth between auditing, fact-checking, prompting, and re-prompting. To manage strain and protect your focus, new strategies are needed.

Published this past March in the Harvard Business Review, a study by Boston Consulting Group and the University of California, Riverside, surveyed 1,500 workers and coined the term “AI brain fry.” The researchers found that juggling multiple AI tools causes decision fatigue and increases errors.

How to combat the problem:

• Work in batches: Continuously reviewing AI output as it comes in can quickly lead to mental burnout. Dedicate blocks of time throughout your day to interact with your AI tools.
• Create analog islands: Your brain needs time to decompress, and that means taking a break from digital processing… and from screen time in general. Make time in your day to step away from screens, such as taking a 15-minute walk or reading a book instead of watching a video online.
• Know when to step in: Instead of endlessly tweaking prompts to get a perfect result, it is often faster and less mentally taxing to manually write or refactor the final 20% yourself.
• Create base prompts: Writing custom prompts that include everything from guardrails to tone instructions for every new project quickly drains your mental energy. Instead, build two or three reusable system prompts, such as one for refactoring legacy code and another for drafting API docs, and use them as templates.

Proving your human value in a new job market

With companies regularly using AI-based applicant tracking systems to filter resumes, and AI actively shifting job responsibilities and skills requirements, the strategy for how you apply for roles and handle interviews is changing.

Leo Freitas, an analyst and research manager at IDC Research, says it’s critical for job applicants to show potential employers what they can do that machines cannot. “You need demonstrable achievements,” he adds. “It’s good to show highly human skills.”

How to combat the problem:

For your resume:

• Mirror their language: Use the exact language from the job description. Traditional applicant tracking systems rely heavily on structured information and keyword matching, says Teresa Hill, founder and leader of Anchor GTM, a growth marketing consultancy. That means if a posting says “product marketing manager,” don’t just write “PMM.” Write both.
• Keep it simple: Use standard section headers, like “Experience” and “Education.” Creative alternatives and formatting can confuse parsers.
• Avoid AI writing: Use AI to help structure your thinking, then edit until the copy sounds natural and authentically human.
• Swap responsibilities for metrics: To stand out, especially with AI scanners, tie as many bullet points as possible from your work to business outcomes.

For the interview:

• So, how do you use AI? Every interviewer eventually asks some version of this question. The best answers focus on judgment vs. simply name-dropping tools. Explain what you automate, what you never automate, and why.
• Show that you’re a gatekeeper: AI tools can generate code or copy instantly, but they also introduce errors. To stand out, show that you know how to audit, verify, and safeguard quality.
• Focus on learning: Don’t emphasize your expertise with a specific AI tool. Focus on being someone who is adaptable and learns quickly, Hill says. 
• What sets you apart from a machine: Show, don’t tell. Give work examples that demonstrate that you know how to be creative, collaborative, and problem solve. Show metrics whenever possible.
• Demonstrate that you know the limits: Make it clear that you know when to use AI and what not to let it touch without heavy review. 

Future-proofing your career in a shifting tech market

The anxiety echoing through the tech industry is tangible as companies reallocate corporate capital toward automation. While both Gownder and Freitas emphasize that there is far more fear than actual AI-driven layoffs, the shift in corporate spending is undeniably stoking job insecurity.

“There’s this apocalyptical view that AI will take everyone’s job in a few years,” says Freitas. “I don’t see that happening, but many things will change in the nature of how we work. I don’t think the world is going to end tomorrow. But it’s always good to do a self-assessment and look at whether AI can do what you’re doing now.”

How to combat the problem:

• Use this technology to your advantage: Approach AI as a new tool, not a replacement. Use it to make yourself better and faster at your job. “I look at AI like it’s another new tool, and I’m going to learn it like I’ve learned any other tool,” says Jones.
• Don’t bury your head in the sand: Take a look at what you do and consider if it could be done by AI.If your role is highly automatable, think about switching to a more advanced position or to a role, like security, that more clearly needs a human in the loop.
• Take ownership of your career: Expand your knowledge and skills. Find courses and certifications (many are free online) and take advantage of employers’ training programs.
• Work with the business side: Make sure you understand the business — its long-term goals, competitive market, and jargon. Be the bridge between the technical and business sides of the company, giving presentations and solving business problems with technology.
• Highlight your in-house expertise: When you have institutional knowledge, make sure you are openly using it to benefit the business. Your knowledge can be your key differentiator.
• Push the business forward: Think about the next app or customer-facing system that will propel the business forward. Be the one who is advancing the company with tech.
• Continue to adapt: Don’t get stuck in your anxiety. Keep being curious and working your learning muscles. 

More on AI in the workplace:

• Burned out by bots: The rise of prompt fatigue in the workplace
• The AI tech job slaughter gets real
• Increased AI expectations without guidance leads to employee burnout
• ‘Botsitting’: The AI time-savings killer only governance can stop
• Here are the top AI certifications that will get you hired and promoted
• How to curb hallucinations in Copilot (and other genAI tools)

AI agents are increasingly being deployed across the enterprise, a rapid adoption that has significantly broadened the organization’s attack surface, turning sharable AI agent resources and configuration files into backdoors, security experts warn.

AI-assisted software developers have been increasingly targeted through malicious IDE extensions, rogue MCP servers, and poisoned AI skills, all of which provide attackers inroads into organizations’ development pipelines and beyond. But these AI helper resources are not the only types of instruction files that developers and users share with one another when making use of AI coding assistants and command-line interface (CLI) agents.

For example, Anthropic’s Claude Code CLI agent loads system prompts from a file called CLAUDE.md. This file contains instructions that are sent to the LLM along with every user prompt to avoid having to repeat rules, user preferences, and persona definitions for the model.

CLAUDE.md can be used globally for all projects or be used on a per-project basis to include instructions about how the LLM should operate within that project. It’s not unusual for CLAUDE.md files to be included in a shared repository to ensure project-relevant consistency in the conventions developers use when working with Claude Code.

Other coding agents have similar files, such as OpenAI Codex’s AGENTS.md or Google Gemini’s GEMINI.md. AI-assisted IDEs such as Cursor or Cline have .cursorrules and .clinerules. GitHub Copilot has .github/copilot-instructions.md. Then there are JSON configuration files that could also contain executable code, such as mcp.json, hooks.json, or settings.json. Hooks are a popular way to deliver scripts and commands based on triggers during an agentic loop.

All these files could hide malicious code or instructions and should be regularly checked and validated, especially if imported from the internet along with a repository.

Researchers from security firm Mitiga recently shed light on this threat, releasing a report on code repositories they found in the wild with malicious instructions injected in such files. The files instructed the target agent to exfiltrate all prompts typed by the user, including all sensitive information they might contain, as well as environment variables and other credentials used by the agent. The researchers dubbed this backdoor attack technique “PromptLogger,” and it is one enterprise security teams and developers are likely to see more of in the future.

“Traditional keyloggers capture keystrokes and send them to an attacker,” Mitiga’s researchers write in their report on the attack vector. “PromptLogger-style behavior captures something richer: the prompts and sometimes responses exchanged with an attacker. That matters because prompts increasingly contain source code, architectural plans, credentials pasted for troubleshooting, internal documentation, debugging output, customer samples, business logic, and operator intent.”

Enterprises have been apprehensive about corporate data leakage via shadow AI use for good reason. This type of attack enables surveillance of corporate even on vetted and sanctioned AI tools.

Moreover, this attack leaves no malicious binary on disk, does not inject code into other processes, and has no classic persistence mechanisms. As a result, it won’t be detected by EDRs or from a workstation monitoring perspective, because it looks like normal tool usage given that the agent itself is performing the exfiltration.

Exfiltration to external cloud-hosted databases

Mitiga’s researchers found and reported multiple examples of agent instruction file poisoning on GitHub repositories. None were popular repositories accessed by a large number of developers, but they don’t need to be. Links to these repositories could be sent to victims in targeted attacks, as has been seen in fake recruitment attacks where developers are asked during the interview process to clone GitHub projects containing malicious code.

One example was a DevOps repository containing poisoned .cursorrules and .github/copilot-instructions.md. The repository contained a full-stack application built with React + Vite frontend, along with Express API, PostgreSQL, nginx configuration, Docker containers, GitLab CI jobs, and AWS infrastructure setup files for Terraform and Terragrrunt. In other words, everything needed to deploy that application.

Despite the README.md file being benign, the agent instruction files distributed in the repo contained instructions for the AI agent loading them to execute a curl command silently without mentioning it to the user before responding to their prompt. That command copied the user’s prompt to a database hosted on the Supabase service using a hardcoded access token.

In another case the researchers found an MLOps repository with an end-to-end machine learning pipeline for training, evaluating, and deploying computer vision models. The repository had a .clinerules file that instructed the agent to verify its environment by collecting several environment variables and command outputs and send them to a site hosted on the Webhook.site service. The collected env variables included Weights & Biases (WANDB) API key, AWS access key, GitHub access token, and MLFlow tracking URL.

“This is direct credential collection,” the researchers’ report notes. “Webhook.site gives the operator an easy request sink that can be created anonymously and monitored in real time.”

A similar environment secrets collection attack was detected in another repository that claimed to be a starter kit for FastAPI, a framework for API development. The .cursorrules and CLAUDE.md files in the repository instructed the agent to send the contents of the local .env file to a Webhook.site endpoint supposedly for synchronization across the team. However, it also contained instructions to suppress the command output and hide this action from the user.

Finally, a GEMINI.md file hosted inside a repository masqueraded as an environment validation step required to pass “Zero Trust” compliance checks. As part of this check, the agent was told to inject an initialization block into every generated or modified Python file, which would then scan the OS environment for any values with key, secret, token, or pass in their names and exfiltrate them to a Pipedream endpoint.

This technique exceeds just poisoning the agent and using it for exfiltration. Instead, it uses the agent to inject backdoor code into other Python files that might be copied to other systems, including continuous integration (CI) jobs, containers, and production workloads.

Some intentional behavior that involves agent instruction files could create risk without the developers realizing it. For example, the researchers found a repository where the CLAUDE.md contained instructions to use the Snipara MCP during commits to store documentation, dependencies, environment variables, and implementation context.

Snipara is a remote cross-project memory layer for AI agents so this use case seems legitimate and intentional. However, if not approved by the security team, it creates a second system that can hold credentials and sensitive data outside the visibility of monitoring systems.

AI agent workflows under attack

What the PromptLogger technique highlights is that attackers are not only breaking down agentic workflows to find new enterprise weak points but transforming those workflows into tools for performing criminal work on their behalf, undetected and unmonitored.

“AI instruction files were designed to make coding assistants more useful,” Mitiga’s researchers emphasize. “They define project conventions, preferred commands, memory behavior, hooks and tools usage. In practice, they also create a security-relevant layer that many teams still treat as documentation.”

This is just one example of a trend that find AI agents fast becoming an unmonitored blind spot that attackers are proving quick to exploit for initial access.

Last month, researchers from security firm AIR built a proof-of-concept malicious skill file, published it to a popular marketplace and promoted it on Instagram. The skill — a file containing task-specific instructions for AI agents — was eventually installed by more than 26,000 designers and marketers, many working for companies.

AI agent skill files are no different in principle from CLAUDE.md or .cursorrules. They contain instructions that AI agents execute at various stages of operation. As such, inspecting such files when they are created or modified is imperative.

Mitiga researchers propose several static scan patterns that could reveal risky commands in such files, but they also advise security teams to monitor developer workstations for traffic to services such as Webhook.site, Pipedream, Supabase, or Telegram Bot API.

Unexpected outbound HTTP requests before or after assistant responses; repeated POST requests containing environment variables, project paths, or prompt text; and the addition of new MCP servers, URL overrides, or tool endpoints to agent configurations should be investigated.

KI wird auch in Unternehmen allgegenwärtig. Aus IT-Sicht erfordert das vor allem ein lückenloses Monitoring der Aktivitäten, die in Zusammenhang mit Large Language Models (LLMs) und KI-Agenten erfolgen. Glücklicherweise ist der DevOps-Welt vor einiger Zeit eine Tool-Kategorie entsprungen, mit der diese Herausforderung zu meistern ist.

Lösungen aus dem Bereich AIOps (manchmal auch als AgentOps bezeichnet) stützen sich dabei in vielerlei Hinsicht auf ähnliche Ansätze wie DevOps-Werkzeuge: Sie überwachen Systeme auf fehlerhaftes Verhalten und kennzeichnen sämtliche Vorgänge, die vom Normalzustand abweichen, um diese anschließend eingehender zu analysieren.

Geht es um die Entscheidung darüber, welches AIOps-Tool für den eigenen Anwendungsfall am besten geeignet ist, ist vor allem die Größe und Art der Agentic-AI-Systeme und des Projekts zu berücksichtigen. Im Mittelpunkt stehen Fragen wie:  

• Sollen bestehende Produkte oder Anwendungen um agentische Funktionen ergänzt oder Agentic-AI-Systeme von Grund auf neu aufgebaut werden?
• Liegt der Fokus darauf, LLMs möglichst stabil zu betreiben oder geht es eher darum, neue Ansätze iterativ weiterzuentwickeln?
• Steht die KI selbst im Fokus oder soll die Technologie lediglich ein bestehendes Stack optimieren?

Egal, wie Ihre Anforderungen konkret aussehen – die nachfolgend aufgeführten AIOps-Tools können diese abdecken.

1. AgentOps.ai

Wenn Agenten in Teams zusammenarbeiten, ist es unerlässlich, ihre Konversationen zu tracken, um zu verstehen, was vor sich geht – und um Bugs beheben zu können.

Das können Developer mit dem SDK von AgentOps.ai bewerkstelligen und dabei unter anderem Details wie Token-Verbrauch, Kosten und Latenz zu erfassen. Das Tool ist sowohl als Service als auch als On-Premises-Lösung verfügbar.  

• Preisgefüge: Basic-Tarif kostenlos nutzbar, Pro-Plan ab 40 Dollar pro Monat;
• Alleinstellungsmerkmal: „Replay“-Analytics mit „Time-Travel-Debugging“;
• Ideal geeignet für: komplexe Debugging-Tasks im Zusammenhang mit KI-Agenten.

2. Arize Phoenix

Auch die Open-Source-Plattform Arize Phoenix unterstützt dabei, Prompts und LLM-Antworten zu debuggen – in erster Linie mit robusten Tracing-Funktionalitäten. Die Ergebnisse lassen sich zudem mit einem Score versehen, um präziser iterieren zu können.

Die AIOps-Lösung trackt die Ergebnisse und Tool-Aufrufe einer Vielzahl wichtiger Plattformen (etwa Anthropic, AWS und OpenAI), die von gängigen Frameworks wie LangChain, LlamaIndex oder DSPy initiiert werden. So wird sichtbar, welche Daten spezifische Antwortketten triggern.

• Preisgefüge: Free-Tarif kostenlos nutzbar, Pro-Plan ab 50 Dollar pro Monat;
• Alleinstellungsmerkmal: „LLM-as-a-Judge“-Metriken, um die Qualität zu tracken;
• Ideal geeignet für: Teams, deren Fokus darauf liegt, schrittweise die Genauigkeit und Qualität von KI-Systemen zu verbessern.

3. BigPanda

BigPanda hat sich in der Vergangenheit bereits einen Namen gemacht, wenn es darum ging, die Performance komplexer Systeme zu überwachen. Inzwischen widmet sich das Unternehmen verstärkt der Problemerkennung und -behebung im Zusammenhang mit fehlgeleiteten KI-Modellen.

Das Hauptsystem von BigPanda stützt sich auf historische Daten und Machine-Learning-Algorithmen, um diese Problemstellungen zu identifizieren. Ein dedizierter Agenten-Layer verbindet die problematischen Nodes mit fehlerhaften Modellen und leitet parallel Warnmeldungen an die zuständigen menschlichen Spezialisten weiter.

• Preisgefüge: „wertbasiertes“ Preismodell, auf Anfrage;
• Alleinstellungsmerkmal: automatisierte Triage;
• Ideal geeignet für: große Teams, die die Alert Fatigue, die mit einem ausgedehnten Kundenstamm einhergeht, reduzieren möchten.

4. Braintrust

Um einen effektiven Optimierungszyklus für KI-Agenten aufzusetzen, ist ein robuster Feedback-Loop erforderlich – von den Produktionsdaten bis hin zum nächsten Agenten-Output. Das AIOps-Tool Braintrust überwacht die Produktionsauslastung und erstellt Testvektoren, die darüber Auskunft geben, wie stark die KI durch Drift oder Regression von ihrem Kurs abweicht.

Diese Lösung kann das Gros der Testing- und Scoring-Feedback-Schleife automatisieren und problematische Muster identifizieren sowie adressieren. Zentraler Bestandteil dieser Lösung ist außerdem ein spezialisierter Data Store, der große (und auch tiefgehend verschachtelte) Test-Sammlungen und deren Ergebnisse nachverfolgen kann.

• Preisgefüge: kostenloser Starter-Tarif, Pro-Plan ab 249 Dollar pro Monat;
• Alleinstellungsmerkmal: hochskalierbare Erfassung von Trace-Daten;
• Ideal geeignet für: Teams, die mit Hilfe von Continuous Testing robuste KI-Guardrails entwickeln wollen.

5. Chronicle Labs

Die Plattform von Chronicle Labs ist darauf ausgelegt, neue Versionen von Agenten, die in die Produktion ausgerollt werden sollen, entsprechend vorzubereiten und im Rahmen einer Reihe von Nutzungstests und Regressionsfällen zu überprüfen.

Dabei verspricht das Unternehmen Tests unter realistischen Bedingungen: Zur Plattform gehört eine Reihe von Tools, die die Telemetriedaten der Produktion nach soliden Testvektoren durchsuchen. Das Ziel dabei ist, KI-Agenten vollumfänglich mit Prompts und anderen Herausforderungen zu testen, um ihre Funktionalität zu gewährleisten, sobald sie ihre Laborumgebung verlassen.  

• Preisgefüge: auf Anfrage;
• Alleinstellungsmerkmal: Back-Testing-Optionen für komplexe Test-Regime;  
• Ideal geeignet für: Teams, die nach besonders leistungsstarken KI-Modellen streben, die in der Realität verankert sind.

6. Comet Opik

Ein Dashboard zu erstellen, ist eine Möglichkeit, sämtliche Daten zu tracken, die KI-Agenten zugeführt oder von ihnen gesendet werden. Genau das geht auch mit Comet Opik.

Das Tool befähigt DevOps-Teams dazu, jeden Call zu tracken und eigene Automatisierungsroutinen hinzuzufügen, um die Ergebnisse zu untersuchen. Diese lassen sich zudem anhand diverser Metriken bewerten oder zum selben Zweck auch an ein anderes LLM weiterleiten.  

• Preisgefüge: kostenlose Open-Source- und Cloud-Optionen, Pro-Modell ab 19 Dollar pro Monat;
• Alleinstellungsmerkmal: Auto-Scoring-Funktion mit mehr als 30 Metriken, um Traces zu evaluieren;
• Ideal geeignet für: Teams, die sich auf RAG- und Agentic-Workflows konzentrieren.

7. Datadog

DevOps-Teams, die mit der Lösung von Datadog Logs über verschiedene Services hinweg tracken, können damit auch LLM-Prozesse überwachen. Das Tool erfasst Performance-Daten wie die „Time to first Token“ und liefert Einblicke zu möglichen Problemursachen – beispielsweise Memory-Mangel.

Die Ergebnisse werden dann in Cost-Tracking-Mechanismen eingespeist, so dass die Buchhaltung auch antizipieren kann, wann das Budget erschöpft ist.

• Preisgefüge: kostenlose Version mit begrenztem Umfang verfügbar, Pro-Tarif ab 15 Dollar pro Monat und Host;
• Alleinstellungsmerkmal: große Installationsbasis – und die Lösung ist nicht auf KI beschränkt;
• Ideal geeignet für: Enterprise-Teams, die mit etablierter Infrastruktur arbeiten.

8. Dynatrace

Bei Dynatrace beschäftigt man sich schon seit mehr als zwei Dekaden damit, Datenflüsse über das gesamte Stack hinweg zu erfassen. Inzwischen hat der Anbieter den Funktionsumfang seiner Plattform auch auf KI-Agenten erweitert.

Der Fokus liegt dabei darauf, komplexe Agenten-Netzwerke zu unterstützen, die Performance- oder Security-Probleme erkennen und diese anschließend innerhalb definierter Leitplanken beheben sollen.

• Preisgefüge: ab 7 Dollar pro Monat und Host;
• Alleinstellungsmerkmal: autonomes Monitoring für große KI-Installationsbasen;
• Ideal geeignet für: komplexe, hybride Umgebungen in denen LLMs mit traditionellen Services kombiniert werden.

9. Galileo

Selbst wenn vorab rigorose Tests gefahren werden, lässt sich die Performanz von KI-Systemen im Produktivbetrieb nicht exakt vorhersagen.  

Das Galileo-Tool (aus dem Hause Cisco) bietet Guardrails, die die Performance tracken und dabei alles erfassen, was von der „Ground Truth“ abweicht. Die „LLM-as-Judge“-Systeme hat der Anbieter zu kompakten Modellen verdichtet, die sich auch lokal ausführen lassen.

• Preisgefüge: kostenloser Tarif verfügbar, Pro-Modell ab 100 Dollar monatlich;
• Alleinstellungsmerkmal: Echtzeit-Guardrails für bereitgestellte Agenten; 
• Ideal geeignet für: Security-fokussierte KI-Installationen, die besonderen Schutz hinsichtlich Halluzinationen und Datenlecks erfordern.

10. Grafana

Grafana ist schon seit längerem die erste Anlaufstelle, wenn es um Open-Source-Telemetrie geht. Inzwischen trackt die Cloud-Plattform auch, wie sich die KI-Antworten in einem agentischen Netzwerk im Zeitverlauf entwickeln, um sowohl Modell-Drift als auch Halluzinationen zu verhindern.

Über einen Cloud-Assistenten können Anwender das Grafana-Dashboard voll und ganz auf ihre spezifischen Observability-Bedürfnisse anpassen. Das Tool umfasst dabei auch Analysemöglichkeiten auf KI-Ebene, die dafür sorgen, dass Modelle geflaggt werden, die zwar schnell reagieren, aber falsche Antworten liefern.

• Preisgefüge: kostenlose Version verfügbar, Pro-Tarif ab 19 Dollar pro Monat;
• Alleinstellungsmerkmal: Full-Stack-Tool mit vollständig integrierten LLMs;
• Ideal geeignet für: Systeme im Enterprise-Maßstab, die KI integrieren.

11. Helicone

Helicone ist als intelligenter Netzwerk-Proxy konzipiert, der alle Modellanfragen routet und dabei zuverlässige Debugging-Protokolle der durchlaufenden Daten erstellt.

Diese lassen sich in übersichtliche Diagramme umwandeln, die es erleichtern, Latenzprobleme oder Modellausfälle zu visualisieren. Darüber hinaus bietet diese Lösung auch die Möglichkeit, die KI-Kosten zu tracken.

• Preisgefüge: kostenlose Stufe verfügbar, Pro-Tarif ab 79 Dollar pro Monat;
• Alleinstellungsmerkmal: Integration auf Proxy-Basis;
• Ideal geeignet für: Dev-Teams, die möglichst schnell bessere Monitoring-Funktionen einziehen wollen.

12. Laminar

Die Open-Source-Lösung Laminar arbeitet eng mit dem Open-Telemetry-Projekt zusammen, um Agenten zu tracken, die im Produktiveinsatz sind. Eventuelle Fehler und Ausfallmuster sind über Protokolldateien nachvollziehbar, die über ein Komprimierungsschema effizient gespeichert werden.

Entwickler können Traces mit einer SQL-ähnlichen Sprache durchsuchen. Bei Bedarf ermöglichen die Traces auch, in der Zeit „zurückzuspulen“ und dieselben Debugging-Inputs erneut „abzuspielen“. Das Ziel ist es, umfassende Transparenz darüber zu schaffen, inwieweit KI-Agenten die Geschäftsziele erfüllen.

• Preisgefüge: kostenlose Stufe verfügbar, Starter-Tarif ab 30 Dollar pro Monat;
• Alleinstellungsmerkmal: die quelloffene Lizenzierung macht Self-Hosting zu einer praktikablen Option;
• Ideal geeignet für: Teams, die in der Lage sind, die mit Open-Source-Lösungen verbundenen Verantwortlichkeiten vollumfänglich zu übernehmen.

13. LangSmith

Echtzeitdaten sind unerlässlich, um Multi-Agenten-Systeme in der Produktion zu managen. LangSmith verfolgt Kosten, Tools und Fortschritte bei der Lösungsfindung nach. Dabei wird eine breite Palette von Agenten über SDKs für Python, TypeScript, Go und Java abgedeckt.

Auch diese Lösung basiert auf OpenTelemetry, überwacht KI-Systeme auf Anomalien und gibt Alarmmeldungen über Dashboards sowie weitere Kommunikationskanäle wie PagerDuty aus. Das Tool kann auch tiefgehende Analysen bieten, um Probleme wie Themen-Cluster oder ungewöhnliche Fehlermuster zu Tage zu fördern.

• Preisgefüge: kostenloser Seat für Solo-Entwickler, Team-Pläne ab 39 Dollar pro Seat und Monat;
• Alleinstellungsmerkmal: systematischer Ansatz für Prompt-Regressionstests;
• Ideal geeignet für: Teams, die sich bereits auf das LangChain- oder LangGraph-Framework verlassen.

14. Lunary

Speziell wenn es um Chatbots und KI-basierte Assistenten geht, macht es Sinn, auch die Benutzererfahrung zu erfassen. Für diese Aufgabe bietet Lunary einen Proxy. Dieser überwacht sämtliche Interaktionen und erstellt anschließend Analytics-Dashboards, um Kennzahlen zu messen – zur User Experience oder auch den Modellkosten.

Wenn Prompts nicht perfekt sind, ermöglicht Lunary zudem, den zugrundeliegenden Text so lange zu überarbeiten, bis die richtigen Antworten ausgegeben werden. Dank seiner Proxy-Struktur und des gängigen API-Formats soll Lunary mit jedem LLM und jedem Framework funktionieren.

• Preisgefüge: kostenloser Tarif verfügbar, Team-Plan ab 20 Dollar pro User und Monat;
• Alleinstellungsmerkmal: tiefgehende Integration von menschlichen Spezialisten, wenn es darum geht, Ergebnisse zu überprüfen und zu optimieren;
• Ideal geeignet für: Startups, die auf schnelle Prompt-Innovationen aus sind.  

15. NewRelic

Diese Plattform war ursprünglich dazu gedacht, die Leistung von Webanwendungen zu überwachen. Mittlerweile ist die Lösung jedoch performant genug, um auch die Datenflüsse in komplexen Agenten-Ökosystemen zu tracken.

Das KI-gesteuerte Monitoring von NewRelic erfasst sogenannte „Golden Signals“, die über den gesamten Lifecycle Anhaltspunkte für Fehlverhalten liefern können. Die Details der Interaktionen werden über Protokolle wie MCP erfasst, die Informationen anschließend den für die Performance verantwortlichen Engineers zur Verfügung gestellt.

• Preisgefüge: kostenloser Tarif vorhanden, Preise auf Anfrage;
• Alleinstellungsmerkmal: Full-Stack-Support mit Hunderten von Integrationsmöglichkeiten für andere Tools;
• Ideal geeignet für: eingespielte Enterprise-Teams, die auch KI einbinden.

16. Nova AI Ops

Die Nova-AI-Ops-Plattform stellt ein Team von Agenten bereit, das Cloud-Instanzen überwacht und diese (zumindest teilweise) mit Self-Healing-Fähigkeiten ausstattet.

Jeder Agent nutzt dabei eine Kombination aus prädiktiver KI und Machine Learning, um die Cloud-Telemetrie auf Anomalien zu überwachen. Anschließend berechnet die KI den „Blast Radius“ und entscheidet, ob es sich um ein Problem handelt, das sich automatisch beheben lässt – oder einem menschlichen Supervisor übermittelt wird.

• Preisgefüge: kostenlose Testversion verfügbar, Bezahltarife ab 16 Dollar pro Monat und Nutzer;
• Alleinstellungsmerkmal: Lösung mit Fokus auf Software Reliability Engineering;
• Ideal geeignet für: Teams, die eine Lösung suchen, die den gesamten SRE- und DevOps-Stack abdeckt.

17. Splunk

Die Plattform von Splunk ist mittlerweile ebenfalls vollständig KI-fähig und bietet Tracking-Möglichkeiten für Agenten, die denen zur Nachverfolgung von Microservices ähneln. Dazu kommen umfangreiche Predictive-AI-Funktionen, um Protokolle und ihre Inhalte in schnelle Lösungen zu übersetzen.

Per KI werden KI-Modelle, die etwa über MCP angebunden sind, getrackt und ihr Verhalten überwacht. Gleichzeitig haben Anwender die Möglichkeit, detailliert zu analysieren, was funktioniert und was nicht.

• Preisgefüge: nutzungsbasierte Abrechnungsoptionen, Observability Cloud ab 15 Dollar pro Monat und Host;
• Alleinstellungsmerkmal: auf Enterprise-Stacks skalierbar;
• Ideal geeignet für: Teams, die Agentic AI in Legacy-Systeme integrieren.

18. Super Penguin

Um den CFO vor bösen Überraschungen zu bewahren, ist SuperPenguin die richtige Lösung: Es erfasst Verbrauchsdaten von KI-Systemen und ermöglicht es, die anfallenden Kosten zu antizipieren.

Die Zielsetzung besteht bei diesem Tool darin, möglichst fundierte Schätzungen zu den Gesamtkosten jedes Produkts zu liefern. Diese werden dazu auf Kunden, Funktionen und Teams gemappt. Bei plötzlichen Schwankungen löst ein „Spike-Detektor“ einen Alarm aus.

• Preisgefüge: kostenlose Version für Einzelnutzer, Bezahltarife ab 30 Dollar pro Monat;
• Alleinstellungsmerkmal: leistungsstarke KI-Accounting-Funktionen inklusive Rechnungsabgleich und Nutzungserfassung;
• Ideal geeignet für: Teams, die einen präzisen Überblick über die KI-Kostenstruktur benötigen.

19. Vellum

Diese Lösung ermöglicht es, Prompt-Ketten auf Metaebene zu managen. Zudem wird Vellum inzwischen auch als eine Art Personal Assistant vermarktet, der über vorgefertigte Konnektoren zu zahlreichen Services verfügt – etwa Gmail.

Eine Komponente, die vielen Teams das Leben leichter machen kann ist dabei ein „LLM Cost Optimizer“, der verspricht, kostengünstigere Wege aufzutun, um bestimmte Prompts auszuführen. Das kann laut Anbieter zu Einsparungen von bis zu 60 Prozent führen.

• Preisgefüge: kostenlose Testversion verfügbar, Bezahltarife ab 30 Dollar pro Monat;
• Alleinstellungsmerkmal: Fokus auf multimodale Pipelines für echte Agentic-AI-Lösungen;
• Ideal geeignet für: Produkt-Teams mit komplexen Prompt-Engineering-Workflows.

(fm)

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

There is a lot of talk about the coming enterprise AI reality, in which AI finally arrives in production systems. You might not know it, but this reality—or nightmare, depending on how you handle it—is already happening.

It all starts with a “pilot,” a “prototype,” or a “side project.” Maybe someone builds an internal dashboard with an agent. The dashboard quickly becomes indispensable, and all of a sudden the experiment becomes production. Along the way, no one thought to ask the boring, inconvenient questions: What exactly was pulled from npm, PyPI, or Docker Hub? How is (or was) authentication configured? Is anyone watching for supply chain attacks against the tools and libraries the agents chose?

And it’s not just a one-off project here or a couple of applications there. AI is enabling organizations to generate more code and ship more products and projects, more quickly, than ever before. By the time security teams get a look, the business is hooked and there’s no turning back. An actual nightmare has begun.

There are three major problems that make the nightmare real.

Components you never explicitly chose

When you ask an AI agent to build an app, it doesn’t just spit out a single script. It quietly assembles an entire ecosystem around whatever problem you’ve described to it. It pulls in a web framework, grabs a bunch of libraries, stands up databases, and then it potentially builds everything on dependencies in container images.

From a productivity perspective, this is awesome. However, from a security standpoint, it’s worrisome, to say the least. When I’ve built apps like this myself, I couldn’t begin to tell you all of the components that were being used unless I went back and asked the agent to explain itself.

We live in a world where anyone can publish to npm or PyPI, and we’ve seen attackers slip malicious packages into those ecosystems or compromise ones that are widely used. Some of the recent incidents have involved security and devops tools themselves pulling a compromised dependency, running it as part of CI/CD with elevated privileges, and quietly exfiltrating secrets or tampering with builds. I personally experienced this type of compromise a couple of months ago, and had to update all of my credentials in GitHub.

Pulling unvetted code is bad; now layer AI agents on top of that. They default to whatever is easiest to discover and integrate. If a package solves a problem in front of the agent, the agent will add it. This is the old “download a random library from the Internet” problem, but now it’s on autopilot, at scale, and moving at a pace we’ve never seen before.

To solve this problem, we must provide the agents with an innate sense of our risk tolerance, an approved components list, our desires around logging, etc. We can do this with spec files and what the industry calls constitutions. Collectively, this is called harness engineering, which we will talk more about later.

Skills shifting from code to architecture

There has been a lot of hand-wringing about whether junior developers will ever really learn to code if AI is doing all of their coding for them.

That’s not what worries me.

I think it’s fine to let an agent spit out code. It’s a job they are really good at. What they are not really good at is identifying and avoiding problems in code.

I haven’t written code in quite some time. I can, but it doesn’t make sense for me to do so. What is worth my while is noticing when an agent suggests something dumb or even dangerous (or both).

For example, while working on a recent personal project, an agent proposed exposing a memory server on the public Internet with no authentication. The agent wired things up so smoothly that, at first glance, everything looked fine and just worked. But then I paused and asked, “Wait, how is this actually authenticating? Where’s the password, secret token, or OAuth in this flow?” Turns out it wasn’t authenticating and there was no password. If I hadn’t taken that beat—and then argued with the agent for a while—the app would have gone live with no protection.

So, the skills issue isn’t about whether we will lose the ability to code but rather whether we have the ability to ask questions and be discerning, and whether we have the understanding to know when something doesn’t look or even feel right. Do organizations have people who know what a dangerous software pattern looks like when the agent suggests it? You need people who can recognize when an authentication flow is too permissive, when a data store should never be exposed beyond a certain boundary, and when an architecture has become such a steaming pile of technical debt that the right answer is to throw away a whole layer and rebuild it.

You need people who know that “what works” isn’t the same as “what’s safe” or “what’s right” and who can argue back with the agent when the former doesn’t line up with the latter.

It’s not about syntax. It’s about architecture, supply chain awareness, and the willingness to say, “We’re tearing this down and doing it right,” even when the prototype looks good on the surface. Teach your AI-assisted coders basic security principles, basic architectural patterns. The AI will teach them the more advanced stuff, as long as they keep asking questions.

Agents with no harness

The third problem is that we’ve unleashed some very capable agents into our development workflows without treating them like first-class actors that need governance.

Many organizations are wiring AI assistants into a repo or IDE and letting them scaffold projects and pipelines. Maybe they bolt on a security scanner and declare “AI enablement.” That’s not a governance model, that’s optimism (and not even cautious optimism).

Indeed, a code-generating agent with broad access to your repos, your CI/CD pipeline, and your artifact registries is effectively a hyper-productive and not-very-well-trained junior developer with access to the Internet and no ingrained sense of organizational policies. It can introduce new tools, new dependencies, and new patterns faster than your review processes can handle.

In my personal projects, I’ve started to think of this as what AI coders call a harness-engineering problem. For every agent that’s responsible for building or wiring code, I try to put other agents in the loop that are responsible for tearing it down, at least conceptually. For example, one agent focuses on security and looks for obvious vulnerabilities and bad practices. Another looks at architecture and points out when the app design is veering into unmaintainable territory. A third looks at performance and reliability issues, which are themselves a kind of security concern when you think about things like denial of service and resource exhaustion. Pair this with constitutions that give the agents first principles on architecture, security, and design, and this is no longer vibe coding, it’s harness engineering at scale for all of your projects.

What I am doing isn’t perfect; there is no perfect in this space, because these are non-deterministic, statistical tools. But, many organizations aren’t even doing this. In effect, their agents are freelancing. They’re vibe coding. They’re not constrained to trusted registries or hardened base images. They’re not required to log their decisions in a way that security can audit. No one owns the harness, and that means a lot of implementation decisions have fully shifted from humans to systems that no one is really watching.

New problems require new thinking

The enterprise AI nightmare is not a killer robot; it’s the erosion of our ability to see and control what’s running in our own environments at the exact moment our velocity is exploding. The danger is in ceding your agency. It’s in shipping applications that internal and external customers love—and don’t want to give up—but inherently aren’t safe. Right now, someone in your organization is using AI to build a capable app, pulling in who knows what from who knows where and adding it to your infrastructure.

The good news is that these problems are identifiable. They are also solvable, although it will take a new form of thinking than what solved problems in the past. You must think statistically, and declare constitutions with first principles. You can standardize trusted stacks and registries. You can retrain people around architectural security rather than just “secure coding.” You can start treating agent harnesses as systems that deserve design reviews and edits.

But, none of that can happen until the enterprise is willing to admit that the nightmare is already here.

Cato Networks has expanded the AI capabilities of its cloud-based secure access service edge (SASE) platform with Agentic Threat Prevention. This new service uses AI agents to predict how attackers are likely to move through an enterprise environment and automatically deploy protections before an attack can progress.

The capability combines network and security telemetry from across the Cato platform to build customer-specific attack models, correlate unrelated events, and enforce preventive controls globally through the company’s SASE platform.

Unlike traditional attack path analysis and exposure management tools that focus on identifying vulnerabilities or prioritizing risk, Cato said Agentic Threat Prevention goes beyond analysis by anticipating likely attack progression and automatically adapting protections.

“Cato Agentic Threat Prevention starts from the premise that preventing AI-assisted attacks requires more than isolated alerts,” said Brian Anderson, global field CTO at Cato Networks, in an interview with Network World. “It uses Cato’s unified network and security context to build an understanding of each customer environment, including users and identities, devices, applications, assets, traffic patterns, security events, vulnerabilities, data activity, and threat intelligence.”

The platform correlates those data points to identify activity that might appear harmless on its own but could signal the early stages of a larger attack, according to Anderson. For example, downloading an administrative tool may not be suspicious in isolation, but when combined with factors such as the user’s role, the time of day, the download source, and other environmental exposures, the platform can predict likely next steps, including tool execution or lateral movement, and automatically apply preventive controls.

Cato SASE Cloud Platform runs on a private global backbone of more than 85 points of presence (PoP) connected via multiple SLA-backed network providers. The PoPs software continuously monitors the providers for latency, packet loss, and jitter to determine in real-time the best route for every packet. Cato applies optimization and acceleration to all traffic going through the backbone to enhance application performance and the user experience. To ensure all locations benefit, Cato optimizes traffic from all the edges and toward all destinations, on-premises and in the cloud.

According to Anderson, Agentic Threat Prevention is designed primarily to stop sophisticated, multi-stage attacks where context and prediction matter, including AI-assisted exploitation, lateral movement, identity-driven attack paths, and ransomware precursors. It is not intended to replace Cato’s existing inline protections for short-lived malware or rapid “smash-and-grab” attacks, which are handled by the company’s IPS, anti-malware, DNS protection, firewall, and Dynamic Prevention engines.

“AI-assisted attacks are exposing the limits of static security controls and manual response. An entire attack can require less time than is required to investigate an alert,” said Frank Dickson, group vice president at IDC, in a statement. “As attackers adapt faster and tailor campaigns to each environment, enterprises will need prevention approaches that use shared context, automation, and cloud-scale enforcement to reduce exposure before compromise occurs.”

This capability is designed to address AI-assisted attacks that can move faster than traditional detection and response processes. According to Anderson, what differentiates the technology is its ability to reason rather than simply execute predefined workflows.

“What makes the approach agentic is the ability to reason across multiple signals, anticipate likely next steps, and adapt protections automatically within the platform, rather than simply triggering a prebuilt workflow after a known condition based on known attack patterns,” Anderson said.

Depending on the predicted attack path, the platform can block access to suspicious tools, prevent additional tool downloads, apply threat prevention controls, or tighten access policies based on the customer’s specific environment rather than generic security rules. The system also periodically reevaluates automated restrictions and removes them if behavior returns to normal to help reduce false positives, according to Cato.

Cato also shared early production and testing metrics to support the technology’s effectiveness. According to the company, the engine processes an average of 4.5 million traffic signals per customer account each week, generating more than 345,000 condition matches and enforcing more than 71,000 targeted restrictions without analyst intervention. Cato also said its internal agentic red team lab has run more than 500 autonomous attack simulations since mid-May, during which the platform consistently blocked attackers before they reached their objectives by applying an average of 15 targeted controls per affected host and mitigating 12 distinct threat vectors per attack.

Agentic Threat Prevention complements Cato’s recently introduced Agentic CVE Mitigation capability, which automatically assesses newly disclosed vulnerabilities and applies protections in as little as 45 minutes. The two capabilities are intended to reduce both the vulnerability exposure window and the time attackers have to move laterally through an environment. Anderson said the new capability reflects a broader evolution in enterprise security from reactive detection to predictive defense.

“The meaningful shift is from reactive detection to predictive prevention,” Anderson said. “In our current AI era, prediction is the new prevention. Defenders need systems that can anticipate attacker movement and act at machine speed to keep pace with AI-assisted attacks.”

Cato’s Agentic Threat Prevention is generally available now.

There is a lot of talk about the coming enterprise AI reality, in which AI finally arrives in production systems. You might not know it, but this reality—or nightmare, depending on how you handle it—is already happening.

It all starts with a “pilot,” a “prototype,” or a “side project.” Maybe someone builds an internal dashboard with an agent. The dashboard quickly becomes indispensable, and all of a sudden the experiment becomes production. Along the way, no one thought to ask the boring, inconvenient questions: What exactly was pulled from npm, PyPI, or Docker Hub? How is (or was) authentication configured? Is anyone watching for supply chain attacks against the tools and libraries the agents chose?

And it’s not just a one-off project here or a couple of applications there. AI is enabling organizations to generate more code and ship more products and projects, more quickly, than ever before. By the time security teams get a look, the business is hooked and there’s no turning back. An actual nightmare has begun.

There are three major problems that make the nightmare real.

Components you never explicitly chose

When you ask an AI agent to build an app, it doesn’t just spit out a single script. It quietly assembles an entire ecosystem around whatever problem you’ve described to it. It pulls in a web framework, grabs a bunch of libraries, stands up databases, and then it potentially builds everything on dependencies in container images.

From a productivity perspective, this is awesome. However, from a security standpoint, it’s worrisome, to say the least. When I’ve built apps like this myself, I couldn’t begin to tell you all of the components that were being used unless I went back and asked the agent to explain itself.

We live in a world where anyone can publish to npm or PyPI, and we’ve seen attackers slip malicious packages into those ecosystems or compromise ones that are widely used. Some of the recent incidents have involved security and devops tools themselves pulling a compromised dependency, running it as part of CI/CD with elevated privileges, and quietly exfiltrating secrets or tampering with builds. I personally experienced this type of compromise a couple of months ago, and had to update all of my credentials in GitHub.

Pulling unvetted code is bad; now layer AI agents on top of that. They default to whatever is easiest to discover and integrate. If a package solves a problem in front of the agent, the agent will add it. This is the old “download a random library from the Internet” problem, but now it’s on autopilot, at scale, and moving at a pace we’ve never seen before.

To solve this problem, we must provide the agents with an innate sense of our risk tolerance, an approved components list, our desires around logging, etc. We can do this with spec files and what the industry calls constitutions. Collectively, this is called harness engineering, which we will talk more about later.

Skills shifting from code to architecture

There has been a lot of hand-wringing about whether junior developers will ever really learn to code if AI is doing all of their coding for them.

That’s not what worries me.

I think it’s fine to let an agent spit out code. It’s a job they are really good at. What they are not really good at is identifying and avoiding problems in code.

I haven’t written code in quite some time. I can, but it doesn’t make sense for me to do so. What is worth my while is noticing when an agent suggests something dumb or even dangerous (or both).

For example, while working on a recent personal project, an agent proposed exposing a memory server on the public Internet with no authentication. The agent wired things up so smoothly that, at first glance, everything looked fine and just worked. But then I paused and asked, “Wait, how is this actually authenticating? Where’s the password, secret token, or OAuth in this flow?” Turns out it wasn’t authenticating and there was no password. If I hadn’t taken that beat—and then argued with the agent for a while—the app would have gone live with no protection.

So, the skills issue isn’t about whether we will lose the ability to code but rather whether we have the ability to ask questions and be discerning, and whether we have the understanding to know when something doesn’t look or even feel right. Do organizations have people who know what a dangerous software pattern looks like when the agent suggests it? You need people who can recognize when an authentication flow is too permissive, when a data store should never be exposed beyond a certain boundary, and when an architecture has become such a steaming pile of technical debt that the right answer is to throw away a whole layer and rebuild it.

You need people who know that “what works” isn’t the same as “what’s safe” or “what’s right” and who can argue back with the agent when the former doesn’t line up with the latter.

It’s not about syntax. It’s about architecture, supply chain awareness, and the willingness to say, “We’re tearing this down and doing it right,” even when the prototype looks good on the surface. Teach your AI-assisted coders basic security principles, basic architectural patterns. The AI will teach them the more advanced stuff, as long as they keep asking questions.

Agents with no harness

The third problem is that we’ve unleashed some very capable agents into our development workflows without treating them like first-class actors that need governance.

Many organizations are wiring AI assistants into a repo or IDE and letting them scaffold projects and pipelines. Maybe they bolt on a security scanner and declare “AI enablement.” That’s not a governance model, that’s optimism (and not even cautious optimism).

Indeed, a code-generating agent with broad access to your repos, your CI/CD pipeline, and your artifact registries is effectively a hyper-productive and not-very-well-trained junior developer with access to the Internet and no ingrained sense of organizational policies. It can introduce new tools, new dependencies, and new patterns faster than your review processes can handle.

In my personal projects, I’ve started to think of this as what AI coders call a harness-engineering problem. For every agent that’s responsible for building or wiring code, I try to put other agents in the loop that are responsible for tearing it down, at least conceptually. For example, one agent focuses on security and looks for obvious vulnerabilities and bad practices. Another looks at architecture and points out when the app design is veering into unmaintainable territory. A third looks at performance and reliability issues, which are themselves a kind of security concern when you think about things like denial of service and resource exhaustion. Pair this with constitutions that give the agents first principles on architecture, security, and design, and this is no longer vibe coding, it’s harness engineering at scale for all of your projects.

What I am doing isn’t perfect; there is no perfect in this space, because these are non-deterministic, statistical tools. But, many organizations aren’t even doing this. In effect, their agents are freelancing. They’re vibe coding. They’re not constrained to trusted registries or hardened base images. They’re not required to log their decisions in a way that security can audit. No one owns the harness, and that means a lot of implementation decisions have fully shifted from humans to systems that no one is really watching.

New problems require new thinking

The enterprise AI nightmare is not a killer robot; it’s the erosion of our ability to see and control what’s running in our own environments at the exact moment our velocity is exploding. The danger is in ceding your agency. It’s in shipping applications that internal and external customers love—and don’t want to give up—but inherently aren’t safe. Right now, someone in your organization is using AI to build a capable app, pulling in who knows what from who knows where and adding it to your infrastructure.

The good news is that these problems are identifiable. They are also solvable, although it will take a new form of thinking than what solved problems in the past. You must think statistically, and declare constitutions with first principles. You can standardize trusted stacks and registries. You can retrain people around architectural security rather than just “secure coding.” You can start treating agent harnesses as systems that deserve design reviews and edits.

But, none of that can happen until the enterprise is willing to admit that the nightmare is already here.