Not your keys, not your coins. Not your model, not your data?

Over the summer, the tech industry was consumed by a debate about AI use in the enterprise and the need to protect IP. If an enterprise used proprietary models, was data leakage a necessary evil?

Companies seemed to have two options: They could use state-of-the-art, proprietary models and risk losing control of their data, or they could use open-weight models and never kiss the frontier.

Thankfully, a third option is emerging.

Consider the concern: Company A wants to use LLM B from AI Lab C, and they want to avoid training AI Lab C how to eat Company A’s lunch by building its capabilities into LLM B. A good way to resolve the tension would be to let Company A run LLM B on its own infrastructure, so there’s no risk of its information fleeing on the wind.

AI agents are “creating a whole different set of requirements at the data layer.”
–Vast Data co-founder Jeff Denworth

But that raises another problem: AI Lab C doesn’t want to allow Company A to run LLM B on its own GPUs because it doesn’t want to hand over its model weights. It’s the same IP issue the company ran into, in reverse. You have to solve the trust problem in both directions!

Enter VAST Data co-founder Jeff Denworth and a new product called DataEnclave, which aims to let AI labs and enterprise-scale companies deploy proprietary models in secure compute environments without risking data transfer in either direction. (DataEnclave uses Nvidia’s Confidential Computing technology to make the system tick; Vast Data’s core product is AI OS, infrastructure that fits beneath a company’s AI applications.) 

The New Stack had Denworth on the podcast to chat about the confidential computing market. I was curious about timing. Why did Vast build DataEnclave now? Nvidia began rolling out Confidential Computing in a serious way in 2024, after all. Denworth argues that the market needed the core technology, yes, but also demand.

And until late 2025, AI demand was modest compared to today’s token totals. Once agentic coding tools took off, corporate demand for AI products soared. This led to the pricing crisis we saw in early 2026, and the secure AI usage debate we endured over the summer. 

Performance drove demand, demand drove usage, and usage dug up fresh problems to solve. Now the question for the market is whether or not DataEnclave has solved enough concerns on both sides of the proprietary AI-proprietary data equation. The market will sort that out as it moves through early access and into general availability.

Our conversation goes deep into the arc of AI, where companies are in their AI journey today, and how much data remains to be unlocked inside the enterprise. If you want to feel the acceleration, it’s a fun one!

The post A third option is emerging in the fight over AI and your data appeared first on The New Stack.

As one of Harness’s field CTOs, Martin Reynolds spends much of his time asking engineering leaders one question with no easy answer.

It’s how they’re keeping up with all the pull requests their coding agents now produce. One of them recently answered with two words, “we’re not,” and explained that his team’s threshold for pushing code into production had dropped, Reynolds tells The New Stack.

TNS spoke with Reynolds a few days after Harness launched a rebuilt Code Repository and a new AI Code Review product — and a few weeks after GitHub’s nearly eight-hour platform outage on August 17.

In our conversation, we discussed how the review bottleneck arose, why Harness rebuilt its Git repository for agent traffic, and which parts of the pipeline should remain deterministic.

Drowning in pull requests

Reynolds says he first ran into the bottleneck during Harness’ early trials of GitHub Copilot and Amazon CodeWhisperer.

“We were getting more PRs, but all the PRs were getting stuck,” he says, “and the test team was shouting, saying, we can’t keep up with all of this.”

“Imagine what that test team feels like right now.”
—Martin Reynolds, Harness Field CTO.

The 1.5x to 2x increase in new code pushed the testing teams to the breaking point, he says, and now, he sometimes sees teams at 10x, with some claiming 50x. “Imagine what that test team feels like right now.”

Reynolds notes that during hallway conversations with engineering leaders at the conference, drowning in pull requests was a recurring theme. And what he sees when talking to customers tends to split three ways: Some have raised their risk tolerance, some have a backlog they can’t manage, and most sit in the middle.

“The somewhere in the middle, I think, is the most common,” Reynolds says. “We’re using some kind of another AI tool to help us in that space, but it doesn’t necessarily solve the problem.”

Review what’s changing, not the scaffolding

Ideally, a reviewer opening a pull request should see the most important changes first, Reynolds says, and he suggests reviewers should come from whoever has worked on that part of the codebase before, “not the person who did the prompt or wrote the code.”

“This other stuff is like 30 files because they updated a dependency. That’s less important in terms of getting eyes on,” he says. Reviewers should “actually review what’s changing rather than a bunch of stuff that’s scaffolding around it.”

