AI can write the code.
Your team still gets the call when it breaks.
You can accelerate the creation of a system without accelerating your ability to understand it. The feature ships. The product gets more capable. Then a customer cannot log in, a payment fails, and someone has to work out what happened across services they did not build.
The productivity gain is easy to demonstrate. The work it leaves behind is harder to see until somebody has to do it.
Anish Agarwal sees this tension in software engineering. In our conversation on Inside the Silicon Mind, he described engineers inheriting more review and production cleanup as AI writes more code. The promise was more time for creative work. The immediate experience can be a longer queue of things to check and fix.
Anish is the co-founder and CEO of Traversal, which is building AI agents to investigate production incidents and help keep software reliable.
If you are deciding what to build, pay attention to this pattern:
When a breakthrough makes one part of a workflow faster, look for the work piling up afterward.
Progress moves the bottleneck. Sometimes it moves the market with it.
1. Find the assumption that is breaking
A dashboard is a small act of prediction.
Someone decided which information would matter the next time something went wrong. They wrote a query, chose a graph, and put it where another person could find it.
Anish calls it an “enshrined query.”
For years, this has been central to observability: the tools engineers use to understand what is happening inside a software system. Logs record events. Metrics measure performance. Traces follow a request as it passes between services. Dashboards turn selected pieces of that information into something a person can read.
You can create ten times as many dashboards without giving an engineer ten times the capacity to hold the relationships in their head.
Anish describes incident calls that grow as the investigation moves from team to team. The database group gets pulled in. Then an application team. Each has a piece of the picture. The call can reach fifty or sixty people before someone with years of experience connects the clues.
The software has generated plenty of information. Understanding still depends on assembling the right people in a room.
And the system keeps changing. The dashboard reflects what somebody already knew to look for. The next failure may happen in a way nobody anticipated.
AI adds another pressure. Anish argues that an engineer responding to an incident may understand less of the underlying code and telemetry when AI produced them. The team has more software to operate, with less firsthand knowledge of how it was assembled.
The old problem was keeping software running. The changing condition is how much of that software a person can reasonably understand.
A familiar problem can become newly urgent when the assumptions behind its solution stop holding. You do not have to discover pain nobody has ever felt. You can notice why the way people have been managing it is starting to fail.
Ask what your customer’s current solution quietly expects a human to do.
Remember the history of every decision? Read every output? Connect evidence scattered across six tools?
Then ask what happens when the volume doubles.
2. Look beneath the market label
Anish and his co-founders began with a sense of the kind of problem they could solve before they had a company idea.
He and two of his co-founders had met while doing their PhDs at MIT. Their research included causal machine learning and reinforcement learning. They were interested in how systems learn cause and effect, and how they search through large spaces of possibilities.
A fourth co-founder, who came from Citadel Securities, introduced them to the reliability problem.
Underneath the unfamiliar industry vocabulary, they recognized familiar mechanics.
A software system is a network. One thing breaks and the effects spread. Soon, several things look broken. Some are symptoms. Some are unrelated. One may be the cause.
The challenge is to distinguish them while searching through an enormous amount of evidence.
“It felt like we were designed for this problem,” Anish said.
A market label can hide a problem you already understand deeply.
That is one way to find founder-market fit: recognize where your particular expertise matches the underlying difficulty.
But you still need the people who understand how the problem shows up in practice.
At Traversal, researchers work alongside experienced site reliability engineers, or SREs: the people who operate systems and keep them resilient. Anish described an SRE working closely with the research team, bringing years of troubleshooting experience into the development of the AI.
The research explains what might be possible. The operator helps reveal what will actually work.
If you are choosing a problem, look for that combination. A relevant technical advantage becomes more valuable when it meets a precise understanding of the customer’s daily frustration.
3. Rebuild around whoever does the work
Once an agent becomes the investigator, the implications reach beyond the interface.
A human needs information presented in a form they can scan and understand. An agent may need to search much more of the data in parallel, choose which evidence to pursue, and preserve what it learns for the next investigation.
Anish sees that as a reason to rethink how observability data is stored, indexed, and queried.
Existing dashboards can still help. He describes them as a useful starting point because they contain knowledge about what people previously considered important. But an agent may store and reuse its own discoveries in a different form.
Changing who does the work can change the system the work requires.
For founders, the question becomes concrete: which parts of the current product exist because a human has to operate them? What becomes unnecessary when that changes? What new capability becomes essential?
There is a second boundary to examine: the one between vendors.
Anish describes large enterprises using multiple observability tools. A customer cannot complete a purchase, but the issue may be several services away from checkout. The evidence needed to trace that failure can be spread across products owned by different vendors.
The customer experiences one broken journey. An engineer has to assemble the explanation from several places.
Anish argues that vendors whose pricing depends on the data customers bring into their platforms have an incentive to draw more data inside. Traversal’s approach, as he describes it, is to investigate across the existing systems and sell the value of the answer.
“We want to sell you the outcome,” he said.
Even in a crowded market, examine what a customer still has to do after buying the tools.
Who joins the pieces? Who resolves the contradictions? Who is responsible when the individual products work but the overall job remains unfinished?
The manual effort between products can reveal an opportunity that a feature comparison will miss.
4. Follow the work all the way to the end
Anish compares severe incidents to heart attacks, recurring alerts to chronic conditions, and long-term resilience work to improving your health before something goes wrong.
Emergency work consumes the attention that could help prevent the next failure.
Traversal’s ambition is to change that allocation. Anish expects agents to take on more investigation, involving people for verification or when an answer is uncertain. Engineers would have more time to improve the underlying system.
That is the human value behind the technical work: giving someone room to do the work they wanted to do in the first place.
The same standard should apply to your product. If you remove an hour of effort but create an hour of checking and correcting somewhere else, the customer may never feel the gain you put on your slide.
For a reliability product, that means measuring the time it takes to reach a diagnosis the team can act on. A fast answer that still requires a room full of engineers to investigate it leaves much of the job unfinished.
The person handling the exceptions often has the clearest view of what the automation left unfinished.
Spend time with that person.
Try this in your next customer conversation:
1. Choose a workflow that is already getting faster. Find someone using AI in real work. Ask who handles the output and who owns the consequences when it goes wrong.
2. Reconstruct the last difficult case. Have that person walk you through an actual example. Record the tools, handoffs, waiting, investigation, and rework. Find where effort accumulates as volume increases.
3. Name the failing assumption. Write down what the existing solution expects a person to know or do. Test whether that expectation is still reasonable at the customer’s current scale.
4. Prove one complete outcome. Agree with the owner on a small pilot and a measure that includes the work of verifying and acting on your answer. Compare it with their current process. Then test whether they will pay to keep using it.
A growing bottleneck gives you a hypothesis. Product-market fit requires the customer’s behavior to confirm it.
Watch what happens after the demo: whether the product enters the workflow, removes effort across the whole job, and earns repeated use.
AI is making more things possible. It is also changing which things are difficult.
Pay attention to where that difficulty goes.
Your next market may be there.