How engineering intuition both powers and troubles your engineering teams

How engineering intuition both powers and troubles your engineering teams

Let’s explore a scenario that’s all too common for most engineers. You’re debugging an issue in production. The first thought hits you: "I don't know what the heck is going on". You're not alone. In most software engineering teams (especially during on-call incidents), this feeling of being lost in the darkness of unknown system behaviors is all too common. This challenge comes from not having access to your seasoned engineer’s "intuition" – the unwritten understanding of how your systems actually work. This engineering intuition is what enables seasoned engineers to navigate complex production incidents or tricky situations. However, when you are not able to access it on demand, it turns into a hidden anchor that subtly drags down your engineering team’s velocity.

What is this Engineering Intuition?

Engineering Intuition isn't just "stuff we haven’t written down" or simple recall. While built upon a memory (both explicit, documented knowledge and tacit, experience-based recollections), it goes beyond just information storage. It’s a dynamic capability including:

• Contextual understanding of your production system – the web of interdependencies, historical decisions, performance quirks, and architectural nuances that dictate how components genuinely respond under various conditions.
• Rapid pattern recognition (almost subconsciously) to identify subtle deviations from normal behaviours or correlations between disparate signals.
• Implicit “feel” beyond documented facts on how the system works. It’s fragile points, typical failure models, or which alarms are usually noise vs. genuinely critical
• Generating hypotheses about root causes, often short-circuiting lengthy troubleshooting by intuitively knowing where to look first or what to try next.

This "intuition" isn't confined to individual "star" engineers; it's an emergent property of the team's collective experience, embedded in past incident responses, subtle code comments, the “go-to” dashboards that really tell the story, and the shared memory of "that one time..."

What happens if you cannot access this Engineering Intuition?

The true cost of inaccessible engineering intuition isn't just inefficiency; it's a significant tax on your engineers' cognitive load, leading to anxiety, loss of trust, and slower incident response

High stakes scenarios like on call production incidents

If the critical context behind an incident (Ex: the subtle interplay between services) isn't readily available, engineers are thrown into a desperate search not knowing where to start.
My co-founder Mayank (Chief Technology Officer at Resolve AI) “During incidents, the major problem is your on-call engineer doesn’t know what questions to ask of the system or your colleagues. As a leader, you are constantly worried about losing institutional knowledge with the departure of your seasoned colleagues. It’s almost as if the team loses a part of “memory”, eventually making it harder for you to scale”.

This uncertainty is paralyzing. Engineers waste precious minutes, sometimes hours, "just trying to figure out" which service is the real culprit or if a proposed fix will trigger a catastrophic cascade. They might have a vague recollection of a similar issue, but the specifics are lost. Even after service restoration, recovery can be incomplete. Post-mortems might capture the "what," but often miss the crucial "why”, paving the way for such repeat incidents.

Unwanted grind during development

Beyond emergencies, this knowledge gap inflicts a daily tax. "Why was this built this way?" can turn into an archaeological expedition. Onboarding new engineers becomes a frustrating exercise in navigating invisible knowledge walls. Code changes made without understanding historical context or unwritten contracts are landmines waiting to detonate. As teams grow and scale, this problem compounds.

New engineers struggle to become productive, hitting invisible walls in what should be mundane activities like understanding deployment processes or service dependencies – things "everyone just knows". When you want to introduce a new approach, you face higher barriers as you fundamentally lose trust in the stability of your engineering infrastructure over time.

If this is such a big problem, why haven’t we fixed it already?

The typical responses to these challenges are often linear – hire more engineers, write more documentation, buy more tools. But, they don't address the fundamental issue of making contextual knowledge accessible and useful:

• Adding more people: While this instinctive reaction adds more capacity, it dilutes the collective understanding rather than strengthening it. Adding more people, especially those external to the core team's history, dramatically increases communication and coordination overhead. Instead of making intuition more accessible, you now have exacerbated the problem.
• Create more documentation/process: Documentation excels at capturing explicit facts, procedures, or the outcomes of past decisions (e.g., "we did X, and Y happened"). But the fundamental problem with intuition is that it cannot be documented. Furthermore, even if fragments of insight are captured, documentation rapidly becomes outdated, and the sheer volume makes finding relevant nuggets a significant toil.
• Buying more tools: More tools frequently mean more data silos and a greater burden on engineers to manually synthesize information. Intuition thrives on seeing the bigger picture and recognizing patterns across disparate signals. When each new tool presents another isolated view, engineers are forced to mentally piece together narratives from fragmented data streams.

This problem is only getting worse because AI is generating more code, more people add to the problem, more tools add to the problem all because you are under immense pressure to deliver

How can you build a reliable system that has the intuition of humans?

We need a new approach that is interconnected and can learn continuously without becoming a chore. This is where a combination of a knowledge graph and AI agents can help.
A knowledge graph can

• Access and connect a vast spectrum of information – explicit knowledge (runbooks, docs, alerts, logs, code metadata, deployment manifests) and infer relationships that reflect tacit knowledge (patterns in incident histories, common troubleshooting paths, hidden dependencies revealed through behavior)
• Model a multi-dimensional understanding of how services interact, how alerts correlate, how changes propagate, and what "normal" behavior looks like across different contexts – the very fabric of understanding that intuition navigates.
• Learn and improve continuously with every interaction. It can be an alert, deployment, incident, or even your troubleshooting patterns – both successful and failed ones. More than just storing data, it learns patterns.

The prospect of building such a complex graph can seem like an integration nightmare. This is particularly valuable for medium to large enterprises where knowledge graphs can have 50,000 nodes and 500,000 edges.

The biggest value of such a graph is not to create another dashboard to stare at. Instead, it is to offer ambient intelligence for your teams so that even new hires start operating like your seasoned engineers.
An AI agent, imbued with such a learning knowledge graph, can "carry that intuition" and provide opinionated guidance to engineering teams – augmenting them with timely and precise context. It can

• Instantly correlate seemingly unrelated alerts to pinpoint a common underlying cause.
• Suggest the most probable investigation paths during an incident based on past similar patterns.
• Provide critical context about a service before a risky change is made.

The goal is to drastically reduce the number of situations where your engineers feel stuck or lost, sifting through unknown data sources and recalling obscure details.

Engineering Intuition isn’t the enemy. It’s scarcity is

Engineering Intuition is the natural byproduct of smart people solving hard problems. The challenge is not that it exists. But that isn't accessible across the team. The cognitive load your engineers face is the bigger problem, and it's time we addressed it.

With the right combination of knowledge graphs and AI agents, we can create an environment where every engineer who wakes up at 3 AM, has the "memory" and insights of the entire team at their fingertips. This isn't just about MTTR; it's about reducing your engineers’ search for crucial information and making their experience of building software more joyful.

About Resolve AI

Resolve AI is the agentic AI company for software engineering founded by the co-creators of OpenTelemetry. By combining our deep expertise in building developer tools and observability with state-of-the-art agentic AI, our mission is to increase engineering velocity by transforming the way engineers build, deploy, and maintain real-world software systems.

Resolve AI autonomously troubleshoots and resolves production issues, freeing up engineers to focus on building. Our agentic AI understands your production environments, reasons like your seasoned engineers, and learns from every interaction to give your engineering teams decisive control over on-call incidents with autonomous investigations and clear resolution guidance.

With Resolve AI, customers like Datastax, Tubi, and Rappi, have increased engineering velocity and systems reliability by putting machines on-call for humans and letting engineers just code. Interested in learning more about our Agentic AI approach to production systems? Say hello.