Persistent Structural Memory for AI: The Architecture Behind Infigraph

June 28, 2026July 12, 2026Sandeep Mewara Leave a comment

In my previous article, I wrote about what I called Code Blindness – the hidden operational cost of forcing AI assistants to repeatedly rediscover the structure and architectural relationships that already exist inside our codebases.

https://learnbyinsight.com/wp-content/uploads/2026/07/infigraph-blog-banner.png

Today’s coding assistants can inspect local files, trace explicit imports and painstakingly piece together relationships to answer familiar engineering questions:

– Who calls this function?
– What breaks if I alter this API route?
– Which services depend on this component?
– What is the true blast radius of this change?

These aren’t difficult questions because the code is hard to read. They’re difficult because the relationships that answer them aren’t explicitly available. Every new AI session reconstructs them from source code, only to discard that understanding when the conversation ends.

That observation eventually led us to build Infigraph – an attempt to turn software structure into reusable, local infrastructure.

When we recently open-sourced the project, one question came up repeatedly:

“What makes Infigraph different from the other code intelligence and code graph projects already out there?”

It’s a fair question.

The ecosystem already has tools for code search, static analysis, architecture visualization and AI-assisted development. Some focus on helping engineers navigate code. Others generate knowledge graphs for LLMs, visualize architecture or build richer retrieval pipelines.

We weren’t trying to build another code intelligence tool.

We were trying to build a local-first, persistent structural memory layer that AI assistants could query directly instead of repeatedly reconstructing software relationships from source code.

That objective influenced nearly every architectural decision we made – from how code is parsed, to how relationships are extracted and stored, to how AI agents retrieve information.

Looking back, those decisions weren’t independent optimizations. They were consequences of a single design principle:

If software structure changes far more slowly than AI conversations, then structural knowledge should be treated as infrastructure and not something rebuilt from scratch for every prompt.

This article walks through the engineering decisions that followed from that principle, the tradeoffs we accepted and the lessons we learned while building Infigraph.

The System Blueprint

Before discussing the individual architectural decisions, it’s worth understanding how the pieces fit together. At a high level, Infigraph continuously transforms a codebase into a persistent structural representation that AI assistants can query directly. Instead of rediscovering relationships for every conversation, those relationships become shared infrastructure.

https://learnbyinsight.com/wp-content/uploads/2026/07/infigraph-architecture-overview.png

The graph doesn’t replace the language model. It changes the question the language model has to answer. Rather than treating every prompt as an isolated reasoning exercise, Infigraph treats structural understanding as persistent infrastructure.

The important observation isn’t the individual technologies. It’s where the computational effort moves.

Traditional AI workflows spend most of their effort reconstructing architecture from source code every time a question is asked. Infigraph moves that work to indexing time. Parsing source code, resolving symbols, understanding imports and discovering relationships happen once – when the repository is indexed. Every subsequent question becomes a retrieval problem instead of a reconstruction problem.

https://learnbyinsight.com/wp-content/uploads/2026/07/infigraph-workflow.png

That architectural shift immediately imposed a new set of engineering requirements. We needed:

A storage engine optimized for relationship traversal rather than document retrieval
A retrieval layer that could combine graph queries with traditional search
A parsing architecture capable of understanding modern polyglot codebases without becoming language-specific

The next three sections explain how those requirements shaped Infigraph’s architecture.

Decision #1: Represent Code as a Persistent Graph

The first architectural decision was to decide how software itself should be represented.

A software system isn’t just a collection of source files. It’s a network of explicit relationships. A function call is an explicit relationship. An import statement expresses a dependency. A class hierarchy defines inheritance. Module boundaries already exist whether an AI model discovers them or not. We needed a statically discoverable representation where relationships were first-class citizens.

That naturally led us to a graph.

Instead of storing source files as isolated text, Infigraph persists a connected topology of software entities and the relationships between them.

https://learnbyinsight.com/wp-content/uploads/2026/07/infigraph-graph-setup.png

Once relationships become explicit, architectural questions stop being text-search problems. Familiar engineering questions become a graph traversal. The system isn’t reading raw source code inside an LLM reasoning loop to find callers. It is traversing an index that already knows they exist.

