devopsy.kinsta.cloud

Tag: ai

HackerOne Extends Platform Reach to Remediate Source Code Vulnerabilities

HackerOne has added a remediation capability to its H1 Platform that reduces the amount of time required to remediate validated vulnerabilities and other weaknesses affecting specific lines of source code.

Nidhi Aggarwal, chief product officer for HackerOne, said H1 Remediation combines artificial intelligence (AI) and crowdsourced research to identify the root cause of issues that are traced back to specific lines of code. Designed to integrate with existing issue tracking tools and AI coding agents via a Model Context Protocol (MCP) server, the goal is to better prioritize remediation efforts in a way that reduces the amount of exposure debt that continues to increase as advanced AI models discover many more vulnerabilities in code, said Aggarwal.

Reports generated, in addition to root cause analysis, also detail exactly where a risky input enters the code and the resulting damage caused, language-specific code change suggestions, business context, and implementation guidance. Additional context is provided via integrations with DevOps tools and platforms such as Jira, Linear, and Confluence to provide incident histories and asset information.

The H1 platform also provides access to a dashboard for tracking resolution rate, mean time to remediate by severity, findings flow, and exposure backlog trends such as peer benchmarking and year-over-year comparisons.

Historically, application development teams have allocated a significant amount of time validating any vulnerabilities reported by cybersecurity teams. That often led to a lot of frustration and wasted effort when application developers discovered the code in question was either not externally accessible or was never loaded into memory. AI tools have now made it much easier to discover vulnerabilities but along with that advance has come a sharp rise in the number of false positives discovered in code, noted Aggarwal.

H1 Remediation addresses that issue by surfacing video examples of how a specific line of source code can be exploited, with plans to also provide examples of how source code can be exploited running in a Docker container that application developers can run and observe, said Aggarwal.

Armed with those insights, it then becomes simpler to either fix that code or develop a kill chain that mitigates the threat using the company’s continuous threat exposure management (CTEM) platform, she added.

It’s not clear at what rate cybercriminals are now moving to exploit vulnerabilities in production environments but it has been confirmed that with help from AI they are able to create an exploit in less than a day. In many instances, the exploit is now being created faster than the patch needed to fix the vulnerability. In effect, DevSecOps teams are now locked in a race against time that requires them to be much more proactive about discovering and remediating vulnerabilities versus waiting for them to be discovered by their cybersecurity teams, said Aggarwal.

Regardless of approach, the way application security is achieved and maintained has fundamentally changed. The only thing that remains to be seen now is how long it will be before organizations that fail to adapt to that new reality start to experience a wave of cyberattacks that will, more than likely, become increasingly lethal with each passing day.

August 7, 2026
Why Reliability Guardrails Are Needed in Every AI Coding Pipeline
We’re in the middle of a reliability reckoning. Thanks to AI, companies are shipping code much faster than before. But if there’s anything to learn from the surge in high-profile outages over the last couple of years, it’s that with more code comes more reliability risks. And when those risks do lead to an outage, the impact can be a whole different order of magnitude.

It’s like driving around a race track. At low speeds, it’s quick and easy to recover from a spinout. But when you’re going significantly faster, a single slip-up can spell catastrophe.

The nature of these risks is also changing. With AI code, we’re less likely to find typos but more likely to find unplanned dependencies, configuration drift, or infrastructure changes due to AI agents not having the proper context.

Any company that cares about its reliability needs to implement AI reliability guardrails: automated feedback loops that safely create real failure conditions to validate resilience, propose solutions for any issues found, and then verify the fixes once they’re implemented.

While operating independently of your AI agents, they provide an automatic governance mechanism that keeps your code within policy and prevents outage-causing risks from being introduced.

When done right, these guardrails will add reliability without slowing us down. And that’s just the first step. The reliability metrics from those tests provide valuable context to improve code quality in the future and help AI SREs track down root causes faster.

Reliability Guardrails Need to Be Based on Actual Performance

One of the earliest concepts of chaos engineering was that you can’t test every possible failure combination with unit and integration tests. Running realistic failure modes against real services tests many things at once, making it much more efficient.

