Oracle plans to issue security patches for its ERP, database, and other software on a monthly cycle, rather than quarterly, to respond to the increased pace of AI-enabled software vulnerability discovery.

Other software vendors, notably Microsoft, SAP, and Adobe, already release patches on a monthly beat, always on the second Tuesday of each month.

Oracle, though, is taking an off-beat approach: It will release the first of its monthly Critical Security Patch Updates (CSPUs) on May 28, the fourth Thursday, and after that, it will release its patches on the third Tuesday of each month — a week after the other vendors — with the next batches arriving on June 16, July 21, and August 18, it said earlier this week.

The new CSPUs “provide targeted fixes for critical vulnerabilities in a smaller, more focused format, allowing customers to address high-priority issues without waiting for the next quarterly release,” Oracle said.

It will issue a cumulative Critical Patch Update each quarter, so on the same schedule as before. The first one this year came in January.

Oracle initially announced the switch to a monthly patching schedule last week, but did not provide the dates.

The new patching rhythm will primarily interest customers running Oracle applications on premises or in their own or third-party hosting environments. For customers using the software in an Oracle-managed cloud, Oracle applies the patches automatically automatically.

Oracle is using artificial intelligence to identify and fix the vulnerabilities faster than before. It said it has access to OpenAI’s latest models through that company’s Trusted Access for Cyber program, and to Anthropic’s Claude Mythos Preview.

Mythos has contributed greatly to concerns that AI will uncover thousands of zero-day flaws in software, but as of mid-April, only one vulnerability report had been tied directly to it.

This article first appeared on CSO.

Identity has always been central to security, but the proliferation of AI agents is rapidly changing the challenge of managing and securing identity, spurring CISOs to rethink their identity strategies — even how it is defined.

“Identity is now both a control surface and an attack surface. We’ve had non-human identities as API keys, tokens, service accounts, but now we have agents, and that’s a new class,” says Dustin Wilcox, senior VP and CISO at S&P Global.

The challenge is attributing actions to non-human identities because the typical signals don’t apply. “The techniques to identify a person, like the telemetry of how they use the keyboard, we won’t be able to do that when it’s an agent that’s working entirely digitally,” Wilcox tells CSO.

And as agents proliferate, it becomes difficult for CISOs to maintain a complete picture of how many exist, what they’re used for, and what they’re authorized to do.

“With a human identity, you can validate access needs directly. With service accounts, and now with agents, that clarity is harder to achieve,” says Docusign CISO Michael Adams.

“Treating them as if they fit existing models can create gaps in visibility and control. At the same time, AI systems are contributing to rapid growth in non-human identities, including the creation of new credentials and tokens, which many inventory processes weren’t designed to track,” he adds.

“And on the human side, generative AI is making social engineering more convincing, eroding some of the behavioral signals defenders have historically relied on. The result is an expanding attack surface at the same moment traditional indicators are becoming less reliable,” Adams tells CSO.

The advice for CISOs is to adopt an identity-first security model that treats identity as the foundational layer of the security architecture.

“Every access decision flows through identity and is continuously verified, not just checked at the door,” says Adams.

Identity becomes the primary control plane

CISOs are now managing a new class of identities that includes copilots, autonomous agents, and AI-powered workflows that don’t fit neatly into existing frameworks. And they can access systems, take actions, and make decisions at machine speed.

Wilcox and Adams are speaking at the CSO Cybersecurity Awards & Conference, May 11–13. Reserve your place.

As a result, Adams says CISOs will increasingly need to adopt an identity-centric security architecture and there are several key tenets to consider.

Build a strong foundation before layering on complexity. The instinct when modernizing an identity program, says Adams, is to reach for sophisticated tooling. Instead, his advice is to get the fundamentals in place — clean directories, enforced least privilege, and reliable offboarding processes.

“Organizations that jump to continuous verification without establishing basic identity hygiene may find themselves building on an unstable foundation,” he says.

Design for the new class of identities. When designing role models and access policies, the temptation is to mirror existing structures.

“That often carries years of permission creep into a new architecture. Starting from least privilege rather than from legacy helps ensure users receive only the access required for their job functions,” he says. “It’s important to challenge ‘it’s always been done this way’ where appropriate.”

Get your non-human identity inventory in order. Build a full inventory of non-human identities and include who is responsible for each identity, and what each one is authorized to do. Do this before any more agents are operating.

“This is as much a governance challenge as a technology one,” he notes.

