Tag: agentic AI

GitHub Workflows Strain Under AI Agent Development

GitHub was built around human workflows. That assumption held for a long time, and it worked — repositories, pull requests, code review and CI/CD pipelines all evolved around the pace at which people ship code. AI agents break that assumption in a hurry. Commits, pull requests, issues and branch changes now arrive at machine speed, and the systems that scaled fine for teams of engineers are showing strain when a swarm of agents is generating activity around the clock.

Mike Vizard sits down with Rob Whiteley, CEO of Coder, to work through what that strain actually looks like in practice and why repositories, pipelines and developer platforms are hitting limits that were not visible a year ago. Whiteley’s argument is that the core idea of Git is still useful — distributed version control is not the problem — but the platforms wrapped around it were designed for a slower, more deliberate cadence than agentic development produces. Volume and velocity are the pressure points, and the operational side of GitHub is where they show up first.

They get into the security and supply chain angle. Malware and risky code can move through repositories quickly, and AI raises the ceiling on both attacker automation and accidental mistakes from legitimate teams. Actions, webhooks and CI/CD integrations turned code repositories into operational control points, which made development faster but also made GitHub a critical dependency for a large slice of the industry. As agents take on more coding work, teams need real boundaries around what agents can access, how they trigger workflows and how their activity is audited — the permissions and execution environments that were adequate for human contributors are not obviously adequate for the agent equivalent.

Whiteley’s read is that agentic development calls for more distributed, policy-aware and resilient systems, with stronger controls around context and execution. Rethinking developer infrastructure before scale, security and reliability turn into blockers is where the organizations getting ready for this next phase are already putting their attention.

September 9, 2026
Apica Adds AI Agents and MCP Server to Platform for Managing Telemetry Data

Apica today added an artificial intelligence (AI) agent and Model Context Protocol (MCP) server to version 3.0 of its Ascent platform for managing telemetry data pipelines.

Andi Mann, chief product and technology officer for Apica, said the AI agent, dubbed Venn, makes it possible for IT teams to use natural language rather than having to create scripts to build and manage data pipelines at higher levels of scale.

The MCP server, meanwhile, makes it possible for IT teams to use third-party AI tools to invoke the Ascent platform and its multiple embedded AI skills within the context of a DevOps workflow.

Finally, a flow-only mode capability has been added to the platform to enable telemetry data to flow 10x faster. That additional capacity will prove critical as more AI agents are added to IT environments, said Mann.

Just as importantly, however, any change that could delete or materially alter configuration requires the consent of an administrator before being applied to ensure no action is performed without approval, noted Mann.

The overall goal is to provide an intelligent foundation for managing telemetry data that, for example, makes it simpler to discover a noisy pipeline, he added.

Longer term, that intelligent foundation will be invoked via multiple communications channels, including Slack and Microsoft Teams, to further reduce the level of friction and bottlenecks that exist with DevOps workflows, said Mann.

It’s not clear at what rate DevOps teams are moving to find more efficient ways to manage telemetry data, but the volume of it is only going to increase in the AI era. In some cases, that may mean increasing the volume of data through existing pipelines, but before too long, the total number of pipelines that DevOps teams will be asked to manage will also increase. Additionally, that data is going to become more crucial than ever as DevOps teams seek to observe events that are increasingly occurring at machine speed.

In general, the Futurum Group is forecasting that total spending on DevOps tools and platforms will grow about 14% in 2027, and 72% plan to significantly increase investment (41%) or slightly increase spending (31%) over the next 12 months. The Futurum Group now projects global spending on software lifecycle engineering tools will roughly double to $226 billion by 2030, up from $111.1 billion in 2025. Spending on agent control planes and agentic development will compound at 48.7% and 45.1%, respectively, through 2030, according to the report.

Hopefully, those investments will soon lead to a day when rather than having to interrogate telemetry data, the systems that process and filter it will become intelligent enough to identify issues that they will then share with other tools and platforms capable of automatically resolving them with human supervision. The simple fact of the matter is that IT environments are already far too complex for humans to manage. The challenge and the opportunity now is to find ways to apply AI to achieve that goal while ensuring that, in the event something goes wrong, the proverbial cure doesn’t wind up being worse than the disease.

September 8, 2026
GitHub’s New Copilot Feature Takes the Guesswork Out of Picking AI Models

Ask any developer who works with multiple AI coding assistants how they choose a model for a given task, and you’ll get some version of the same answer: Trial and error. A quick model for simple edits. A stronger, pricier one for hard debugging. Sometimes a second model gets pulled in just to check the first one’s work. It’s a manual routing problem, and it falls on the developer every single time.

GitHub thinks it has a fix. The company just introduced Project HydraFusion, a research preview built into GitHub Copilot that handles that routing automatically. Instead of a developer deciding which model gets which task, HydraFusion evaluates the request and builds the workflow itself.