This concept still holds true with reliability guardrails for AI code. Code analysis will only get us so far. If we want to see how the code will actually perform in production, we need to see how it responds to failures. And because we don’t have the time for manual chaos engineering experiments, we need to set up automated tests based on known failure modes.

Our goal with these guardrails is to validate resilience and ensure the code complies with resilience policies. Ideally, the code will respond correctly, for example, by falling back to the primary database when the cache is unavailable. If that happens, then we’ve verified resilience and the code can ship.

But what about when the test fails? To keep things moving quickly, the reliability guardrails should include proposals to address any issues that come up, such as suggesting an adjustment to the database timeout.

Once the fix is implemented, then the test can run again, verify the fix worked, and promote the code.

The goal is to embrace automation and AI integration to maintain reliability without slowing down. When set up correctly, these guardrails can keep everything on the road while still going fast.

Cover the Most Common Failure Modes First

Many outages are caused by issues with the same five things: CPU, memory, disk, I/O, and network. After all, software runs on computers, and computers have the same set of resources. Every architect knows this, and we all try to design systems that are resilient to failures like scaling, increased latency, or unavailable resources. But we also know that things don’t always go to plan.

So instead of waiting to see what happens in production, we need to create those failure conditions in a safe, automated way with tests that cover these key areas:
- Zone or host redundancy: What happens if entire zones or regions go down? What happens when a host or container is unavailable?
- CPU scalability: Is scaling set up correctly for CPU surges? Can it scale back down after the surge is done?
- Memory scalability: Same thing with memory. Can it scale? Will it gracefully degrade the way it’s supposed to?
- Dependency failure: Modern applications are a massive web of third-party and internal dependencies. What happens when your application can’t reach them?
- Dependency latency: Even if they can be reached, what happens when there’s too much latency? Will your application gracefully degrade, resort to a backup database, or just fall over?
The thing is, we should already know the answer to these questions, and we usually have policies in place that govern this kind of behavior. All we’re doing with these guardrails is making sure the candidate being proposed meets those policies and standards.

Use the Reliability Guardrails for AI Context

So we put these guardrails at the end of the CI/CD pipeline, right before promotion. If any test fails, the code gets flagged along with the test information, any recommended fixes, and is sent back to the agent. That alone will help improve reliability.

But those test results, fixes, and resolutions also provide valuable context to strengthen our agentic workflows. Every time a test is failed, a fix is applied and the test is passed, that data should be returned to the AI agents. We’ll still want to test every single time, but this context should mean that new code will pass more tests than it fails.

That same data can also be used to give context to AI SREs. Because while reliability guardrails will make outages less frequent, they will still happen. But if we feed the results into the AI SREs, there will be a contextual record of which failure modes have been tested, the test results, and the fixes implemented, allowing AI SREs to narrow the scope so the severity, duration, and customer impact can be reduced.

Which is, after all, the whole point: to make sure that your applications can be there when your customers need them. And with the right reliability guardrails, they can.
August 6, 2026
Meta Launches AI Coding Agent to Challenge OpenAI and Anthropic

In an effort to catch up with OpenAI and Anthropic in one of AI’s fastest-growing markets, Meta has launched its first AI coding agent, Muse Code, alongside an updated coding-focused AI model.

CEO Mark Zuckerberg announced the preview release of Muse Code, describing it as a tool that can handle software engineering tasks from planning code changes to writing software and validating the results. The release also includes Muse Spark 1.2, an updated version of Meta’s foundation model that has been optimized for coding workloads.

The products come from Meta Superintelligence Labs, the AI division led by Chief AI Officer Alexandr Wang. Wang joined Meta as part of Zuckerberg’s effort to jumpstart the company’s AI development after its earlier models struggled to match rivals in several key benchmarks, particularly software development.

Coding assistants are a highly competitive segment of generative AI. Products from OpenAI and Anthropic have demonstrated that AI can automate much of the software development process, allowing developers to generate code and test applications with far less manual work. Meta is now attempting to establish its own position in that market.