“It’s not just the model on its own,” he also notes. Harness spent “a good chunk of the last 12 months” building what it calls a software delivery knowledge graph, a map of a customer’s pipelines, deployments, incidents, and policies, so the reviewer can pull context “at speed and not burn lots of tokens.”

The company’s own example is a migration flagged because an earlier incident review found an unindexed CREATE INDEX statement had locked a production table for 14 minutes.

By the company’s own count, its engineers saved more than 10,000 hours of manual review time a month. The day Harness launched, GitHub’s Copilot code review began reviewing pull requests opened by bots, including its own coding agent.

Agents don’t work nine to five

Recently, Harness customers on GitHub “would quite often genuinely send us screenshots of GitHub being down,” Reynolds says.

The reason for GitHub’s struggles, he believes, is that GitHub “was ultimately built for people, teams of maybe up to 10, 15, who are changing code, creating pull requests. Those pull requests will be there for a few hours to maybe a couple of days.” But agents “don’t work nine to five.”

Harness has been selling a repository service since 2023, when it launched Harness Code on top of its open-source Git project, and Reynolds says the company rebuilt it as “a ground-up AI-first repository that works for humans and AI.”

He describes it as Kubernetes-based, running across multiple clouds and regions, tested at thousands of commits per second, and used by about 20 enterprise customers during beta, none of which Harness has published.

GitHub CTO Vlad Fedorov’s postmortem on the August 17 outage said “a critical infrastructure component in our Central US data center failed to scale” as traffic hit a new peak. GitHub now handles 2.9 billion commits a month, a little more than 1,000 a second on average.

That’s not the scale Harness operates at, of course, but for its enterprise users, that may just be an advantage.

Harness is also starting to look beyond the traditional process. The capabilities for an autonomous delivery lifecycle exist today, Reynolds argues, but “are organizations and companies ready for that? I’m not entirely sure.”

Either way, he says deterministic tooling needs to stay, and test results still come from the test runner. “There’s no need to rip those out and replace them. It’s like, where can you enhance them?”

The reviewer is the part of this launch most teams will touch first. It works on pull requests that already live on GitHub, and moving a repository is a long project at most enterprises.

The engineering leader who told Reynolds “we’re not” doesn’t need a new Git host to change that answer. He needs something that tells his reviewers which files in a pull request still need a human and which 30 came with a dependency bump.

That’s a much smaller promise than an autonomous delivery lifecycle, but for now, it’s also likely the more useful one.

The post Harness rebuilt its Git repository for nonstop AI agent traffic appeared first on The New Stack.

A metrics dashboard can tell you a system’s health with ease. A log can help you understand a discrete failure. But if you want to understand where in a query’s journey things went awry, you need traces.

By tracking a request from its point of origin through data and microservices to the end user, traces offer unparalleled insight into how systems work and where failures occur. SREs offer the fastest path to remediation. That means less downtime, fewer burned-out developers, and happier customers.

Sadly, the promise of traces often doesn’t match the on-the-ground reality. 

Why? Simply collecting and holding onto all your company’s traces is an exercise in hoarding. Do you need to store terabytes of tracing data just to show when your systems worked? Not only is that much information expensive to hold onto, but collecting it can slow the very systems you are trying to monitor. And when you have all the stored tracing data, finding what you need in the ocean of information can take too long.

Is tracing cooked? Not at all.

Is tracing cooked? Not at all. There are several ways to beat back tracing data overload: Head sampling collects only a portion of tracing data, reducing storage concerns; tail sampling asks whether, after a trace is recorded, it is worth holding onto, making it easier to find what you’re looking for down the road. And dynamic sampling can automatically cull similar or highly repetitive traces, so you don’t accidentally flood your storage system with nearly identical data.

You can avoid the most common tracing pitfalls by building your observability system intelligently. That’s precisely what I was hoping to learn from Sarah Hudspeth of Chronosphere (a Palo Alto Networks company), who is my guest on the latest episode of The New Stack podcast.

Whether you are just starting your tracing journey or deep in the trenches looking for help, Hudspeth’s ability to turn abstract technical concepts into simple, digestible analogies is enviable. 

Hit play on the episode above, and let’s jump the chasm between the promise of tracing and getting it to work for you in a production setting.

The post How to find failures without drowning in tracing data appeared first on The New Stack.