The system leans on three execution patterns. In “single” mode, one model handles the task outright. In “cascade” mode, an efficient model drafts a solution first, and only escalates to a stronger, more expensive model if the draft doesn’t clear a quality gate. In “critique” mode, one model drafts the answer, a second, independent model reviews it, and the original model revises once based on that feedback.

Deciding which pattern to use comes down to a set of capability signals that GitHub evaluates for every request: reasoning demands, code-generation complexity, debugging depth, and tool use. HydraFusion picks the least complex workflow it thinks has a real shot at succeeding, rather than defaulting to the biggest model available. That’s the part platform teams should pay attention to. It’s not just an accuracy play. It’s a cost-control mechanism built directly into the workflow logic.

The early numbers back that up. On TerminalBench 2.1, GitHub reports that HydraFusion delivered a 4.9 percentage-point quality improvement over Claude Opus 5 at an estimated cost 67% lower. On DeepSWE, the cost savings were smaller at 36%, with a slight 1.5-point quality dip. On CheckpointBench, HydraFusion cut costs by 65% while holding quality almost flat, down just 0.1 points. Comparisons ran against Claude Opus 5 and GPT-5.6 Sol, both evaluated at the same medium reasoning level.

Those results won’t hold up the same way across every organization’s codebase or workload, and GitHub is framing this as a research preview for a reason. But the direction is clear enough. GitHub isn’t trying to build a better single model. It’s trying to build a better dispatcher, one that treats “which model should do this” as an optimization problem instead of a developer’s judgment call.

That shift fits a broader pattern in how AI is emerging across the software development lifecycle. Mitch Ashley, Vice President and Practice Lead for CIO & Technology Buyers and for Software Lifecycle Engineering at The Futurum Group, has highlighted this exact transition in his coverage of agentic AI tools. “This new wave of agentic AI development tools represents a shift from AI-augmented tools, which support developers in writing code, to agentic AI, which actively performs multi-step development tasks,” Ashley said. HydraFusion is a fairly literal example of that shift. The orchestration decision, the escalation logic, and the review step: none of them require a developer to steer.

GitHub also shared some early internal feedback. A Microsoft principal software engineer testing the system said, “So far, the reasoning and task-solving capability [of HydraFusion] is at or better than Opus.” That’s a meaningful data point, though it’s one team’s read on a preview feature, not a verdict.

For DevOps and platform engineering teams, the interesting part isn’t the benchmark chart. It signals where model management is headed. Right now, most organizations handle model selection the same way they handle everything else in early AI adoption: informally, per developer, per tool, with little consistency and less auditability. An orchestration layer that automatically routes tasks to the right model and can explain why starts to look less like a coding assistant feature and more like infrastructure. That has implications for cost governance, for security review, and for anyone trying to answer the increasingly common question of which AI model actually touched a given piece of production code.

It also raises a fair question about control. If the system is choosing the workflow, teams will want visibility into that decision, not just the output. Which model drafted the code, which model reviewed it, and why the system decided a cheaper model was good enough are all things a platform team will eventually need to answer, whether that’s for a compliance audit, an incident review, or just a developer who wants to know why their request got escalated. Expect that to be a bigger conversation as tools like this move from research preview to general availability. Trust in an agentic system depends on being able to see how it decided to act, not just on the code it eventually produced.

HydraFusion is still early, and GitHub has been upfront that results vary by benchmark. But the underlying idea, that the smartest use of AI models isn’t picking one and sticking with it, is worth watching. As agentic AI tools take on more of the actual development work, the orchestration layer deciding which model does what may end up mattering as much as the models themselves.

September 8, 2026
Trusted Open Source Catalogs for AI and Developers

Open source supply chain security has been a scanner-and-CVE game for years — pull the package, run the scan, cross-reference known vulnerabilities, hope the metadata is current. That model always had gaps, and AI agents are widening them fast. Agents pull open source components from wherever they can find them, at machine speed, and the after-the-fact scan is not a control that keeps up. What developers and platform teams actually need is a curated catalog that vets components before they enter the environment, not after they cause a problem.

Alan Shimel sits down with Leslie Pascual, Field Engineering Manager for AI and Security Solutions at ActiveState, to work through what a trusted open source catalog looks like in practice and why it becomes table stakes as soon as AI agents join the software supply chain. Pascual brings more than 20 years across engineering, architecture and leadership, with a stint hardening enterprise healthcare applications that pushed her into cybersecurity. Her point is direct — scanners compare packages to CVE metadata after the fact, which is fundamentally different from vetting a component before it ships.

They get into the mechanics. Packages go through a cool-down period, secure build, attestation and strong provenance before landing in the catalog, which now spans the top nine open source ecosystems and is expanding to twelve — Python, Java, JavaScript, R and more. Continuous monitoring keeps catalogs current with patches and fixes, and SBOMs and attestations ship with every component. The integration side matters just as much: catalogs plug into JFrog Artifactory, Sonatype and Cloudsmith so developers see no extra friction, and mirrored repositories let each customer expose the catalog inside their own Artifactory instance.