According to Wang, Muse Code can be installed with a single command and supports complete software engineering workflows rather than simply generating snippets of code.

The system is built around a coding harness that manages AI models designed specifically for software development projects. Developers can use the service through Meta’s existing developer platform, where the company’s Muse Spark APIs are already available.

Competing on Price

Wang said pricing, rather than outright model capability, is one way Meta hopes to differentiate itself from established competitors. Muse Code will be available through a pay-as-you-go model that follows the pricing introduced with Muse Spark 1.1, which charges $1.25 per million input tokens and $4.25 per million output tokens.

A lower-priced contributor tier allows developers to use the service at far less cost if they agree to share data that helps improve the underlying models.

The company is also beginning to offer zero-data-retention options for enterprise customers that do not want development data stored to train future models.

Muse Spark 1.2 was developed alongside Muse Code to improve coding performance. Although Meta does not position the model as the industry’s most advanced frontier AI system, the company compares its performance with leading models from Anthropic, OpenAI, Google and xAI.

The launch is part of an effort to revamp Meta’s AI business. After its Llama models failed to gain the momentum the company expected among developers, Zuckerberg embarked on an aggressive hiring campaign and reorganized the company’s AI operations under Meta Superintelligence Labs. Since then, the company has introduced multiple members of the Muse model family, including Muse Image, while also previewing its Muse Video model.

Beyond the Muse Code launch, Meta’s AI strategy comes with a substantial price tag. During its latest earnings report, Meta increased the lower end of its projected capital expenditures to between $134 billion and $145 billion, reflecting the cost of building AI models and constructing the data centers needed to support them. The spending has weighed on investor sentiment even as the company continues to prioritize AI as a long-term growth strategy.

August 6, 2026
AWS Extends DevSecOps Reach to AI Coding Tools from Anthropic and OpenAI

Amazon Web Services (AWS) this week at the Black Hat USA conference revealed it is working with both Anthropic and OpenAI to integrate their respective coding tools with a service it has developed that makes available artificial intelligence (AI) agents to help application developers write more secure code.

Launched earlier this year, the AWS Continuum service provides access to AI agents that discover, validate and prioritize vulnerabilities and surface remediation recommendations. Currently available in preview, the integrations connect AWS Continuum with coding tools from Anthropic and OpenAI to create a tighter feedback loop for developers as they write code.

At the same time, AWS has also expanded the reach of AWS Security Hub Extended, a unified cloud security and posture management service, to include data shared by Chainguard, a provider of curated open source libraries and container images, and Socket, a provider of a platform that flags malicious software packages, to better detect and block malicious dependencies before they are incorporated into an application. The findings generated by AWS Security Hub are shared via an Open Cybersecurity Schema Framework (OCSF) that is being advanced under the auspices of the Linux Foundation.

Finally, AWS is also working with Miggo Security, a provider of an AI runtime security and application detection and response (ADR) platform, to integrate rule sets directly within the Amazon Web Services (AWS) Web Application Firewall (WAF) console.

Gee Rittenhouse, vice president for agentic security at AWS, said, in general, AWS is working toward securing agentic workflows both as code is developed and after AI applications and agents are deployed. The challenge is that the AI agents that drive these workflows tend to change personas and roles at various stages of those workflows, he added. Applying the right controls at the right time requires a significant amount of visibility and context to ensure, for example, any patch that might be created is trusted enough to safely deploy, noted Rittenhouse.

In the meantime, however, the rate at which AI coding tools and agents are being adopted continues to increase. A global survey of 839 IT decision-makers conducted by the Futurum Group finds 54% now work for organizations that use AI across more than half of their software development lifecycle (SDLC), with 40% reporting AI already generates the majority of production code merged in the last 90 days. Within the next three years, a total of 58% expect AI to build 80% or more of their software, the survey finds.

However, three-quarters of survey respondents (75%) have also encountered a production issue that they have confirmed is attributable to AI, with 42% experiencing multiple incidents. That suggests there is still significant work to be done when it comes to applying governance to agentic AI engineering.