Once we committed to representing software as a graph, the next question became much more practical:

What kind of graph engine could support interactive AI workflows without becoming another server-side dependency?

That question shaped our next architectural decision.

Decision #2: Persist Structural Memory Locally

We could have stored the graph in a traditional client-server database. We could have relied on a managed graph service. Or we could have generated structural context on demand through cloud-hosted retrieval pipelines.

All of those approaches work.

But they conflicted with one of our architectural constraints from the very beginning:

Structural knowledge should live alongside the repository, not behind another network boundary.

That single constraint influenced far more than our storage engine. It shaped the entire architecture.

If AI assistants increasingly become part of the developer’s inner loop, structural knowledge should be available with the same characteristics developers already expect from their source code:

local
immediately accessible
private
independent of cloud connectivity

That immediately narrowed our design space. We needed a graph engine that was:

embedded rather than server-based
lightweight enough to ship with the developer environment
optimized for large relationship traversals
capable of answering structural queries within an interactive AI workflow

That led us to KuzuDB , an embedded, columnar graph database designed around analytical graph workloads rather than transactional business operations. The workload wasn’t updating records, it was traversing relationships. A columnar storage engine aligns well with that access pattern because it can efficiently scan relationship data without repeatedly loading complete records.

The architectural layout shift here is central to performance. The difference isn’t the graph model – it’s the storage layout:

https://learnbyinsight.com/wp-content/uploads/2026/07/infigraph-kuzu-db.png

Performance Benchmarking

When traversing deep, multi-hop dependency tracks across half a million nodes, we rarely need to unpack full, heavy row configurations. Benchmarks were run on representative repositories and consistently observed substantially lower traversal latency for deep dependency walks.

The important result wasn’t the absolute latency. It was that the storage layout aligned far better with the traversal-heavy workload of AI-assisted development.

https://learnbyinsight.com/wp-content/uploads/2026/07/infigraph-perf-kuzuDB.png

Like every architectural decision, it came with tradeoffs. KuzuDB is a younger ecosystem than some of the established graph platforms. We consciously traded ecosystem maturity for an embedded architecture that better matched the interaction model we were trying to enable. Looking back, that tradeoff shaped much more than storage. Once structural memory became local and inexpensive to traverse, the next challenge was no longer storage.

Decision #3: Retrieve Structural Context Before Reasoning

Persisting structural knowledge solved only half the problem. The remaining challenge was retrieving the right structural context quickly enough that an AI assistant never needed to fall back to reading large portions of the repository.

At first, it seemed tempting to rely on a single retrieval strategy. Keyword search is excellent when an engineer already knows the exact symbol they’re looking for. Semantic search is better when they describe an idea rather than an identifier. Graph traversal is indispensable when the question is fundamentally about relationships. But, none of these approaches is sufficient on its own.

Different questions require different retrieval strategies.

Instead of trying to force every question through a single search engine, Infigraph combines multiple retrieval mechanisms, each optimized for a different type of query.

https://learnbyinsight.com/wp-content/uploads/2026/07/infigraph-hybrid-retrieval.png

We built a local-first, parallel hybrid retrieval pipeline where each engine contributes a different signal:

BM25 (Exact Retrieval): Fast, deterministic lookup for symbols, filenames, identifiers and keywords
Semantic Retrieval (Model2Vec): A bundled 29 MB embedding model retrieves conceptually similar code without relying on external embedding APIs
Regex Retrieval: Captures explicit syntactic conventions, decorators, annotations and language-specific patterns that keyword and semantic search may overlook

Once these candidate starting points are identified, Graph Traversal takes over. The retrieval layer expands those candidate matches into architectural context.

If retrieval is part of the developer’s inner loop, it should remain just as local and self-contained as the graph itself. That led us to build the entire retrieval pipeline including keyword indexes and semantic embeddings to execute locally without depending on external services.

The goal wasn’t simply lower latency. It was to ensure that structural understanding remained available regardless of network connectivity, while keeping source code inside the developer’s environment. The retrieval layer shouldn’t decide what the model thinks. It should decide what the model needs to think about.

Making Structural Memory Consumable