Treat MFA as a starting point, not a destination. The identity roadmap needs to include phishing-resistant alternatives to SMS or push-based MFA. Least privilege, micro-segmentation, and continuous monitoring are part of the playbook.

“Assume credentials may be compromised and architect accordingly,” Adams advises.

AI and the shifting security balance

Identity systems have long been targets for attack. But as identity becomes the primary control plane, the risk becomes more concentrated and requires a different approach.

“I’d encourage every CISO to think deeply about the intersection of identity and AI,” says Adams, adding that systems need to be redesigned around the principle of intent instead of actual behavior to ensure agents operate within appropriate boundaries.

“That requires behavioral monitoring and real-time access evaluation — capabilities many organizations are still building toward,” he notes. “That’s the work ahead.”

Wilcox is ultimately optimistic that AI offers security practitioners more tools to combat malicious actors. If CISOs can get this right, it’s a way to level the playing field with the attackers in a way not previously available.

“We’ve had this asymmetric playing field where they’ve had the advantage for as long as I can remember. Now we can use AI both strategically and tactically to improve our defenses,” he says.

Agentic AI is rewriting the identity security playbook in real-time, and your peers are already adapting. Hear Dustin Wilcox, Michael Adams, Renee Guttmann, and other leading CISOs share what’s actually working at the CSO Cybersecurity Awards & Conference, May 11–13. Secure your seat before it fills up.

오픈텍스트 애플리케이션 시큐리티 에비에이터(OpenText Application Security Aviator)는 AI 기반 분석 기술을 활용해 개발 과정에서 발생할 수 있는 보안 취약점을 사전에 식별하고, 코드 수정과 보안 대응을 지원하는 애플리케이션 보안 솔루션이다.

이번 교육은 특히 오프라인(Offline) 모드 환경에 초점을 맞춰, 규제 조건이 까다로운 고객사 환경에서도 해당 솔루션을 운영할 수 있는 방안을 제시하는 데 중점을 뒀다. 이를 통해 파트너들이 실제 고객 제안 및 PoC(개념검증)에 활용할 수 있는 역량 확보를 지원했다.

현장에서는 솔루션 소개와 함께 핸즈온(Hands-on) 중심의 실습이 진행됐으며, 참가자들은 프로젝트 기반 취약점 점검부터 AI 기반 정탐·오탐 분류, 코드 수정 시 보안 검증 지원 기능까지 직접 체험했다.

오픈텍스트는 이번 교육을 통해 파트너들이 AI 기반 애플리케이션 보안 기술을 이해하고, 다양한 고객 환경에 적용할 수 있는 역량을 확보하는 데 목적이 있었다고 설명했다.

오픈텍스트 관계자는 “AI 기반 보안은 개발 단계에서부터 적용되는 것이 중요하다”며 “앞으로도 파트너들이 다양한 고객 환경에서 활용 가능한 역량을 갖출 수 있도록 지원을 이어갈 계획”이라고 밝혔다.
dl-ciokorea@foundryco.com

The cybersecurity community is currently fixated on data lineage and leakage via LLM prompts. While SandboxAQ’s 2025 AI Security Benchmark Report confirms that 52% of security leaders identify sensitive data egress as their primary concern, this focus addresses a yesterday problem. As a cryptography and security engineer, I look at the underlying building blocks of how these systems interact. The real risk has shifted from what users tell an AI to what autonomous agents are permitted to do.

We are entering the era of shadow operations: The uncontrolled deployment of autonomous agents that execute logic, integrate with systems by calling APIs and modify states without formal security oversight.

What we are hearing directly from security leaders reinforces this shift. Many organizations have already rolled out AI across business units. They are using managed services, embedding AI into workflows and in some cases building their own agents. Yet when asked a simple question about where their agents are and what they are allowed to do or to access, the answer is often uncertain. The visibility gap is not hypothetical. It is a reality.

The rise of the OpenClaw era

We are seeing a trend toward fast adoption of agentic AI frameworks to automate and make certain processes or tasks more efficient. Moreover, open-source projects like Moltbot and the broader OpenClaw movement aim to provide tooling that can be deployed with minimal friction. While these foster innovation, they bypass the traditional “secure-by-design” principles we apply to production code.