Regardless of how each DevOps team goes about achieving that goal, the one thing that is clear is that, rather than being in the middle of those workflows, software engineers will instead become orchestrators of agentic AI workflows that will soon span every aspect of the software development lifecycle (SDLC).

August 6, 2026
AWS Adds Agentic Workspace to Kiro AI Coding Tool

Amazon Web Services (AWS) this week added an open source workspace for its Kiro artificial intelligence (AI) coding tool that enables application developers to asynchronously assign tasks to an AI agent that is capable of autonomously performing tasks, such as testing code as it is created, in a way that maintains context across multiple sessions.

Darko Mesaros, a distinguished developer advocate at AWS, said the Kiro Crew workspace is also capable of creating reusable AI skills by observing the tasks developers assign to Kiro as they write code.

Kiro Crew orchestrates agents using the Agent Client Protocol (ACP) to ensure every step is observable in real time as sub-agents are spawned. For example, developers can also hand off a ticket queue to Kiro Crew for it to triage issues and flag what needs their attention or ask it to investigate the root cause of an incident while a developer continues to work on another task. An Activity view shows each agent’s reasoning, every tool call, and the results as they happen, with one card per agent on the dashboard.

The overall goal is to remove more of the toil that takes time away from ensuring that the underlying architecture of the application being created is optimized for a specific use case, said Mesaros.

In many ways, Kiro Crew provides many of the same capabilities as a general-purpose AI agent such as OpenClaw that has been designed for application developers, said Mesaros. Unlike a general-purpose AI agent, however, Kiro Crew provides an operating system-level sandbox, denied-by-default commands, suspicious-pattern blocking, input validation, sensitive-path blocking, credential redaction, and a signed audit log of every action. Any time, for example, an external AI agent seeks to install a tool it will be denied access, noted Mesaros.

In general, most of the AI skills that developers create today will increasingly become capabilities that are embedded within the next generation of large language models (LLMs). However, there will always be a unique set of AI skills that individual developers will require to build applications for a particular IT environment. Rather than having to build those AI skills themselves, Kiro Crew monitors how code is being developed and then makes a recommendation to add an AI skill that will automatically generate on behalf of the application developer.

Kiro Crew is designed to be an extension of the command line interface (CLI) that AWS developed for Kiro. More than 500 internal AWS developers contributed to a project that is now used by thousands of AWS developers, said Mesaros. Next up, AWS plans to make an edition of Kiro available on Windows platforms, he added.

At this juncture, just about every developer is, to one degree or another, making use of AI coding tools. The challenge now is taking those efforts to the next level by embracing more advanced agentic engineering tools to not just write code faster but also regain the simple joy that comes from building an application that solves a problem for the business.

August 5, 2026
RapidFort Extends Open Source Software Security Reach to Runtime Environments

RapidFort today at the Black Hat USA conference announced it has extended its ability to secure open source software to the runtimes that DevOps teams deploy in production environments.

Michael Wood, chief marketing officer for RapidFort, said the RapidFort Runtime platform makes it possible to now monitor open source software deployed within a container image to detect unauthorized or unexpected changes, and proactively assess the impact any report of a newly discovered Common Vulnerabilities and Exposures (CVE) might have.

The overall goal is to make it simpler for DevOps teams to run the curated open source software packages that RapidFort already provides in their production environments, adds Wood.

At the core of RapidFort Runtime is a Runtime Bill of Materials (RBOM) capability that integrates with pipelines in continuous integration/continuous delivery (CI/CD) platforms and uses application programming interfaces (APIs) and instrumentation to map system calls, network and memory usage, and process execution.

The RapidFort Runtime platform is then able in a read-only mode to continuously monitor those environments in a way that both tracks changes and surfaces actionable mitigation recommendations as production environments are updated, said Wood.

Additionally, RapidFort can be used to discover any unused files within an application that only serve to increase the overall size of the attack surface that might be exploited, he added.