Building a retrieval pipeline solves only part of the problem. The other half is exposing that structural knowledge in a way AI assistants can consume naturally. Rather than embedding graph traversal logic into individual coding assistants, Infigraph exposes focused capabilities – symbol lookup, dependency traversal, call graph exploration and structural search – through the Model Context Protocol (MCP).

That separation was intentional.

The graph remains the system of record. MCP becomes the interface through which AI assistants access that knowledge. Whether the client is Claude Code, Cursor, GitHub Copilot, Windsurf or another MCP-compatible tool, they all interact with the same persistent structural memory instead of rebuilding it independently.

This reinforces the same architectural principle that shaped the rest of Infigraph:

Structural knowledge should be shared infrastructure. MCP simply makes that infrastructure accessible.

The final challenge was making that extraction scale across the reality of modern polyglot systems.

Decision #4: Decouple Structural Extraction from Language

Very few systems live entirely within a single language. A typical request may begin in a TypeScript frontend, flow through a Java service, invoke a Python-based machine learning component and finally interact with SQL or infrastructure configuration. Supporting that reality required more than adding parsers. It required separating the extraction engine from language-specific syntax.

That became our final architectural decision:

The extraction pipeline should remain stable as language support grows.

Instead of writing language-specific logic inside the core engine, Infigraph separates parsing from extraction.

https://learnbyinsight.com/wp-content/uploads/2026/07/infigraph-multi-lang.png

To support both mainstream languages and enterprise-specific grammars, we built a dual-extraction architecture:

For mainstream languages, we rely on Tree-sitter grammars and declarative queries to identify structural entities such as symbols, imports, calls and inheritance.
For proprietary languages, internal DSLs or environments where Tree-sitter isn’t the right fit, Infigraph provides an ANTLR-based extension path. New grammars can be added without modifying the extraction engine itself.

That separation turned out to be more valuable than we initially expected.

Once parsing produces a common structural representation, everything else in the architecture remains unchanged. Every additional language increases the capability of the platform without increasing the complexity of its core.

Today, that approach allows Infigraph to support 62 languages out of the box while remaining extensible for environments that need more. Persistent structural memory shouldn’t become more complicated every time your software ecosystem grows. By separating extraction from language, we made language diversity an extension point instead of an architectural constraint.

The Landscape: Where Infigraph Fits

Most code intelligence platforms are ultimately designed around one of two consumers:

Humans, who need to search, visualize, analyze or understand software systems.
Analysis engines, which evaluate code for correctness, security, compliance or quality.

Our primary consumer is different. It’s an AI assistant operating inside a developer’s editing loop.

Projects such as SciTools Understand, Sourcegraph, Joern and newer AI-native graph initiatives have each pushed the ecosystem forward in different ways. Many engineers already rely on them successfully.

Our goal wasn’t to replace those tools. It was to optimize for a different execution model.

The architectural differences become clearer when viewed through the problems each category was designed to solve. The differences aren’t primarily about features. They’re about architectural optimization. Each category solves a different problem and therefore makes different tradeoffs.

Dimension	Human-Centric Platforms	AI Knowledge Builders	Infigraph
Typical Examples	SciTools Understand, Sourcegraph, Joern	Understand-Anything, Graphiti, Nomik and similar projects	Infigraph
Primary Consumer	Engineers & Architects	AI knowledge generation workflows	AI coding assistants
Structural Extraction	Parser / index-based	Often combines parsing with LLM summarization	Deterministic parser-based extraction
Deployment Model	Desktop or centralized infrastructure	Frequently cloud-assisted	Local-first embedded infrastructure
Primary Interaction	Search, navigation, visualization	Repository understanding and documentation	Real-time MCP tool calls
Optimization Target	Human understanding	AI-generated repository knowledge	Persistent structural memory for AI

These categories aren’t mutually exclusive. In many organizations they complement one another. The difference lies in which problem each one is optimized to solve. This distinction matters because our optimization target was fundamentally different.

We weren’t building another interface for engineers to explore repositories OR building another cloud pipeline that asks an external LLM to understand a repository before a developer can ask a question.

We were trying to answer a much narrower architectural question:

How do we make structural knowledge continuously available to AI assistants without paying to rediscover it every conversation?

That single question explains almost every architectural decision described in this article.