The forward-looking piece is where AI agents plug in directly. Tools like Claude and Cursor need a source of truth for open source components, and Pascual argues that the trusted catalog becomes exactly that — the place agents pull from instead of grabbing whatever the internet returns. An MCP server is on the roadmap to extend that intelligence directly into the CI/CD pipeline. The broader read is that shifting security all the way left, past the scanner and into the catalog itself, is what actually makes AI-assisted development safe enough for enterprise teams to scale.

September 1, 2026
Harness Unfurls Source Code Repository Alternative to GitHub

Harness today launched a code repository service that is specifically designed for DevOps teams that are relying on artificial intelligence (AI) agents to generate code.

Martin Reynolds, Field CTO for Harness, said the Agent-Ready Harness Code Repository and AI Code Review service provides an alternative to existing GitHub source code repositories that were not designed to handle the volume of pull requests and updates that are made by AI agents operating at machine speed.

As a result, there are not only more outages but search and file history get slower as indexing falls behind, pull requests pile up faster than anyone can read them, and a permission system designed around a list of developers lacks the ability to identify and track an AI agent that might merge code on its own. The assumption legacy source code management tools make is that a human wrote code and opened a pull request that will be reviewed sometime later.

In contrast, the Harness Code Repository has been tested to handle thousands of simultaneous pull requests and commits from both AI agents and human application developers, said Reynolds. Search, history, and diffs keep working across repositories of any size that can have tens of thousands of branches.

Harness Code Repository and AI Code Review are both designed to be reachable via the Harness Model Context Protocol (MCP) server or command line interface (CLI). DevOps teams can review pull requests by the author’s email instead of an internal ID, see every open pull request across every repository and create, reply to, or resolve comment threads without opening a browser.

AI coding agents can either be assigned specific permissions or they can inherit them from application development teams that have deployed them. DevOps teams can further define what an AI agent can access, merge, or deploy, much like they do for any human software engineer using role-based access controls (RBACs) and policies based on the Open Policy Agent (OPA) framework provided via the Cloud Native Computing Foundation (CNCF).

The AI Code Review then reads a pull request, checks to see what gates are mandatory and prevents any request that fails from being merged. Additionally, differences are grouped by risk rather than by file, so high-risk changes that alter how the software behaves are not lost under a mass of renamed repositories and dependencies. A feedback capability also describes what a change puts at stake rather than noting that a line moved. If the feedback is valid, changes can be merged with a single click.

Any team can start using Harness Code Repository for free. Migrations from another repository, including GitHub, GitLab, Bitbucket and Azure DevOps, only require a few clicks, noted Reynolds.

In general, DevOps teams are starting to realize that a piecemeal approach to agentic AI engineering isn’t going to be sufficient, said Reynolds. Instead, the entire software development lifecycle (SDLC) will need to be re-engineered to manage what is becoming massive amounts of code that is overwhelming existing DevOps workflows, he added.

In the case of Harness, that means commits, review, builds, tests, security and deployments all stem from a single sequence within the platform. The Harness Software Delivery Agent then runs those workflows from commit to production using policies created via a single common engine. All workflows are then mapped in the Harness SDLC Knowledge Graph to provide the context needed for every review. Based on early testing, Harness claims DevOps teams have seen savings of 10,000 hours over the last month alone.

Mitch Ashley, vice president and practice lead for the Futurum Group, said the bottleneck in AI-assisted development has moved to review and approval. Agents produce code faster than teams can verify it, and verification debt builds faster than anyone can hire reviewers, he added.
The key here is still accountability, noted Ashley.

Regardless of the approach to software engineering in the age of AI, it’s now more a question of when rather than if DevOps workflows will be re-engineered. The only thing that remains to be seen now is how long that might actually require.

August 27, 2026

How to Build a Durable Change-Control Gate for AI Agents

An AI agent that can call tools is not automatically an unsafe system. The dangerous move is smaller: Letting a workflow turn a recommendation into an external action without a durable decision record.

That distinction matters in DevOps. An agent can sensibly summarize a failed deployment, draft a rollback plan or classify a dependency alert. The moment it opens a change request, modifies a feature flag, creates an incident, messages a customer or publishes a configuration, the system needs more than a high-confidence score.

It needs a change-control gate.

The gate below is a practical pattern for a tool-using agent. It verifies whether the policy is still current, pauses for the required human decision, makes one idempotent outbound request, then confirms the receipt. It is deliberately boring. That is the point.

Figure 1: Illustration of a Workflow Moving Through Policy, Human Approval and Idempotency Gates While a Risky Duplicate Path is Stopped

Why a Confidence Threshold Isn’t Enough

Confidence says something about a model’s answer. It does not say whether a particular action is reversible, who owns its consequences, whether the policy changed while the agent was working or whether the same action has already happened.

For a production workflow, treat those as separate decisions.

Question	What the Gate Should Decide
Is this action permitted now?	Revalidate the current policy and declarations.
Does this action need a person?	Route it to an explicit approver with the exact action payload.
Has this action already been sent?	Use an idempotency key stored before or with the transmission.
Did the destination accept it?	Verify a receipt, job ID or visible confirmation without resending.