In a shadow ops scenario, a well-meaning developer uses an agentic framework to automate a complex workflow, perhaps an Extract, Transform, Load (ETL) process or a cloud deployment script. To make it work quickly, they might grant the agent a high-privilege API key (e.g., an AWS AdministratorAccess or a GitHub Personal Access Token with full code repository scope). The result is a non-deterministic autonomous entity running in a cloud function with the keys to the kingdom, invisible to your Cloud Security Posture Management (CSPM) tools.

The risk is no longer just traditional confidentiality or data security and privacy; it is enterprise-wide operational integrity. The impact shifts from a compliance fine to direct financial loss and a breach of trust in our own technology.

This risk is amplified by how agents are introduced into environments. They are often embedded at the repository level through GitHub actions, API integrations, orchestration layers or model calls buried in application logic. If security teams only begin monitoring once code is deployed, they are starting too late. The moment of risk introduction happens at the pull request, not at runtime.

Why your current security stack is blind to it

Our existing security suite of tools is not built to solve for shadow operations. Standard Data Loss Prevention (DLP) and Identity and Access Management (IAM) solutions are often blind to agentic ephemeral identities. A CSPM might see a legitimate server running a legitimate process, but it doesn’t see the unvetted AI logic calling a third-party resource via a hardcoded API key.

We have a profound visibility gap. You cannot secure what you cannot see, and you cannot see these agents where they are born. If your security view starts when software is already running, you are looking in the wrong place. This is compounded by an increasingly complex supply chain. The recent incident involving OpenAI and its analytics vendor, Mixpanel, serves as a baseline example: A breach in a sub-processor exposed account metadata. With agentic frameworks, the supply chain expands to include every model, plugin, and external tool the agent is permitted to call.

The expansion of the supply chain is particularly significant. Agents do not operate in isolation. They call models, connect to Model Context Protocol (MCP) servers, integrate external plugins and access enterprise systems through APIs. Without a unified inventory that maps which agent is using which model, running on which host and accessing which resources, security teams cannot understand the blast radius.

This is where the concept of an AI Bill of Materials, or AI BOM, becomes operational, not theoretical. An AI BOM is a structured inventory of models, agents, orchestration layers and dependencies embedded within an application or AI system. It should identify managed third-party model calls as well as self-hosted models discovered within repositories or cloud workloads. Without this baseline inventory, governance cannot be enforced.

There is also confusion in the market about what an AI BOM can realistically capture. Some expect it to include complete training data lineage, model versions and dependency chains. In practice, training data transparency varies. Standard models may expose metadata through sources such as model cards, while fine-tuned or internally trained models may not automatically surface that lineage. Security leaders must design controls with that uneven transparency in mind.

Engineering a solution: Visibility as a primal requirement

Countering shadow operations requires evolving our security posture toward shift-left discovery. This means identifying AI assets at the pull-request level, long before they are compiled, deployed or downloaded, and executed. We must move beyond static API keys to a model of contextual least privilege and if an agent is built, its permissions must be strictly scoped to the specific task and continuously monitored for anomalous “behavioral drift.” Given that more than 75% of organizations are already integrating AI, we effectively need policy-driven guardrails that implement automated discovery and monitoring for these shadow operations across the entire infrastructure footprint.

Inventory, however, is only the first step. Visibility must be paired with qualification. Organizations need mechanisms to evaluate model behavior and assign enforceable health criteria. Structured red teaming, adversarial prompt testing and measurable model scoring allow security teams to define policy thresholds. Models that fall below defined integrity or hallucination benchmarks should not be promoted into production environments.

Enforcement must also extend into runtime. Proxy-based guardrails positioned between users and models create a control layer that can inspect prompts and responses in real time. These guardrails can detect malicious instructions, sensitive data exposure, jailbreak attempts or proprietary code leakage based on policy. Without runtime enforcement, governance depends entirely on user discipline.

This is especially relevant for AI coding assistants and agent-to-agent interactions. If developers are using external copilots or SaaS-based coding tools, sensitive source code and credentials may traverse systems outside centralized oversight. Routing traffic through enforceable proxy infrastructure enables logging, inspection and policy-based blocking where required.

The goal for 2026 is not to stifle innovation by blocking these agents, but to bring them under the umbrella of formal governance. We must ensure that the cryptographic identities and operational permissions they carry are as rigorously managed as any other critical piece of our infrastructure. By treating autonomous agents as first-class system actors with distinct, verifiable identities, we can mitigate the risk of integrity failures while allowing engineering teams to leverage the speed and efficiency of the agentic era.