Represent software as a persistent graph
Persist structural memory locally
Retrieve structural context instead of raw files
Expose that knowledge through MCP
Keep extraction extensible across languages

Everything else follows from that design center.

Choose Infigraph when…

Your primary development workflow revolves around AI coding assistants, such as Claude Code, Cursor, GitHub Copilot, etc
Your agents repeatedly ask structural questions about callers, dependencies, ownership or impact analysis
You want local-first execution without repeatedly sending repository context to external services
You want persistent structural context that survives beyond individual AI conversations

Continue using existing tools when…

Your primary need is enterprise-scale code search
You’re performing security or compliance analysis
You need architecture visualization or reverse engineering for human exploration

Instead of asking the AI to reconstruct relationships every session, Infigraph provides them as persistent structural memory that can be queried locally in milliseconds.

Our goal isn’t to replace the existing code intelligence ecosystem. It’s to become the lightweight local-first, structural memory layer that complements it for AI-native software development.

Looking Ahead

I don’t think Infigraph is the final answer to AI-native software development. In fact, I suspect we’re only beginning to define what this architecture layer should become.

Today, persistent structural memory captures relationships between software entities. Tomorrow, it may also incorporate architectural evolution, ownership boundaries, runtime behavior, operational telemetry, organizational knowledge and historical change patterns.

The better AI becomes at generating code, the more important these structural layers become. Generated code is only valuable if it fits coherently inside the system around it. I believe our responsibility is gradually shifting toward building better representations of the systems AI increasingly helps us evolve.

That’s ultimately why we open-sourced Infigraph .

Not because we think we’ve solved the problem, but because we believe persistent structural memory is an architectural direction worth exploring together.

If this way of thinking resonates with you, I’d encourage you to try Infigraph against your own repositories, challenge the assumptions we’ve made and contribute where you think the architecture can be improved.

We’re still learning.

Hopefully, we’ll learn together.

. Sandeep Mewara Github
Tech Explore
Trend
Learn Machine Learning with Examples
Machine Learning workflow

https://learnbyinsight.com/wp-content/uploads/2026/07/infigraph-vertical-light.png

GitHub : https://github.com/intuit/infigraph
Documentation : Detailed design specs and contribution guidelines are included in the repo.

Agentic Development: From Divergence to a Self-Evolving Platform

June 21, 2026June 21, 2026Sandeep Mewara Leave a comment

In my previous article, I shared a perspective that divergence is a natural and often necessary phase of agentic development adoption. As organizations move from a handful of alpha teams toward broader adoption, multiple implementations like PDLC orchestrators, agent workflows and skills naturally emerge.

The challenge is not divergence.

The challenge is ensuring that divergence eventually compounds into reusable organizational capability rather than permanent fragmentation. The next logical question becomes:

How do we converge without losing the innovation, learning and investment accumulated during exploration?
More importantly, how do we unify architecture without selecting arbitrary winners and forcing teams to discard everything they have built?

This article proposes a practical strategy that treats early duplication not as architectural waste, but as a high-value parallel testing playground. It maps out the transformation from Managed Divergence to an Overrideable Platform Baseline, offering an operational roadmap, clear component definitions, code blueprints and a self-evolving governance model designed to scale AI execution safely across the enterprise.

The intent is not to prescribe a single path. It is to share one possible blueprint based on observation, experimentation and lessons learned while navigating agentic adoption.

1. The Core Principle: Converge Capabilities

Successful architecture convergence follows an advanced strategy where instead of crowning individual team’s codebase as “standard”, it asks a far more valuable question: Which specific capabilities have consistently delivered production value across our teams?

This subtle shift changes everything. Instead of comparing entire software implementations as rigid and monolithic blocks, we break them down to harvest their underlying functional components:

Requirements Analysis & Guardrailing
Automated Architecture Review Loops
Distributed Traceability & Prompt Diagnostics
Human-in-the-Loop Approval Gates
Context Management & Core Memory Primitives

The goal is not to converge implementations but capabilities.

Standard vs. Baseline

This distinction becomes critical to our engineering culture.

A Standard says: Everyone must use this.
A Baseline says: Everyone starts here unless they have a compelling reason not to.