This maps cleanly to the NIST AI RMF’s idea that risk management should cover governance, measurement and management throughout the system life cycle — not merely model evaluation. It also fits a practical fact of durable agent runtimes: A paused workflow can restart a node when it resumes, so outbound side effects must be idempotent. NIST AI RMF and LangGraph’s interrupt guidance both make the broader control problem explicit.

The Smallest Useful State Machine

Do not begin with a large autonomous platform. Begin with explicit states that an operator can inspect.

type ChangeState = | “queued” | “policy_blocked” | “approval_required” | “transmitting” | “submitted” | “verified” | “submission_unverified” | “rejected”;type ChangeRequest = { actionType: “deploy” | “create_ticket” | “send_message”; destination: string; summary: string; idempotencyKey: string;};

The useful property is not the spelling of the states; it is that ‘approval_required’ and ‘transmitting’ are distinct. A system should be able to show an approver exactly what will happen before it happens, then preserve a record of the result.

Revalidate Policy Immediately Before the Action

The policy check belongs close to the outbound call. A week-old permissions decision is not a preflight check.

async function canSend(request: ChangeRequest) { const policy = await loadCurrentPolicy(request.actionType, request.destination); return { allowed: policy.isCurrent && policy.permits(request), declarations: policy.requiredDeclarations, checkedAt: new Date().toISOString(), };}

This is where an organization can apply its real rules: Production versus staging, maintenance windows, owner groups, regulated data or a mandatory incident commander for customer-impacting work. Keep the policy data outside the prompt. A prompt may explain a rule; it should not become the only enforcement point.

Ask for Approval Using the Actual Outbound Payload

An approval that says, “approve the agent’s plan?” is too vague. Show the action type, destination, change summary and required declarations.

async function requestApproval(request: ChangeRequest, policy: Awaited<ReturnType<typeof canSend>>) { return interrupt({ kind: “change_control_approval”, actionType: request.actionType, destination: request.destination, summary: request.summary, declarations: policy.declarations, message: “Approve this exact change? Approval sends one request; rejection sends none.”, });}

If the user rejects the request, end the workflow. Do not reinterpret a rejection as a request to regenerate a more persuasive plan.

Make the Transmission Idempotent

The awkward failure is an ambiguous one. The receiving system may complete the change while the client times out before it receives a response. If the agent retries blindly, it can create a duplicate ticket, a second deployment or a second message.

Use a stable key derived from the action’s business identity — not a fresh UUID for each retry.

import { createHash } from “node:crypto”;function actionKey(request: ChangeRequest) { const material = [request.actionType, request.destination, request.summary].join(“\u001f”); return createHash(“sha256”).update(material).digest(“hex”);}async function transmitOnce(request: ChangeRequest) { return fetch(request.destination, { method: “POST”, headers: { “content-type”: “application/json”, “idempotency-key”: request.idempotencyKey, }, body: JSON.stringify({ summary: request.summary }), });}

The destination must honor the key, or your own durable store must do so before the outbound request. Either way, do not put an automatically retried network call before a pause node unless that side effect is safe to repeat.

Verify Instead of Resending After Ambiguity

Treat a timeout as an observation problem first. Query the destination with the key, look for the created job or ticket and write the result to the workflow state. Only retry if the system can prove that no action exists.

async function verifyReceipt(key: string) { const result = await findActionByIdempotencyKey(key); if (result) return { accepted: true, receipt: result }; return { accepted: false, issue: “No receipt found; needs operator review” };}

That final status should be ‘submission_unverified’, not ‘failed’. The name forces the right next action: Investigate before sending another request.

A Controlled Simulation: Where Duplicates Appear

To make the trade-off concrete, I ran a deterministic simulation of 10,000 outbound agent actions. Each simulated action had a 9% policy-change state, a 21% non-approval state and 1–3 resume events. This is a controlled illustration of workflow logic, not production telemetry, a reliability claim or a measured industry failure rate.

Control Design	Sends	Duplicate Sends	Policy-Bypassing Sends	Unapproved Sends
Ungated Send	12,114	2,114	1,106	2,544
Approval Only	9,570	1,673	879	0
Preflight Gate	8,691	1,514	0	0
Durable Gate	7,177	0	0	0

Figure 2: Bar Chart Comparing Outbound Sends and Duplicate, Policy-Bypassing and Unapproved Actions Across Four Simulated Control Designs

The notable row is the preflight gate. It eliminated actions that bypassed policy or approval, but it still created 1,514 duplicate sends because resumed workflow events could enter the same action more than once. The durable gate reduced that to zero in this simulation by using a stable idempotency record.

The simulation code and raw summary are included with this submission so that editors or readers can reproduce the numbers. Modify the assumptions before applying the result to your own environment.

Keep the Approval Boundary Narrow

This pattern is not an argument for asking a human to approve every tool call. That usually leads to notification fatigue and workarounds.