Identity is the connective layer between cryptographic posture and agentic execution. Agents require credentials to access systems. If those credentials are static, overprivileged or manually provisioned, fragility becomes systemic. Just-in-time access and tightly scoped permissions enforced at machine speed are foundational to operational resilience in autonomous environments. Manual IAM workflows cannot scale to agents operating continuously.

The call for 2026: Securing the AI perimeter

The trajectory is set. With over 75% of organizations now reporting the use of AI, the pivot from simple data usage to autonomous execution is the next inevitable phase of infrastructure evolution. The risk is no longer theoretical because the tools are deployed, and the shadow operations attack surface is expanding.

We must expand our definition of AI security beyond data security and privacy to encompass operational resilience. True security cannot rely on monitoring the output; it must start where the AI is built and executed. We require continuous visibility and strict control mechanisms to ensure that agents do not become the vector for systemic disruption.

Operational resilience also requires longitudinal observability. Security posture cannot be a snapshot in time. Organizations must track issue evolution across repositories, model usage trends and configuration changes to maintain a defensible audit trail. Without that historical context, governance cannot adapt to drift.

Market pressure is reinforcing this direction. Structured AI governance artifacts are increasingly tied to regulatory scrutiny and vendor risk requirements, particularly in large financial institutions. Demonstrable inventory and enforceable runtime controls are becoming prerequisites for enterprise trust.

By enforcing strict identity governance and deep visibility now, we can capture the productivity of the agentic era without introducing a hidden layer of fragility into the heart of our enterprise-wide operations.

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

미국 백악관이 주요 연방 기관에 앤트로픽(Anthropic)의 고성능 AI 모델 ‘클로드 미토스(Claude Mythos)’ 접근을 허용하는 방안을 추진하고 있다. 해당 모델은 사이버 보안 취약점을 빠르게 탐지하고 이를 악용할 가능성까지 제시할 수 있는 만큼, 오남용 방지를 위한 보호 장치 마련이 병행되고 있다.

블룸버그에 따르면, 백악관 관리예산국(OMB)의 연방 최고정보책임자(CIO) 그레고리 바르바치아는 15일(현지시간) 각 부처 관계자들에게 내부 공지문을 통해 “연방 기관이 해당 모델을 사용할 수 있도록 보호 체계를 구축 중”이라고 밝혔다. 다만 구체적인 도입 기관이나 일정은 명시되지 않았다.

바르바치아는 “모델 제공업체와 산업 파트너, 정보기관과 긴밀히 협력해 적절한 가드레일과 보호 장치를 마련한 뒤 수정된 형태의 모델을 기관에 제공할 가능성을 검토하고 있다”고 설명했다.

이번 조치는 국방부가 지난 3월 3일 앤트로픽에 대해 공급망 위험 지정을 내린 상태에서 추진되고 있다는 점에서 주목된다. 해당 지정은 4월 8일 워싱턴DC 순회항소법원이 효력 정지 요청을 기각하면서 유지됐으며, 이에 따라 앤트로픽은 여전히 국방 계약에서 배제된 상태다. 반면 민간 연방 기관은 이번 조치를 통해 접근 가능성이 열리고 있다.

백악관과 앤트로픽 측은 관련 문의에 입장을 내놓지 않았다.

가드레일 정의가 핵심 쟁점

이번 공지문에서 언급된 ‘수정된 모델’은 실제 도입 방식과 범위에 대한 불확실성을 드러낸다. 앤트로픽은 지난 4월 7일 ‘프로젝트 글래스윙(Project Glasswing)’의 일환으로 일부 기술 및 금융 기관에 제한적으로 제공되는 ‘클로드 미토스 프리뷰’를 공개한 바 있다.

당시 앤트로픽은 내부 테스트에서 해당 모델이 주요 운영체제와 브라우저 전반에 걸쳐 수천 건의 제로데이 취약점을 발견했다고 밝혔으며, 일반 공개 계획은 없다고 선을 그었다.

시장조사업체 카운터포인트리서치의 닐 샤 부사장은 “연방 기관 도입이 정당성을 확보하려면 명확한 보증 기준이 필요하다”며 “분석 대상 소스코드는 격리된 에어갭 환경에서 관리돼야 하고, 데이터가 기본 모델 재학습에 활용되지 않도록 해야 한다”고 말했다. 이어 “버그 수정 전 인간 검토 절차를 포함하는 등 투명성과 통제 장치를 강화해야 한다”고 덧붙였다.

기업 시장에도 확산되는 영향