RapidFort has also integrated code scanning tools from ReversingLabs to identify vulnerabilities in binaries before and after software is deployed in a production environment. RapidFort is also one of the founding members of an Akrites initiative launched by the Linux Foundation that seeks to disclose and remediate vulnerabilities in critical open source software via a shared Security Incident Response Team (SIRT) and a Coordinated Vulnerability Disclosure (CVD) process.

In general, RapidFort is making a case for deploying a curated set of open source software packages that have been patched to remove known vulnerabilities in a way that also seamlessly integrates with most existing package managers, said Wood. That approach enables DevSecOps teams to rapidly update applications that include open source software components at a time when artificial intelligence (AI) models are now discovering thousands of vulnerabilities in legacy software. The issue is that most DevOps teams lack the resources required to apply patches to all their legacy applications before many of those vulnerabilities are exploited.

More challenging still, any vulnerability discovered in an open source component requires the maintainers of that project to issue an update. RapidFort removes the overhead associated with managing the process by providing curated instances of those components that it continues to maintain as updates are made.

It’s not clear how quickly vulnerabilities in applications are now being exploited, but the amount of time cybercriminals need to create an exploit for a vulnerability is now measured in hours. As such, it’s now only a matter of time before a much higher percentage of vulnerabilities found in applications are exploited. In effect, DevSecOps teams, whether they like it or not, are now locked in a race against time in the AI era whenever a new vulnerability is discovered.

August 4, 2026
The Surprisingly High Cost of ‘Free’ Search Solutions
Not long ago, some business leaders seemed to view enterprise search as a “nice-to-have.” Or, at the very least, they considered it more of a supporting utility than a strategic, business-critical platform.

Organizations use enterprise search tools to help employees locate internal documents and enable support teams to surface relevant information. And, of course, retailers have long needed search to help customers navigate their product catalogs. But historically, expectations have been relatively modest: Users entered a few keywords and received a list of links, and then they did the remaining legwork themselves to figure out which results were relevant.

It’s little surprise, then, that many companies have historically relied on self-managed open-source solutions like Apache Solr for enterprise search.

But even though the role of enterprise search has changed, many organizations’ approach to search has not. The rise of GenAI has trained customers to expect companies’ search tools to understand their search intent, deliver more relevant answers, and surface useful information even when their queries are imprecise. Employees largely expect the same from internal tools. And search has become a critical layer in the generative AI tools that organizations are building to give users instant access to context-informed intelligence.

Leaders are beginning to understand the hidden costs of self-managing such a critical capability and are beginning to seek alternatives.

Growing Demands

Eliminating the cost of a software license does not eliminate the cost of delivering enterprise search. Organizations must still supply the infrastructure and engineering talent required to keep the platform available and secure.

Buyers tend to look at the topline number first when evaluating enterprise tools, and the $0 license fee associated with Apache Solr. But the total cost of a self-managed search platform also includes servers, storage, monitoring tools, and backups, among other expenses. Solr relies on a separate Apache ZooKeeper ensemble for cluster coordination, meaning teams must deploy, monitor, upgrade, and maintain an additional distributed system.

These demands only grow as search becomes more important, with customer-facing AI tools and employee knowledge assistants requiring higher availability, lower latency, and even more robust security. Despite the considerable expertise available in open-source communities, self-managed search deployments do not automatically come with guaranteed response times, vendor escalation paths, or a single point of accountability. And Solr’s relatively small maintainer base and slower release cadence can make it more difficult for organizations to keep pace with developments in real-time indexing, vector search, and cloud-native operations.

Also, every hour that internal engineers spend simply keeping search operational is an hour that they cannot devote to building new capabilities and better user experiences.

Some organizations continue to find self-managed platforms to be worth the operational overhead. But as enterprise search becomes increasingly critical to business operations, others are concluding that a fully managed solution like Amazon OpenSearch Service is both more reliable and more economical.

The Benefits of Amazon OpenSearch Service