Instead, classify actions by consequence:

Action Class	Typical Examples	Default Control
Read-Only	Fetch a deployment record, inspect a log	Allow with audit trail
Reversible Internal	Create a draft change ticket, add a label	Allow or sample review
Material but Reversible	Change a feature flag, queue a rollback	Named approval plus idempotency
External or Hard to Reverse	Deploy to production, message a customer, delete data	Named approval, policy recheck, idempotency, receipt verification

The fastest agent systems make safe paths easy and consequential paths explicit. They do not pretend all operations have the same risk.

What to Test Before Enabling an Agent Action

Run these cases in a non-production environment before connecting a new action to an agent:

A policy changes after the agent produces its recommendation but before the approval click.
An approver rejects the action, then the workflow resumes.
The destination completes the change, but the client loses the response.
A queue redelivers the same event.
An operator tries the same action manually while the agent is waiting.
Receipt verification is temporarily unavailable.

For each test, the expected outcome should be visible in state: Blocked, rejected, submitted, verified or unverified. “The agent probably handled it” is not an operational status.

The Operational Rule

AI agents can move quickly without bypassing change control. The reliable pattern is straightforward: Validate the rules immediately before the action, show the real payload to the right approver, record one idempotent transmission and verify the result before retrying.

That sequence gives teams something better than a promise of autonomy. It gives them a system they can inspect when the answer is ambiguous and the consequences are real.

Method and Source Notes

Controlled Simulation Script: `scripts/run-contribution-gate-simulation.mjs`
Raw Results: `research/contribution-gate-simulation-2026-08-21/summary.json`
The simulation uses a fixed seed and synthetic policy, approval and resume-event rates. It does not measure any customer system.
The article’s workflow pattern was implemented and tested in TypeScript as part of an internal contribution-control graph. The sample code is simplified for teaching.

August 27, 2026

The AI Agent Race Is On. But Are We Watching the Right Race?

Claude Code, OpenAI Codex, GitHub Copilot, Cursor and a growing field of challengers are competing to define the future of software development. A new Techstrong special report examines who is ahead, how the race should be measured and what enterprises need to consider before placing their bets.

Which AI coding agent is winning?

It sounds like a simple enough question. Claude Code has surged among professional developers. OpenAI Codex is gaining ground quickly. GitHub Copilot enjoys enormous distribution and sits inside the repository and pull request workflows enterprises already use. Cursor has emerged as an agent-native development environment. Google brings powerful models, cloud infrastructure and developer reach. Devin and other specialists are pursuing longer-running autonomous work, while open source projects such as OpenHands, Cline, OpenCode and Aider give organizations more control over models, data and deployment.

There is no shortage of contenders. There is also no shortage of numbers supposedly telling us which one is ahead.

The problem is that those numbers are frequently measuring different things.

Model-routing platforms measure token traffic. Developer surveys measure which products their respondents say they use. Enterprise surveys measure which foundation models organizations have placed into production. Benchmarks measure the performance of a specific model operating inside a specific harness, with a particular set of tools, instructions, compute resources and time limits. Customer stories show what one organization accomplished with one implementation.

All of that evidence is useful. None of it, taken alone, gives us a universal market-share table for AI coding agents.

That is why Techstrong’s new special report, “The AI Agent Race: At the Top of the Stretch,” starts by separating the races before attempting to handicap the field.

DOWNLOAD THE FULL REPORT (PDF)

A Fast-Moving Field

There is little doubt that AI coding agents have moved into the mainstream of software development.

A 2026 JetBrains survey of more than 15,000 professional developers found that 90% used AI coding agents at work at least weekly, while 68% used them daily. Claude Code was used at work by 39% of respondents, up from 18% in January. Codex rose from 3% to 16% during roughly the same period.

Other evidence reveals a different picture. Futurum research found OpenAI, Azure OpenAI and Google Gemini widely used as production model providers across enterprises. Anthropic’s share at the foundation-model level was considerably lower than Claude Code’s position in developer surveys.

Those findings are not necessarily contradictory. An enterprise might use OpenAI models in a customer-facing application, Gemini for data analysis and Claude Code for software development. It might access Claude through GitHub Copilot or Cursor rather than through Anthropic’s own interface. It may use one agent in the IDE, another in the terminal and an internally developed system for background work.

The model, agent, development environment and enterprise platform are becoming increasingly difficult to separate. They are also not always purchased from the same vendor.

That makes this a much more complex contest than the usual horse-race coverage suggests.

Assistance Is Not Autonomy

The other complication is that nearly everything is now marketed as “agentic,” even though most enterprise adoption remains concentrated in assisted rather than autonomous work.

Futurum’s software lifecycle research found individual developer assistance to be the dominant mode of AI use at 47.20%. Supervised agents accounted for another 18.36%, while semi-autonomous agents stood at 13.59%. Autonomous, end-to-end agents represented only 5.84%.

The same boundary appears when we examine where AI is being used across the software lifecycle.

