Retiring Tidra, and what we learned about the agentic SDLC

We’re retiring Tidra as a standalone product.

The Maintenance Agent features and technology behind Tidra isn’t going away. It will continue to be part of OpsLevel, where many customers are regularly using it to automate maintenance work across lots of services and repositories.

However, building Tidra taught us a bunch about where AI is taking software development. In particular, it changed our thinking about the size and shape of the problem we should be working on.

So, a little history first.

From coordinating maintenance to doing it (aka the world’s least exciting engineering work)

OpsLevel started as an internal developer portal. But it grew much beyond that.

At a basic level, developer portals help engineering organizations answer questions that get surprisingly hard as companies grow:

What software do we have? Who owns it? How does it all fit together? Is it being built and operated the way we expect?

The Software Catalog became the foundation for that.

Several years ago, we added Campaigns to solve a related problem: Platform teams have all sorts of cross-cutting work they need to drive across an organization. Upgrade an internal library across 75 Java services. Remediate a high-severity vulnerability. Add a stanza to every Kubernetes config. Adopt a new logging standard.

None of these changes are particularly glamorous.

They are also notoriously hard to finish.

The hard part usually isn’t changing one repository. It’s the bigger workflow: figuring out which 75 repositories need changing, who owns them, telling those teams what to do, tracking which ones are done, and then politely reminding the other 53 teams that yes, they still need to do the thing.

Campaigns automated a lot of that program management.

That worked pretty well.

There was just one obvious limitation: OpsLevel could automate the program management bits and tell everyone what needed to happen, but the individual teams still had to actually do the work.

But then: coding agents got good.

By late 2025, we felt like models had crossed an important threshold. For a lot of bounded coding tasks, they weren’t just useful assistants anymore. They could actually complete the change.

That led us to Initiatives and Maintenance Agent.

Instead of a platform team saying:

“Hey, I know you’re busy, but can you please upgrade internal-lib to v2.0 sometime this quarter? Here are some possible backwards-incompatible changes to figure out…”

They could say:

“Here’s a PR that fully upgrades you to internal-lib v2.0. Please review it.”

That’s a much better interaction.

The owning team still has some work to do in this model. They own their software, so part of that responsibility means someone should actually review the change.

But “please go do this work” and “please review this completed work” are very different operating models.

Then we built Tidra

Maintenance Agent originally lived inside OpsLevel.

But we saw what looked like a standalone product opportunity.

Buying and rolling out an internal developer portal is an organizational decision. You’re generally trying to solve a broad set of problems around ownership, complexity, standards, self-service, and developer experience.

Maintenance felt different.

If you have 100 repositories and need to make the same change across 40 of them, that’s a pretty self-contained problem. One that lots of platform teams face. You shouldn’t necessarily need to deploy an entire IDP to solve it.

So we pulled that experience out into its own product.

We called it Tidra, a portmanteau of “tidy” and “rapid.”

Connect GitHub. Tell us a little about your organization. Describe the change you want to make. Let the agents figure out which repositories are affected and start opening PRs.

As a new “brand”, Tidra brought along a lot of novelty for us: new website, new logo, new positioning, new LinkedIn page, new ad campaign, new outbound. The whole thing.

And off we went.

What we learned from Tidra

Quite a bit.

Maintenance is a real problem. It’s just one part of a much bigger one.

We continue to see strong value in Maintenance Agent inside OpsLevel. It’s been a great part of our product suite.

As a standalone product, though, the wedge was narrower than we expected.

More interestingly, conversations with engineering organizations rarely stayed focused on maintenance for very long.

Yes, they want agents to remediate vulnerabilities and upgrade dependencies across their org.

They also want agents reviewing code. Fixing CI failures. Triaging bugs. Implementing features. Testing changes. Updating infrastructure. Investigating production incidents.

Maintenance is one class of work that agents can take on. It isn’t the category though.

The larger question we kept hearing was some version of:

We’ve given everyone access to AI coding tools. Now how do we turn that into an organizational capability?

That’s a much more interesting problem.

Faster coding moves the bottleneck

This was probably our biggest learning.

The first wave of AI in software development focused, quite reasonably, on writing code faster.

And wow, did that work.

But software development is not just typing code into an editor.