Standards optimize for control, while baselines optimize for adoption. In fast-moving domains such as agentic development, baselines tend to age much better than mandates.

The baseline should provide shared governance, shared infrastructure, shared orchestration and shared capabilities, while still allowing product-specific workflows, domain-specific skills, specialized agents and contextual optimizations.

Convergence Readiness Signals

We look for specific architectural markers to know when an engineering organization is ready to move into a baseline:

Signal	Meaning
Multiple teams solving the same problem	Candidate for convergence
Repeated primitives emerging	Baseline opportunity
New adopters unsure where to start	Discovery problem
Maintenance burden increasing	Consolidation opportunity
Overrides becoming common	Promote capability evaluation

2. The Platform Evolution View

The platform should continuously absorb innovation rather than requiring periodic reinvention. To track this loop, we map the entire platform evolution path in one comprehensive architectural view:

This structural flow establishes a permanent, virtuous evolution loop across our active software engineering ecosystem.

By implementing this transition blueprint, we do not ask teams to throw away their clones. Instead, we catalog what they built, harvest repeated capabilities, engineer reusable core components and let teams adopt the baseline progressively.

3. The Two-Track Convergence Model

Convergence should happen through two coordinated, pipelined tracks. At the organizational level, these tracks run in parallel to maintain velocity. At the component level, they operate sequentially, ensuring that technical construction is always guided by harvested organizational data.

We run Track A (Knowledge Convergence) to harvest organizational data alongside Track B (Technical Convergence) to engineer the reusable execution environment. As soon as Track A distills early patterns (like standard telemetry schemas), Track B immediately begins platform construction on those components while Track A moves ahead to discover more complex primitives.

4. The Target Reference Architecture

Once structural patterns become visible, we construct a reusable platform baseline. I believe a Core + Hook architecture provides the right balance between consistency and flexibility. It offers unified enterprise boundaries while providing localized teams complete room to execute custom intelligence loops.

Layers Deep-Dive

Knowledge & Context Layer: Holds trusted organizational knowledge (ADRs, Standards, APIs, Design Systems) that acts as the ultimate source of truth, thus helping agents to not experience semantic drift. For example, an Architecture Agent retrieves existing architecture decisions and approved patterns before generating recommendations.
Platform Contracts Interface Layer: The missing enabler that defines standard interfaces between governance and execution components. Standardized schemas enable convergence while keeping the platform baseline implementation-agnostic.
Skills & Tools Layer: Supplies the shared, stateless action utilities that agents ingest natively. While short-term memory retrieval policies can be altered at the override layer, the underlying database connection pooling, key-value serialization and caching infrastructure reside permanently here. The principal guideline: Agents consume skills; agents do not rebuild skills.
Agent Capabilities Layer: Houses standardized, virtual organizational personas that model common roles. For example, Requirements Agent converts business requests into structured requirements. Architecture Agent turns requirements into architecture proposals. QA Agent converts implementation plans into test strategies.
Baseline Orchestration Layer: Defines the default, customizable, cross-cutting multi-stage lifecycle flow (Requirements → Planning → Architecture Review → Implementation → Testing → Release Readiness). Traceability, HITL gates and security checks remain mandatory, while sequence and domain reviews are overrideable.
Override & Extension Layer: Preserves rapid innovation directly at the product edge. Squads inject custom business logic (e.g. Healthcare Compliance Agents, Tax Validation Agents) while keeping the core platform baseline stable.
Registry & Discovery Layer: Makes reusability easier. It continuously indexes and exposes real-time ownership, quality metrics and metadata context for all active agents, skills, workflows and patterns.
Experience & Adoption Layer: Makes adoption easier than unmanaged divergence. It contains starter kits, documentation templates and migration guides.

Cross Cutting Verticals

Governance & Control Plane Layer: The silent operational engine running underneath all execution steps. It enforces non-negotiable enterprise requirements – such as real-time PII data masking, automated token rate-limiting and immutable audit logs.
Evaluation Plane Layer: The objective, metrics-driven testing environment. It relies on standard benchmarks, regression runners and corporate golden datasets to continuously measure agent quality, runtime cost and latency profiles. It is also responsible for determining whether localized overrides should remain product-specific or be promoted into the platform baseline. This ensures the platform continuously learns from future divergence rather than treating it as technical debt.