Amazon OpenSearch Service is a managed retrieval engine built on OpenSearch for agentic AI, search, and analytics. It combines traditional lexical search with vector and hybrid retrieval, helping organizations match exact keywords while also understanding the semantic meaning behind users’ queries. OpenSearch also includes native tools for embedding generation, neural search, reranking, and retrieval-augmented generation.

Cluster Insights surfaces issues with prescriptive recommendations, and OpenSearch Serverless eliminates capacity planning with automatic scaling that adapts to demand without downtime.

All of this is to say that Amazon OpenSearch Service lets your team offload infrastructure management, allowing your engineers to focus on building.

OpenSearch itself is an open-source, community-driven project at the Linux Foundation, with more than 2 billion downloads and contributions from thousands of contributors across hundreds of organizations. This means that you can benefit from neutral governance and long-term sustainability, while also taking advantage of the scalability, availability, and operational simplicity made possible by partnering with Amazon for delivery and management.

Real-world case studies show dramatic results for companies that make a switch. For example, the social media analytics firm Audiense saw a 1,400% reduction in query time after migrating workloads from Apache Solr to Amazon OpenSearch Service. The company’s engineers now spend around half an hour per quarter on maintenance, compared to frequent manual maintenance beforehand.

BigData Boutique worked with Yotpo, an ecommerce retention marketing company, to migrate to Amazon OpenSearch Service from its existing self-managed search solution, after errors from manual configurations led to multiple problems. As a result of the move, the company lowered cluster costs by 11% and cut around three weeks of annual maintenance work.

As with any major migration, there will be challenges. Organizations often lean on a partner like BigData Boutique to help them navigate API and feature differences, query language translation, configuration migration, custom plugins, change management, and other hurdles.

Making the Move

To learn more, watch the on-demand webinar hosted by Techstrong, all about migrating Apache Solr workloads to Amazon OpenSearch Service.

We cover:
- Why organizations are modernizing their search platforms.
- The key differences between Apache Solr and Amazon OpenSearch Service, including performance, scalability, and AI/ML capabilities.
- How to solve common challenges and streamline your migration journey.
Watch if your organization is looking to improve search performance, reduce management burdens for internal teams, or simply prepare your environment for the future of AI. If you already know you’re looking to make a change, click here to schedule a meeting about migrating from Apache Solr to OpenSearch.
July 29, 2026
OpenAI Open Sources Codex Security CLI for the Merge Path

OpenAI has released its Codex Security command-line interface and software development kit as open source software under the Apache 2.0 license, providing a new way to bring its AI security scanner into development workflows.

The CLI can scan repositories, review staged and unstaged changes before a commit, compare findings across scans and export results for use in other code-scanning tools. Teams can also run it in CI and set a severity threshold that returns a failing status when a completed scan identifies a finding at or above that level. OpenAI recommends starting with advisory results before allowing findings to affect the CI check.

Because the client code is public, teams can inspect and adapt the CLI or SDK to fit their own tooling. But that openness stops at the integration layer, as the service that performs the underlying analysis remains under OpenAI’s control.

“OpenAI open-sourced the client and kept the scanner. That is distribution, not openness,” said Mitch Ashley, VP and practice lead for DevOps and application development with the Futurum Group. “The Apache-2.0 CLI lands in CI configs and pre-commit hooks while the beta-gated backend holds the model, triage logic, and the billing relationship.”

In practice, teams cannot use the published client code alone to operate a standalone scanner. The CLI and SDK remain in limited beta and are available only to approved customers and partners, according to OpenAI. Local users sign in with a ChatGPT account, while CI and other automated workflows use an OpenAI API key. Full repository scans may also require Trusted Access for Cyber. Developers can therefore inspect and modify the integration software, but the system that generates and evaluates findings still depends on OpenAI’s hosted service.

Security scanning in CI is already common, and established application security platforms are increasingly adding AI features to help assess findings, generate fixes and check whether those fixes work. Codex Security combines those activities in a more integrated agent workflow. According to OpenAI, the agent creates a threat model for the repository, examines possible attack paths, attempts to reproduce suspected vulnerabilities in an isolated environment and proposes patches for human review. It can then check whether a vulnerability remains after a fix is merged.