If an agent writes a feature in 20 minutes and the PR waits two months for somebody to review it, congratulations: you made one part of the system incredibly fast.

But you didn’t make the system fast.

From a queuing theory perspective, the bottleneck moved.

We’re already seeing this with review. Agents can produce a lot more code than humans used to. Human review capacity did not magically increase at the same rate.

The same thing happens with planning, testing, CI, security review, deployment, and all the other steps around implementation.

And then there’s trust.

When a human engineer writes 200 lines of code, another human reading those 200 lines is a reasonable verification strategy.

When agents can produce thousands of lines across dozens of repositories in parallel, “have a human carefully read all of it” starts to break down pretty quickly.

You need better verification loops. Better automated review. Better tests. Better guardrails. Better ways to know when a change is routine enough to proceed and when a human really should look at it.

Writing code faster is useful.

But it’s a first step towards the actual goal of shipping software faster.

The interesting problem is converging to the system around the agents.

Agent activity isn’t the metric

There’s a similar trap around measurement.

Tokens consumed? Not very interesting.

Number of agent sessions? Also not very interesting.

PRs generated? Better, but still easy to game.

If an agent produces twice as many PRs and humans spend twice as much time fixing them, have we improved anything?

The metrics we care about are closer to the software delivery system itself.

How quickly does useful work move from intent to production?

How often does an agent get a change right on the first attempt?

Where are humans spending their time?

What types of work can safely run with more autonomy?

What is the total cost of getting a successful change into production, including inference, execution, retries, and human attention?

And, most importantly: Are we increasing throughput while maintaining or improving quality?

That feels like the right level of abstraction.

The bigger opportunity: agentic SDLCs and software factories

All of this has pushed our thinking beyond maintenance.

For the last year, a lot of engineering organizations have been in what I’d call the “give everyone Claude and Codex” phase of AI adoption.

That has driven enormous individual productivity gains.

But it’s also fairly decentralized.

Different developers use different tools, different prompts, different models, different MCP servers, different skills, and different levels of autonomy.

That’s probably fine when AI is an assistant.

It gets more interesting when agents start doing meaningful parts of the SDLC themselves.

What context should they have? Which organizational standards should they follow? What tools should they be allowed to use? When can they act autonomously? Where should humans approve their work? How do you verify what they produced? How do you compare one model or harness against another? How do you know whether any of this is actually helping you ship better software faster?

Some people are calling the end state a software factory. I think that’s useful shorthand, although the term itself can get a little fuzzy.

The more precise shift, to me, is toward an agentic SDLC: agents participating throughout the process of taking an idea all the way to running software, with humans increasingly focused on intent, judgment, and oversight.

It turns out that OpsLevel is the perfect foundation for this, and has been getting used as that foundation by some our customers already as they shifted towards an agent-first architecture.

The catalog — that helped humans understand their software estate — has become critical context for agents.

Standards — that helped teams build software the right way — has become guardrails for agents.

And the reporting layer that helped engineering leaders understand their software estate can expand to measuring throughput, quality, cost, and autonomy across the delivery process.

This is one reason we remain very bullish on the software catalog in an AI world.

Agents don’t make organizational complexity disappear.

If anything, they make good organizational context more important.

An agent staring at a Git repository knows what’s in that repository.

An agent that understands the service it belongs to, the other systems it depends on, the team that owns it, its production infrastructure, the standards that apply to it, and the other repositories affected by a change can do a lot more useful work efficiently.

What happens to Tidra?

We’re no longer accepting new Tidra signups.

Maintenance Agent will continue to be developed inside OpsLevel. (And will expand to something much bigger, as we agent-ify your entire SDLC.)

For existing Tidra customers, we’ll transition your accounts to full OpsLevel accounts at no additional cost over the coming months. We’ll reach out directly as that process begins.

Tidra helped us test an important idea: agents can take on broad software maintenance work that previously required coordination across dozens or hundreds of teams and repositories.

We still believe that.

However, what changed is our view of the size of the problem.

Maintenance is one part of a much bigger shift in how organizations build software.

We started by asking how agents could help platform teams finish cross-cutting maintenance work. We came out of it asking a larger question:

What does the software development lifecycle look like when agents can do a meaningful amount of the work?

We think there’s a lot to build there.

More to announce on that very soon.