5. The Transition Architecture

The layered reference architecture describes our target destination. The missing operational bridge is: How do we transform existing, divergent implementations into structured, reusable platform assets?

This is where Capability Mapping and Core Component Engineering come together.

We systematically catalog what product squads built, extract the underlying functional features and engineer them into decoupled platform primitives.

The Component Classification Model

To create a frictionless, predictable path from localized experimentation to enterprise-wide reuse, every discovered capability is classified into one of five structural component types in the plaform engine:

Component Type	Real-World Example	Target Placement Slot
Contract	Standard Trace Schema, Unified HITL Payloads, Input/Output Boundaries	Platform Contracts / Governance Interface Plane
Platform Service	Centralized OpenTelemetry Engines, Token Cost Budgeting, Security Sanitizers (PII Redaction)	Control Plane / Shared Operational Primitives
Skill	Semantic Vector Search, Document Extraction APIs, Active Cache Primitives	Reusable Skills Layer
Agent	Automated Architecture Compliance Reviewers, Virtual PMs, Testing Primitives	Reusable Agent Layer
Workflow	Default multi-stage PDLC Orchestration Flow, Agent-to-Agent Critique Loops	Baseline Orchestration Layer

This mapping creates a direct path from experimentation to reuse, changing the migration conversation from a compliance chore to an evolutionary contribution.

6. Core Runtime Platform

The Common Core Runtime is owned, versioned and centrally governed by the platform team. It abstracts away standard non-functional requirements (NFRs) and cross-cutting platform concerns, ensuring they are never rebuilt by individual product teams:

Core Capability	Platform Examples
Security	PII Masking, Prompt Injection Detection, Compliance Enforcement
Reliability	Retry Logic, Circuit Breakers, Fallback Models
Cost Controls	Token Budgets, Usage Quotas, Model Throttling
Observability	Logs, Traces, Metrics

Individual product teams interface with this core natively through a decoupled Lifecycle Hook Registry. The registry acts as our primary stitching layer:

The design boundary is explicit: The platform owns lifecycle management, while local product teams inject contextual intelligence.

7. The Enterprise Repository Blueprint

To ground this architecture in production reality, the entire ecosystem is organized into a single, unified repository structure. This layout provides an explicit separation between our core platform governance, reusable inner-source capabilities and localized product extension:

To complement the architecture and operating model described here, I have also created a companion repository that translates these concepts into a concrete implementation structure. It includes a reference layout. My hope is that it helps make the ideas discussed in this article easier to visualize, evaluate and adapt within different organizational contexts.

Companion Repository: https://github.com/sandeep-mewara/agentic-platform

8. Ownership Model: The Core Matrix

To eliminate delivery ambiguity between centralized infrastructure squads and individual product feature teams, ownership across the platform layers is distributed cleanly:

Architectural Artifact / Layer	Primary Engineering Owner
Common Core Platform & Registry	Platform Team
Governance & Control Plane	Platform Team
Evaluation Plane	Platform Team + Architecture Council
Shared Skills Pool	Platform Team + Distributed Contributors (Inner-Source)
Shared Agent Personas	Dedicated Capability Owners (Specialized Feature Squads)
Product Overrides & Domain Logic	Individual Product Teams
Baseline Core Release Sign-Off	Architecture Council

9. The Progressive Adoption Runbook

Instead of launching a high-risk “big-bang migration” that stalls existing feature roadmaps, product teams adopt the baseline progressively using a step-by-step outside-in sequence:

Step 1: Keep local clones active. Do not freeze or disrupt active product delivery.
Step 2: Connect unified telemetry. Integrate the platform’s standardized logging and tracing hooks to get instant cost and visibility tracking.
Step 3: Offload foundational plumbing. Replace duplicate local code with common core platform services like PII sanitizers and token budgets.
Step 4: Swap out common skills. Deprecate redundant local utility code in favor of shared utilities from the Inner Commons repository.
Step 5: Migrate the core orchestrator. Hot-swap the custom local execution loop for the official ConvergedAgentOrchestrator base engine.
Step 6: Register unique overrides. Protect remaining specialized behavioral prompts and domain-specific tools by preserving them cleanly inside the platform hook registry.