AI was used for code generation by 40.17% of respondents and code review by 37.66%. Adoption fell to 28.01% for testing, 20.98% for observability, 16.21% for incident response and 13.23% for CI/CD operations. Only 6.20% reported using AI in deployment decisions.

Enterprises are clearly willing to let AI help create and review a change. They become more cautious as an agent approaches infrastructure, credentials and production.

That caution does not mean the autonomous software delivery vision is dead. It means that every increase in autonomy also increases the potential consequences of failure.

A bad code suggestion can be rejected. A bad commit can be reverted. An agent with access to secrets, infrastructure or a production deployment pipeline can cause damage before a person understands what it has done.

The report examines this widening gap between agent capability, enterprise authority and the controls organizations have actually deployed. Some of the findings should give DevOps, platform engineering and security leaders pause.

The Leaderboard Can Mislead

Public benchmarks remain an important part of evaluating coding agents, but they can create a false sense of precision.

A benchmark score does not belong to the model alone. It reflects the model, the agent harness, the available tools, the task design, the execution environment and the resources the system was allowed to consume.

Change the tool interface and an agent may complete more tasks while using fewer tokens. Change the compute or memory allocated to the environment and leaderboard positions may shift. Use a familiar public repository rather than an undocumented internal codebase and the benchmark may tell an enterprise very little about how the agent will perform on its own work.

The report looks at recent questions surrounding SWE-bench Verified, the emergence of SWE-Bench Pro, Terminal-Bench and evidence showing how infrastructure and purpose-built tools can materially change agent results.

It also examines the cost question, which has become almost as confusing as performance.

A monthly seat price, token rate or premium-request allowance does not tell a software organization what useful agent work costs. The real calculation includes inference, compute, tools, retries, human steering, review, rework, defects and rollbacks.

The least expensive model may generate the most expensive pull request.

Picking the Right Horse for the Course

The AI agent market is beginning to take shape, but it is far from settled.

Claude Code, Codex, GitHub Copilot, Cursor, Google, autonomous specialists and open harnesses each enter the race with different advantages. One may lead in reported developer adoption. Another may control the workflow through which enterprises accept and govern changes. A third may provide the model portability or data sovereignty required by a regulated organization.

There may be leaders, but it does not follow that there will be one winner for every kind of software work.

“The AI Agent Race: At the Top of the Stretch” examines the field, the evidence behind the claims, the gap between assistance and autonomy, the limitations of public benchmarks, the economics of agentic development and the questions enterprises should ask before expanding an agent’s authority.

It also offers a practical framework for evaluating these systems against an organization’s own code, workflows, risk tolerance and definition of a successfully completed task.

I will save the report’s final handicapping for the report itself. It is available ungated, so you can read it without surrendering your email address or waiting for someone to call.

Ask Patrick Debois Anything, Live at DevOps Experience

The report is being published in support of DevOps Experience 2026, and we are adding a special session worthy of the occasion.

Patrick Debois, the man who coined the term DevOps and helped launch the movement, will join us for a live AMA. Patrick will be joined by Futurum’s Mitch Ashley and several surprise DevOps experts for a wide-ranging, unscripted conversation.

This is your opportunity to ask Patrick and the panel about where DevOps goes from here. Bring your questions about DevOps, AI-native development, coding agents, platform engineering, software delivery, the changing role of developers or anything else shaping the next era of the movement.

The report frames many of the questions the industry now needs to confront. At DevOps Experience, you will have the chance to ask them directly of the person who helped start the conversation.

Download the ungated Techstrong special report, “The AI Agent Race: At the Top of the Stretch,” and register for DevOps Experience 2026 on Sept. 24, 2026.

The field is coming into view. The finish line is not, and the people who helped define DevOps will be with us to discuss what comes next.

August 25, 2026
Preparing Infrastructure for the Next Phase of Agentic AI

After years of exploring how AI can support agency operations and make better use of growing volumes of data, agencies are now preparing for the next phase: agentic AI.

The infrastructure needed is changing along with it. Agentic AI, unlike regular AI capabilities, can coordinate multiple specialized agents to carry out complex, multistep workflows, which means agencies are no longer planning only for the compute required to run AI models. They also have to account for the orchestration between agents, the movement of data across environments, and the points where human judgment still belongs.

That makes it important to start with the work itself—not the newest, shiniest technology. The following three strategies can help.

Start With the Workflow, Not the Hardware

Agentic AI is more sophisticated, but it also requires more orchestration and preparation. Consider a permitting process. One agent might evaluate municipal requirements while another examines state or federal statutes. A third agent—or a human—might then validate conflicting information before the process can move forward. The individual AI tasks are only part of the workload. The system must also coordinate those tasks, determine when one step depends on another, and move information between them.

That changes infrastructure requirements. AI environments have often been designed around compute-intensive model workloads, with significant attention paid to accelerators. But agentic systems can introduce substantial CPU and networking requirements as agents execute workflows and interact with one another.