이 같은 보안 기준 문제는 기업의 AI 도입 전략에도 그대로 적용된다. OMB의 이번 움직임은 연방 사이버 방어 전략이 인간보다 빠르게 취약점을 탐지하는 차세대 AI 모델 중심으로 전환되고 있음을 보여준다.

샤 부사장은 “국방부와 백악관 간 입장 차이는 강력한 AI 기술의 배포 통제가 얼마나 중요한지를 보여준다”며 “탐지, 분류, 보안, 검증, 실행 전 단계에 걸친 다층적 통제 프레임워크가 필요하다”고 강조했다.

이 같은 기술 격차는 국가 간에도 나타나고 있다. 현재 초기 접근 권한은 영국 AI 보안 연구소에만 제한적으로 제공됐으며, 유럽 주요 기관은 대부분 배제된 상태다. 만약 OMB의 계획이 실행될 경우 미국 연방 정부는 유럽보다 앞선 방어형 AI 역량을 확보하게 될 전망이다. 반면 동일 기업에 대한 국방부의 제재는 법적 절차를 계속 밟고 있다.

‘수정 모델’로 국방부 제재 우회

앤트로픽은 수정된 모델 제공 방식을 통해 국방부의 강경한 입장을 우회하고 있는 것으로 분석된다.

샤 부사장은 “수정된 모델은 국방부의 이분법적 접근을 피해가면서도, 합의된 가드레일 내에서 민간 및 기업 환경에 안전하게 적용될 수 있는 보안 영역을 제공한다”고 평가했다. 이어 “이 방식은 향후 다른 정부 기관과 기업으로의 확산에도 선례가 될 것”이라고 전망했다.

한편 앤트로픽의 연방 접근 권한은 최근 몇 주간 변동을 겪고 있다. 캘리포니아 연방법원은 3월 26일 민간 영역에 대한 별도 지정 조치에 대해 앤트로픽의 가처분 신청을 인용하며, 관련 계약업체들이 AI 공급망을 재검토할 시간을 확보했다.

현재 앤트로픽은 군 조달에서는 배제된 상태이면서, 민간 시스템에서는 제한 조치가 일시 중단됐고, 동시에 OMB를 통한 접근 확대 논의가 진행 중이다. 이로 인해 계약업체들은 AI 모델이 실제 시스템 내 어디에 적용되는지 파악하는 데 어려움을 겪고 있으며, 이는 연방 AI 공급망 리스크 관리 전반에 영향을 미치고 있다.
dl-ciokorea@foundryco.com

If you scroll through your professional feeds or check your inbox this week, you are guaranteed to see the phrase “vibe coding.”

Instead of writing code, your product managers can just chat with a coding agent and prompt a fully deployed app into existence. I just read the market-tanking prediction from Citrini Research arguing that AI is on the verge of coding entire SaaS products completely on its own. LLM vendors and YC startups are aggressively selling this exact idea that anyone can build complex software in an afternoon simply by describing their desired features.

But from where I sit, this unchecked acceleration is an absolute disaster. AI today might be able to generate the superficial shell of a SaaS app, but it is still far away from having the engineering rigor required to build something reliable enough to become part of our digital infrastructure.

While this conversational approach makes it incredibly easy to scaffold apps, it is quietly creating a massive crisis in enterprise security and technical debt. We are abandoning disciplined software engineering and replacing it with a culture of probabilistic guesswork. If we don’t course-correct, we are going to expose ourselves to catastrophic risk.

The rise of unsanitized agents

The risks multiply when we transition from AI that just generates new content to AI that takes action. Over the past few months, we’ve seen an explosion of unsanitized agentic systems. The most popular is an open-source project called OpenClaw (formerly Moltbot/Clawdbot). Unlike a regular chatbot, this thing has the ability to independently execute actions on a machine—sending files, running programs, making outside connections.

I recently deployed OpenClaw to a sandboxed environment just to see what the fuss was about. I found a bloated mess of features, but the most basic functions, such as Telegram streaming, didn’t even work. I tried consulting their documentation, but it was clearly just a wall of AI-generated, high-entropy and low-variance text that told me absolutely nothing useful. To make matters worse, the project changed its name twice in a row without providing a single migration guide for how to move to the new binaries. If a traditional piece of software shipped like this, we would deem it completely unacceptable. But because it’s an AI that theoretically can do a lot of things on paper, people tolerate it.