10. Common Failure Modes to Monitor

When executing a convergence strategy, architectural roadblocks are rarely purely technical. They are usually cultural and operational. Watch for these critical organizational anti-patterns:

Converging implementations instead of capabilities: Trying to force everyone onto a single team’s codebase instead of extracting core features.
Selecting architectural winners too early: Enforcing standardization before running an audit track, destroying valuable edge-case engineering.
Creating rigid standards instead of flexible baselines: Building rigid mandates that force teams to bypass the platform entirely to ship specialized capabilities on time.
Omitting critical extension hooks: Designing a centralized orchestration engine that lacks an open, extensible Lifecycle Hook Registry.
Operating without an evaluation mechanism: Making architectural decisions based on subjective opinion rather than objective benchmarks and golden datasets.
Treating convergence as a forced migration exercise: Framing the entire platform shift as a compliance checkbox for engineering teams.

Final Thoughts

One vital lesson I continue to learn through agentic adoption is this:

Convergence is not the opposite of divergence. Done correctly, convergence is built on top of divergence.

The experimentation, duplication and architectural variation that feel messy in the moment contain the exact technical insights required to build a stronger foundation. The goal should not be to eliminate divergence as quickly as possible. The goal is to learn from it intentionally enough that convergence becomes the natural, frictionless next step for your engineering culture.

Furthermore, the platform should be designed so that future divergence can be harvested, evaluated and promoted back into the baseline over time – transforming your core infrastructure into an evolving, learning system.

Enable divergence. Harvest learning. Build a baseline. Preserve flexibility. Evolve continuously.

. Sandeep Mewara Github
Tech Explore
Trend
samples GitHub Profile Readme
Machine Learning workflow

The Hidden Cost of Code Blindness in the Age of AI

June 14, 2026June 14, 2026Sandeep Mewara Leave a comment

Last month, I was looking over the shoulder of one of our engineers as they worked with an AI coding assistant. They asked a question that should have been entirely straightforward: “Who calls the validate_user function in our codebase?” The answer eventually came back. But watching them get there required a familiar and surprisingly expensive loop: reading multiple files, tracing imports, reconstructing call paths and inferring relationships that already existed inside the system.

As we stood there brainstorming around their screen, a realization struck us. What broke the workflow wasn’t the token count. It was the repetition. If anyone on the team opened a new session tomorrow and asked the exact same question, the model would perform much of the same work all over again. The relationship hadn’t changed. The code hadn’t changed. Only the cost and our collective time had.

The Cost of Rediscovery

That moment exposed a fundamental flaw in how we approach AI-assisted development. The problem isn’t that AI is inherently expensive. The problem is that AI keeps paying a premium to repeatedly rediscover the same foundational knowledge. What looks like a token limitation is actually a structural understanding problem. And that’s ultimately why our engineering team set out to build Infigraph.

AI Has Context. It Doesn’t Have Structure.

The last few years have been dominated by a single, brute-force idea: give AI more context. Bigger context windows, more capable models, better reasoning and smarter agents. All of those advances matter. But many of the questions engineers ask every day aren’t really code-understanding questions. They are system-understanding questions.

Engineers ask questions like: Who calls this function? What breaks if I change this API? Which services depend on this component? What is the blast radius of this change?

These are not primarily language problems. They are relationship problems. They are graph problems. A model can read raw text files incredibly well, but what it lacks is a persistent understanding of the architecture that connects those files together. Software systems are not just collections of files, they are collections of relationships. The industry has spent years teaching machines how to read code, but we are only beginning to teach them how to understand systems.

The Economics of Reconstructing Knowledge

Every engineering organization already possesses a vast amount of implicit structural knowledge. The system already knows which modules depend on each other, which symbols are reachable, which services communicate and which changes create downstream impact. Yet, most AI workflows require that knowledge to be rediscovered from first principles, repeatedly.

When you ask who calls validate_user, the model reads files and reconstructs relationships. Open a new session tomorrow, ask the same question and the model performs much of the same work again. The relationship didn’t change, but the cost did.