Before deciding where to invest, agencies should map both the workflow and the data flow. Where will each agent perform its work? What information will it need, and where does that information reside? Which steps can occur simultaneously, which depend on one another, and where is human review required?

Those questions are especially important in hybrid environments, where data and workloads may span cloud and on-premises systems. An architecture optimized for one generation of AI can create new bottlenecks when multiple agents must coordinate across distributed environments.

Mapping the workflow can also reveal where agentic AI will and will not provide value. An existing 12-step process, for example, might contain five steps that agents can accelerate while others lack sufficiently accessible or reliable data to make automation worthwhile. The goal is not to insert an agent into every step, but to understand the process well enough to determine where autonomy can improve it and what infrastructure those agents will require.

Prioritize Resources With Observability

With more agents operating simultaneously, agencies also need a way to determine which workloads receive infrastructure resources first. Those priorities can reflect mission importance, deadlines, or operational requirements. A financial reporting workload at the end of the month, for example, might temporarily receive priority over a less time-sensitive optimization workload.

The underlying concept isn’t new. High-performance computing environments already use scheduling systems to prioritize workloads based on factors such as urgency and deadlines. As agentic AI develops, agencies must consider how similar principles might help automate resource prioritization more broadly rather than assuming there is already a mature playbook for doing so.

That depends on visibility. IT teams already collect telemetry such as performance metrics, storage information, and logs. In an agentic environment, that information may need to be readable not only by IT teams but also by the systems monitoring and coordinating autonomous workflows.

Consider what happens when an agent encounters a latency spike or another performance issue in the middle of a workflow. Instead of simply stopping, could it use performance or security telemetry to help determine what went wrong? Depending on the policies in place, the system could then recommend reprioritizing or moving the workload or escalating the issue for human review.

Design Around Data Movement, Not Rip-and-Replace

Agentic AI also puts new pressure on data architecture. Agents may depend on information residing across multiple clouds, local systems, and external data sources. Simply having access to that information does not mean an agent can retrieve it quickly enough—or in the appropriate form—to complete a workflow efficiently.

Agencies should map those dependencies to identify potential bottlenecks, from data cleansing and outdated external sources to latency when retrieving information from remote environments. Because agents often depend on one another, a delay in one step can affect the entire workflow. Understanding dependencies can also inform decisions about where data should reside and whether compute, networking, and other infrastructure resources align with agentic workloads.

But identifying a bottleneck should not automatically trigger the need for a new technology purchase. Agencies should first establish the “as-is”: What infrastructure, platforms, data sources, code, and capabilities are already available? What can be reused or consolidated? And where would a new investment fill a genuine gap?

That assessment matters because few agencies can (or should) replace their infrastructure every time the technology landscape changes. A stepwise approach allows them to target the most consequential bottlenecks, build on existing investments, and consider total cost of ownership as agentic AI evolves.

The infrastructure required for agentic AI will continue to change as the technology matures. Agencies don’t need to predict every requirement today. They do need a clear picture of their workflows, data, and existing environment so they can modernize where the mission actually demands it.

August 24, 2026
AI Agents Are Writing Code Faster Than Anyone Can Review It. Tessl Is Betting On Standards To Close That Gap

Every team that has turned coding agents loose on real work has run into the same wall. The agents write fast. They write a lot. And somewhere between the tenth and twentieth pull request of the day, the humans responsible for reviewing that code start falling behind.

That’s not a hypothetical. It’s the operating reality on teams that have adopted agentic development this year, and it’s the problem Tessl is aiming to address with the launch of Tessl Code Review, a new tool the company rolled out this week and is offering for free during its beta period.

The pitch is simple: teams don’t need another reviewer catching naming nits and formatting issues. They need a reviewer that runs on its own, filters out the noise, and actually knows the team’s standards. Tessl Code Review checks pull requests against those standards, written once and stored as a skill the team owns and controls.

That last part matters more than it might sound. A lot of AI code review tools ship with review logic baked into the product, which means the criteria a team is being judged against lives somewhere they can’t see or edit. Tessl took a different approach. Review standards live in the repo as versioned files, just like code. Teams can start with Tessl’s default review skills, or fork them, edit them, and point their own agent at their own repo. If a team decides to switch tools later, the standards go with them.

The other piece worth understanding is what the tool actually reads before it renders a judgment. Most AI reviewers look at the diff and little else, which means they’re commenting on a slice of a change without the surrounding context that would tell them whether the change actually makes sense. Tessl Code Review reads the whole pull request: the surrounding codebase, the team’s standards, and everything already discussed in the thread. Every finding is supposed to be traceable back to something concrete, not a guess based on eight or nine changed lines.

That context also carries forward. Update a pull request after a first round of review, and the next pass already knows what was fixed, what was explained, and what was declined. It focuses on what’s still open instead of re-flagging the same three issues every time someone pushes a new commit. Anyone who has sat through a review cycle where a bot keeps repeating itself will recognize why that’s a real fix and not a minor convenience.