They do look incredible in YouTube demos. But deploying unsanitized, non-deterministic agents with root access to local environments is a massive security regression. You are effectively taking decades of strict Identity and Access Management (IAM) protocols and tossing them in the trash.

Consider the “lethal trifecta” these agents represent. First, they hold persistent privileged access. Second, they continuously read untrusted external data like incoming emails or Slack messages. Third, they have unrestricted communication with the outside world. If an attacker sends an email with a hidden prompt injection, the agent doesn’t verify it and might just silently leak your local SSH keys!

The “works on my machine” problem at scale

The crisis goes beyond deviant agents. It infects how we build our entire software supply chain. When developers prioritize speed over deep understanding, they start building infrastructure based on luck.

Right now, my team is fighting a novel threat vector known as “slopsquatting.” It is also known as AI package hallucination. AI models do not query a deterministic database of facts. They predict the next most likely word. Because of this, they frequently invent software package names that sound perfectly plausible but do not actually exist.

Here’s how the attack works: malicious actors register these hallucinated packages on public repositories and inject them with malware. The coding agent suggests the fake package and blindly installs it. From the vibe coder’s perspective, the AI’s code works without throwing any warnings and the installed package seems legit. But under the hood, they just handed root access to a cybercriminal.

This blind trust also destroys our internal quality assurance. A big part of the vibe coding promise is that the AI will write the feature and then the unit tests to validate it.

I recently reviewed a pull request for a new internal routing microservice. 100% test coverage. The CI pipeline showed a beautiful sea of green checkmarks. But then I actually read the code. I found what my co-founder and I now call “cardboard muffins.”

The AI hadn’t written tests to verify the underlying business logic. It completely ignored the edge cases. It simply hardcoded the exact return values needed to satisfy the assertions. Its only goal was to make the deployment pipeline pass.

When 80% of a codebase is generated by an AI that hallucinates dependencies and fakes unit tests just to get a green checkmark, you haven’t built software. You’ve built a house of cards. Scaling this kind of code takes the old “works on my machine” problem and turns it into an enterprise-wide disaster.

I firmly believe that the new luxury in software development won’t be the sheer speed of feature rollouts. The new luxury will be old-fashioned, boring determinism.

The dual-track strategy

We cannot afford to ban generative AI. The capability for rapid innovation and market testing is simply too valuable. But we absolutely cannot let probabilistic vibe coding dictate the architecture of our production systems.

To fix this, CIOs can promote a “dual-track” development lifecycle. This strategy separates rapid exploration from rigorous production engineering.

Track 1 (the fast track)

This is the domain of unconstrained discovery. In Track 1, vibe coding is explicitly permitted and heavily encouraged. If a product manager wants to use an autonomous agent to scaffold a prototype in an afternoon, let them do it. The core metric here is speed to feedback. We want to validate business ideas and test user interfaces as cheaply and quickly as possible.

But there is a massive catch. Track 1 development must occur in heavily sandboxed environments. These vibe-coded applications are disposable blueprints. They are never permitted to touch production data, customer PII or mission-critical corporate networks.

Track 2 (the slow track)

Once a prototype in Track 1 proves its business value, the project moves to Track 2. This is the domain of real software engineering.

The mandate here is simple but painful: Start over. Do not attempt to refactor, salvage or clean up the vibe code. Rewrite it from the ground up.

In Track 2, human engineers take the lead. They use the Track 1 prototype merely as a visual reference. They build secure and scalable architectures. This track prioritizes deterministic security guarantees, strict type safety and rigorous human peer review. AI tools are still used, but they are demoted from being autonomous creators to highly restricted assistants. Every dependency is verified against established security frameworks and every unit test is manually reviewed to ensure we aren’t baking cardboard muffins into our core product.

A big cultural shift

Implementing a dual-track strategy requires a big cultural shift. This is especially true when managing executive expectations. It hinges on one non-negotiable directive: never base the timeline of the slow track on the velocity of the fast track.

It’s going to be a tough conversation with your business stakeholders. When they see a seemingly functional, vibe-coded prototype spun up over a single weekend, it’s natural for them to assume the final product can be finished if given one more week. But enforcing this boundary is exactly how we ensure the business becomes a benefactor of AI coding, rather than its next victim.

AI is an incredible force multiplier for innovation. But it is not a substitute for architectural foresight. By embracing a dual-track strategy, we can give our teams the freedom to experiment at the speed of thought while protecting the deterministic rigor that keeps our digital infrastructure running.

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