We don’t rebuild database schemas every time a SQL query executes and we don’t rebuild search indexes every time a user types a keyword. We persist structure because persistence is more efficient than rediscovery. Software systems deserve the same treatment:

Persist the knowledge once. Query it many times.

The Shift I Think We’re Entering

I don’t pretend to have all the answers for how AI and complex architectures will evolve together. But as an architect looking at how our workflows are changing, I know where the responsibility is moving. Historically, our primary effort as developers was spent translating intent into syntax. Increasingly, AI handles that translation smoothly. As that happens, the bottleneck shifts away from writing code and toward understanding architecture, change impact, dependency boundaries and system behavior.

The better AI becomes at generating code, the more critical structural understanding becomes. Generated code is only an asset if it fits correctly inside the system around it. Otherwise, it’s just technical debt written at supersonic speed. We would never build an application that rediscovered its data schema for every transaction, yet that is effectively how many AI-assisted workflows approach codebases today.

Why We Built Infigraph

As we discussed this pattern internally, a simple question emerged: If structural knowledge is repeatedly rediscovered, why aren’t we persisting it? Instead of parsing relationships from raw source files every time a question is asked, what if those relationships were represented directly? What if structural understanding became infrastructure?

That idea became Infigraph. Infigraph creates a persistent representation of codebase structure that AI agents can query directly. Rather than repeatedly reading files to discover relationships, agents can ask questions about relationships that already exist. The goal was never to replace AI reasoning; the goal was to make AI contextually aware of the broader systems it operates within.

Same Question. Same Codebase. Different Architecture.

Three principles shaped our approach:

Structure First: Code contains explicit relationships. Those relationships deserve first-class, deterministic representation.
Local First: Code intelligence should be private, fast, and fully available even when disconnected from the cloud.
Polyglot Reality: Real systems span many languages, frameworks, technologies, and internal platforms. Infigraph currently supports 63 languages out of the box because the tool should adapt to your system—not the other way around.

The Byproducts of Structural Awareness

Cost is simply the easiest metric to measure, but it isn’t the most important outcome. The more important outcome is quality. When structural relationships are treated as a foundational layer, the system answers questions with greater consistency and more complete coverage than transient inference from raw files can reliably provide.

A cheaper answer is useful, but a more complete answer is transformative. Architects care about correctness, engineering leaders care about confidence and developers care about understanding impact before making a change. Structural awareness improves all three.

When we stopped asking, “How do we slash our token bill?” and started asking, “Why are we repeatedly paying to rediscover the same relationships?” the economics fell into place naturally. Fewer files needed to be pulled into context, tool call chains became shorter, latency dropped and cost followed. Cost savings are not the primary innovation but they are a consequence of eliminating redundant engineering work.

Why We Open-Sourced It

We originally built Infigraph to solve systemic problems inside our own development workflows. But as more engineers and teams began using it, we realized that this challenge isn’t unique to us. The entire industry is moving aggressively toward AI-assisted development while software systems continue growing larger and more interconnected.

Those two trends collide around a simple question: How do we help machines understand software systems, not just individual files? We know the current trajectory: repeatedly paying to rediscover knowledge that already exists within our own codebases. That model isn’t sustainable. We believe the next step deserves community participation, scrutiny and collective engineering.

That’s why we released Infigraph as an open-source project under the Apache 2.0 license. Not because we think it’s finished, but because we believe this is a direction worth building together.

What’s Next

This article focused on the core problem. The next article (in upcoming week) will focus entirely on the engineering decisions behind our approach from graph-based representations and retrieval strategies to the tradeoffs we encountered while building local-first code intelligence.

But you don’t have to wait for that deep dive to start exploring.

⭐ Star the repository on GitHub and follow the project.
👥 Assess, Contribute and raise PR.
🚀 Install it and try it now against your own codebase.

If you hit issues, open a GitHub issue. If you want to contribute, whether that’s a new language parser, search improvements or new MCP integrations, we’d love to collaborate.

Thanks for reading. And, a special thanks to the engineers on our team who transformed a whiteboard conversation into a tool we can now share with the broader community.

. Sandeep Mewara Github
Tech Explore
Trend
samples GitHub Profile Readme
Learn Machine Learning with Examples
Machine Learning workflow