“Agent-written code now stalls at review,” said Mitch Ashley, an analyst at The Futurum Group who tracks agentic software development. “Agents open more pull requests in a morning than a reviewer clears in a day, so review quality drifts with whoever is on the hook. No one hires their way out of that.”

Ashley pointed to the same fix Tessl is building toward: standards that are visible to the team. “The fix is standards written once, versioned in the repo, and owned by the team, since reviewers cannot enforce criteria they cannot see,” he said.

The volume problem behind all this isn’t going away. Agentic coding tools are now writing meaningful shares of the code that gets merged into production repos, and that pace isn’t slowing down. Review has become the bottleneck, and it’s the kind that doesn’t respond well to simply adding more human reviewers. Teams either build review capacity that scales with agent output, or they start merging more code than anyone actually looked at closely.

Tessl isn’t the only company chasing this problem, and AI code review has become a crowded category over the past year as tools like CodeRabbit and Qodo have pushed into the same territory. What sets Tessl’s approach apart is the emphasis on ownership. The standards aren’t a black box inside the vendor’s product. They’re files a team writes, versions, and can take with them, which lowers the switching cost that usually keeps teams locked into a review tool once they’ve invested in configuring it.

For platform engineers and DevOps leads evaluating this space, the free beta is a low-cost way to see whether whole-PR context and standards-as-code actually change review outcomes, or whether it’s another layer of noise on top of an already noisy pipeline. Tessl has a quickstart guide that promises a first review in about 10 minutes against a team’s own standard, along with a setup skill for teams working through their own coding agent, and Discord support for teams working through setup.

The bigger question this launch raises isn’t really about Tessl. It’s about how development teams will keep human judgment in the loop as the volume of agent-written code continues to climb. Standards that live in the repo, travel with the team, and are automatically checked on every pull request are one answer. Whether they’re a durable one will depend on whether the reviews hold up once teams start trusting them with the code that actually matters.

As Ashley put it, the constraint has already shifted. “Review capacity now caps how fast agent code ships,” he said. “Engineering leaders own closing that gap, not tool vendors.”

August 20, 2026
Harness Adds AI Agents to Automate DevSecOps Workflows at Machine Speed

Harness today added multiple artificial intelligence (AI) agents and a virtual patching capability to its portfolio to automate DevSecOps workflows at a time when the number of vulnerabilities being discovered in code continues to exponentially increase.

The AI agents include one that has been added to the static application security testing (SAST) tool that Harness already provides. In addition, there is now a set of AI agents that automatically triage scanner findings to prioritize remediation efforts based on exploitability, create and validate a fix, and open a pull request for a developer to review and approve. DevSecOps teams can also opt to add their own AI scanners within their pipelines.

There is also now a Zero-Day Agent that monitors threat intelligence feeds for newly disclosed zero-days on a 24/7 basis. Once a zero-day vulnerability is discovered, the AI agent instantly identifies every affected pipeline and artifact and generates a validated fix ready for review within minutes.

Finally, Harness has added a capability that enables DevSecOps teams to apply a virtual patch the moment a vulnerability is discovered during testing that requires no code changes.

Rahul Sood, general manager of application security at Harness, said collectively these additions make it possible for DevSecOps teams to respond to issues at machine speed. That’s crucial at a time when advanced AI models are now capable of discovering thousands of vulnerabilities in applications that cybercriminals can now create exploits for them in a couple of hours, he added.

Many DevSecOps teams are also underestimating to what degree their applications may now become collateral damage when cyberattacks enabled by AI impact organizations that might not have been the initial target, noted Sood.

The challenge that DevSecOps teams are encountering as they attempt to use AI to discover many of those vulnerabilities themselves is the number of false positives those tools generate. By incorporating AI agents into a SAST tool it becomes possible to combine the probabilistic capabilities of an AI agent with a deterministic platform that validates whether a vulnerability is actually exploitable, said Sood. That approach also provides the added benefit of reducing the number of tokens that would otherwise be consumed by an AI agent as code is scanned, he added.

Mitch Ashley, vice president and practice lead for software lifecycle engineering at the Futurum Group, said DevSecOps teams in the AI era are now drowning in vulnerability findings they can’t act on fast enough. Harness, in effect, is moving triage and remediation into the pipeline that already ships the code so the fix now travels with the release, he added.

Periodic scanning was built for code humans wrote at human speed, noted Ashley. Machine-speed generation breaks that model, which means DevSecOps teams now need to have control the moment code is created, not at the next scan window, he added.

It’s not clear to what degree DevSecOps teams are revisiting existing workflows, tools and platforms to address what has become a vulnerability management crisis, but for most it’s now more a question of when and to what degree rather than if. In fact, the issue in the short term at least may be prioritizing which applications to fix first on the assumption that DevSecOps teams will not be able to remediate every issue before a wave of AI-enabled cyberattacks are launched.

On the plus side, however, it may also turn out that in the longer term the overall state of application security may finally improve as DevSecOps teams finally address technical debt issues that have been kicked down the proverbial road for far too long.

August 19, 2026