“Every team already runs a scanner in CI,” Ashley said. “The advance is an agent that confirms the finding, writes the patch, and verifies it across runs.”

Giving the agent responsibility for validating potential vulnerabilities and proposed fixes raises the standard it must meet before teams allow its output to block code changes. OpenAI says AI scans can produce different results even when the configuration remains unchanged, and that a previously reported issue disappearing from a later scan does not prove the vulnerability was fixed.

Ashley said Codex Security should earn a role as a merge gate only after OpenAI demonstrates that repeated scans of the same code produce sufficiently consistent findings. For DevOps teams, the unresolved question is whether those results can become dependable enough to decide whether a code change should be allowed to merge.

July 29, 2026
AI Code Generation Raises New Quality Risks

AI coding tools are producing more code, faster, than teams have ever had to absorb before. That productivity story is real, but it comes with a bill that most engineering leaders have not fully paid yet. Technical debt piles up faster. Repetition slips in. Security gaps and quality issues show up in places where nobody was watching, because nobody wrote the code that put them there. Speed alone is not the win it appears to be if the review layer never scales to match.

Mike Vizard sits down with Mladen Lazic, CTO of Scopic, to work through what it actually takes to keep AI-assisted development from turning into a debt engine. Lazic’s core point is that reviewing AI-generated code is genuinely harder when engineers were not part of how it was created — context is missing, intent is unclear, and the usual mental shortcuts a reviewer relies on stop working. His answer is to keep developers in the loop from the start and treat AI tools as junior developers who need direction, not autonomous builders who ship features alone.

They get into the mechanics of independent validation. Lazic warns against a common failure pattern where the same AI agent writes the code, generates the tests and reviews the output — effectively grading its own work. Scopic is moving toward separate agents for coding, pull request review and test creation, with some testing agents deliberately blind to the source code so they validate against requirements rather than against whatever the coding agent happened to produce. That separation is what turns AI QA into a real check instead of a rubber stamp.

Looking further out, Lazic expects the engineer’s job to shift toward instruction, monitoring, verification and improvement rather than raw production. That reframes AI code quality as a durable concern for DevOps, security and application leaders — not a phase to get through. The teams that build better gates, sharper observability and independent QA now will be the ones shipping better software sooner, without eating the debt everyone else is quietly accumulating.

July 29, 2026
Why Agentic Coding Needs Governance at Scale

Most enterprises never fully finished the DevOps transformation they started a decade ago. Agentic coding is now surfacing every place that was left unfinished. Builds still take hours. Test suites are flaky. Releases are still gated by manual steps. An AI coding agent that has to sit idle for eight hours waiting on feedback is not just slow — it is an extremely expensive kind of slow, burning tokens and calendar time on the same pipeline gaps DevOps was supposed to close years ago.

Moritz Plassnig, the newly returned CEO of CloudBees, joins Alan Shimel to explain what he saw during five years away at Immuta and why he came back. Watching large language models reshape how customers worked with data reignited his interest in the delivery side of the problem, and he argues agentic coding is DevOps’s second chance to actually deliver on the original promise. The gap is no longer that teams disagree that DevOps is real — it is that most companies never went all the way, and the shortcuts they took are now the ceiling on how fast agents can work.

Plassnig’s recipe is direct. Take the rules an organization already lives by — two-human review on any code change, whatever the specific policies are — and encode them as versioned policy that a central governance engine can enforce across CloudBees, Jenkins, GitHub, GitLab or whatever coding tool a team picks. He shares a striking data point from a very large bank: technology planning horizons have compressed from five to ten years down to two to three, which means standardization is losing to a curated menu of approved tools that a governance layer holds together.

If code generation is no longer the constraint, the next bottleneck is getting software into production safely — and Plassnig is blunt that AI-scale development needs AI-scale governance or the mismatch becomes catastrophic. Supply chain risk compounds with every automated step, and the organizations that pretend policy can stay manual are the ones that will discover the hard way that agents scale faster than any human review process ever could.

July 29, 2026