By Arjun Mehta, Principal Engineer at Glue

I have been the engineer who discovers, mid-sprint, that a "simple" feature change requires modifying fourteen files across three services because of code dependencies nobody mapped. Code dependency analysis is the practice of understanding which parts of a software system rely on which other parts, and it is the single most neglected discipline in modern product development.

Most product teams have never seen a dependency map of their own system. Most engineering teams build them mentally, if at all, relying on tribal knowledge and institutional memory. The result is planning that ignores the most fundamental structural reality of software: everything is connected, and connections have consequences.

This post covers what code dependencies are, why they matter far beyond the engineering team, how to map them, and how dependency data transforms the way teams plan and build software.

At the simplest level, a code dependency is a relationship where one piece of code relies on another piece of code to function. If Module A calls a function in Module B, Module A depends on Module B. Change Module B, and Module A might break.

Dependencies exist at multiple levels.

File-level dependencies. File A imports File B. This is the most visible type of dependency and the one most tools can detect.

Package-level dependencies. Your application depends on third-party libraries and frameworks. These are tracked in package manifests (package.json, pom.xml, requirements.txt) but their transitive dependencies, the libraries your libraries depend on, create a tree that can run hundreds of levels deep.

Service-level dependencies. In microservice architectures, Service A calls Service B's API. These runtime dependencies are harder to trace from code alone because they often involve network calls, message queues, and configuration files rather than direct imports.

Schema-level dependencies. Multiple services or modules may read from or write to the same database tables. Changing a column in one table can break every module that queries it. These are among the most dangerous dependencies because they are invisible in the code itself, hiding in SQL queries and ORM mappings.

Implicit dependencies. The hardest to detect. Module A does not directly call Module B, but both depend on a shared configuration value, a file system path, or an environment variable. Change the config, and both break, even though they have no visible connection.

According to the Standish Group, 66% of software projects experience cost overruns. Hidden dependencies are a primary driver. When a team estimates a project without understanding the dependency chain, they are estimating a fraction of the actual work.

If you are a product manager reading this, you might be thinking: "Dependencies are an engineering concern. Why should I care?" You should care because dependencies determine your timelines, your risk exposure, and your roadmap feasibility.

Dependencies determine blast radius. When you ask "how hard is it to change the checkout flow?", the answer depends entirely on what the checkout flow is connected to. If it is a self-contained module with clean interfaces, changes are isolated. If it is tangled with the billing system, the inventory service, and the analytics pipeline, every change requires coordination across multiple teams.

Dependencies create hidden blockers. Two projects that look independent in Jira might touch the same shared service. When both teams modify that service simultaneously, they create merge conflicts, breaking changes, and coordination overhead that nobody planned for. Understanding which parts of the codebase are shared, and which projects overlap, is a planning function that most teams skip entirely.

Dependencies explain why estimates are wrong. The Jellyfish 2025 report found that developers spend 23% to 42% of their time on technical debt and maintenance. A significant portion of that time goes to managing dependencies: updating libraries, resolving version conflicts, and untangling modules that should have been separated years ago. When engineers estimate a feature, they often account for the direct work but not the dependency-related overhead.

For engineering leaders, dependency data is operational intelligence. It tells you where your system is fragile, where coordination costs are highest, and where architectural investment would have the most impact.

Dependencies are a leading indicator of technical debt. A module with many incoming dependencies (many other modules depend on it) is a bottleneck. If that module is also complex, poorly tested, or owned by a single engineer, it is a risk multiplier. Dependency analysis surfaces these risks before they become incidents.

Mapping dependencies is part science and part craft. The science is in the tools. The craft is in knowing which dependencies matter and how to present them to different audiences.

Automated code scanning. The first step is parsing the codebase and extracting import statements, function calls, API invocations, and database queries. Tools that perform this analysis include SonarQube (for quality-focused metrics), Sourcegraph (for code navigation), and Glue (for AI-powered dependency intelligence). The depth of the analysis varies. Some tools only detect direct imports. Others trace call paths through the entire execution chain.

Dependency graph visualization. Raw dependency data is overwhelming. A large codebase might have thousands of dependency relationships. Visualization tools that render these relationships as graphs, with filtering by module, team, or service, make the data usable. Look for the ability to ask "show me everything that depends on the payment module" rather than staring at a wall of edges and nodes.

Git history analysis. Code dependencies are static: they describe what the code looks like now. Git history adds a temporal dimension. Files that are frequently changed together (even if they do not have direct import relationships) often have implicit dependencies. Change coupling analysis reveals these hidden connections.

Runtime dependency tracing. For service-level dependencies, static code analysis is insufficient. Runtime tracing tools like Jaeger and Zipkin capture actual service-to-service calls in production. Combining static analysis with runtime data gives you the most complete dependency picture.

Manual enrichment. No tool catches everything. Team interviews, architecture reviews, and incident post-mortems surface dependencies that automated analysis misses. The senior engineer who knows that "if you change the user table, you also need to update the cache invalidation config" holds dependency knowledge that no parser will detect.

The goal is not a perfect map. The goal is a map that is good enough to improve planning decisions. Even a partial dependency picture is vastly better than the default, which is no dependency picture at all. For a deeper technical treatment, see our guide to code intelligence platforms.

Dependency data transforms planning in three specific ways.

Risk assessment before commitment. Before committing to a roadmap item, run its affected modules through the dependency map. How many other modules depend on the areas you are changing? Which teams own those dependent modules? What is the test coverage in the affected area? This analysis takes minutes with the right tool and prevents weeks of mid-sprint surprises.

Sequencing projects intelligently. When two roadmap items touch shared dependencies, you have three options: sequence them (do one first, then the other), coordinate them (both teams work together on the shared area), or isolate them (refactor the shared dependency first so both projects can proceed independently). Without dependency data, you discover the overlap mid-execution when all three options are more expensive.

Investment prioritization. Modules with many dependents and high complexity are the highest-value refactoring targets. Cleaning up a module that ten other modules depend on produces outsized returns. Cleaning up a module that nothing depends on produces no returns at all. Dependency data turns effort estimation from political negotiation into evidence-based analysis.

Glue surfaces dependency intelligence specifically for planning conversations. Instead of asking an engineer to trace call paths manually, you can ask "what depends on the user permissions module?" and get a comprehensive answer that includes affected services, file counts, and ownership information. This data feeds directly into sprint planning, roadmap decisions, and technical debt prioritization.

The teams that map their dependencies consistently are the teams that ship on time consistently. This is not a coincidence. Dependencies are the structural reality of software. Ignoring them does not make them go away. It just means you discover them at the worst possible moment: when the deadline is already at risk.

---

What is code dependency analysis?

Code dependency analysis is the practice of identifying and mapping which parts of a software system rely on which other parts. This includes file-level imports, function call paths, service-to-service API calls, shared database schemas, and implicit dependencies through shared configuration. The purpose is to understand how changes in one area of the codebase affect other areas, enabling better planning, risk assessment, and architectural decision-making.

Why do code dependencies matter for product planning?

Code dependencies determine the true scope and risk of any project. When multiple features or services depend on the same module, changes to that module require coordination across teams and carry higher risk of breaking other functionality. Without dependency mapping, product teams underestimate project complexity, miss cross-team coordination needs, and discover blockers during execution rather than planning. Dependency analysis is the difference between a roadmap based on assumptions and one based on system reality.

How do you visualize code dependencies?

Dependency visualization typically involves generating a graph where nodes represent code modules and edges represent dependency relationships. Effective visualization tools allow filtering by team, service, or module so you can focus on the relationships relevant to a specific project. Combining static code analysis (import statements, call paths) with git history analysis (files frequently changed together) and runtime tracing (service-to-service calls) produces the most complete picture. The goal is not to visualize everything at once but to answer specific questions like "what depends on this module?"

ChatGPT for Product Managers: What It Does, What It Misses, and What Comes Next

By Priya Shankar, Head of Product at Glue

Last year, I started using ChatGPT for product managers tasks that used to eat entire afternoons: drafting user stories, summarizing customer feedback, brainstorming feature names, structuring competitive analysis. It was genuinely useful. I cut my document drafting time in half. I got unstuck on positioning problems faster. I used it as a thinking partner when I did not have a colleague available to bounce ideas off of.

But three months in, I hit a wall. And the wall was the same one I had been hitting for years, long before AI entered the picture. ChatGPT could help me think about products in the abstract. It could not tell me anything about my product specifically, because it had never seen my codebase.

This post covers how product managers are actually using ChatGPT today, where it delivers real value, where the critical blind spot lies, and what the next generation of AI for product teams looks like.

Product managers have adopted ChatGPT faster than almost any other function. A 2024 survey from airfocus found that AI adoption among PMs is accelerating, with most using it for content generation and analysis tasks. The use cases fall into a few distinct categories.

Document drafting. PRDs, user stories, release notes, internal memos. ChatGPT is excellent at producing first drafts that capture structure and key points. You still need to edit for accuracy and specificity, but the time from blank page to working draft drops dramatically.

Customer feedback analysis. Paste in a batch of support tickets or NPS responses, and ChatGPT will identify themes, categorize sentiment, and surface patterns. It handles volume that would take a human analyst hours in a fraction of the time.

Competitive research. "Give me a comparison of Productboard and Aha! for mid-market SaaS companies." ChatGPT produces a reasonable overview using its training data. The output is a starting point, not a final analysis, but it accelerates the research process.

Brainstorming and ideation. When you are stuck on a naming convention, a pricing structure, or a feature prioritization framework, ChatGPT serves as an infinite brainstorming partner. It does not get tired, it does not judge your bad ideas, and it produces volume that helps you find the good ideas faster.

Communication polish. Stakeholder emails, exec summaries, board deck narratives. ChatGPT helps PMs communicate more clearly and concisely, especially for those who struggle with written communication or are writing in a non-native language.

For a comprehensive look at AI applications in the PM role, see our AI product management guide.

To be fair to ChatGPT, it does several things remarkably well for product managers.

It reduces time on low-value tasks. The PM role is full of tasks that are necessary but not high-value: formatting documents, writing repetitive updates, structuring information. ChatGPT handles these efficiently, freeing PMs to spend more time on customer conversations, strategic thinking, and cross-functional alignment.

It provides broad knowledge access. ChatGPT has been trained on an enormous corpus of product management content, business strategy, software development practices, and industry analysis. When you need general knowledge about a topic, it delivers well-structured, reasonably accurate information.

It serves as a sounding board. Product management is often a lonely role. You are the only PM on a team, making decisions with incomplete information. ChatGPT provides a dialogue partner for stress-testing ideas, exploring edge cases, and identifying blind spots in your thinking.

It accelerates learning. For new PMs or PMs moving into an unfamiliar domain, ChatGPT compresses the learning curve. "Explain how payment processing works" or "What does a typical SaaS pricing migration involve?" provides a foundation that used to require hours of reading or access to a patient colleague.

UXcam found that 52% of PM time is spent firefighting rather than strategic work. ChatGPT helps shift that ratio by handling routine tasks faster, creating more space for the strategic work that actually moves the product forward.

This is the part that matters most, and it is the part that most "AI for PMs" discussions skip entirely.

ChatGPT does not know your codebase. It has never seen your repository. It cannot tell you which features you have built, which modules depend on each other, where technical debt is concentrated, or how complex a proposed change actually is.

This means that every product-specific question gets a generic answer. Ask "how should I implement a referral program?" and you get a textbook response about referral program design. Ask "how should I implement a referral program in our system?" and ChatGPT cannot answer, because "our system" is a black box to it.

This is not a minor limitation. It is the fundamental constraint. Consider the most important questions a PM asks:

• "How complex is this feature?" ChatGPT cannot say, because it does not know your architecture.
• "What dependencies does this project have?" ChatGPT cannot identify them, because it has not parsed your code.
• "What features do we already have?" ChatGPT has no idea, because it has never analyzed your codebase.
• "Which files would need to change?" ChatGPT cannot tell you, because it has no access to your repository.

Airfocus and Gitnux found that 95% of PMs cannot read code. ChatGPT does not solve this problem. It gives PMs a better thinking partner, but it does not give them the codebase visibility they actually need.

The question of whether AI can replace product managers gets asked a lot. The answer is no, but the reason is instructive. AI cannot replace PMs because the PM role requires context that generic AI does not have. The PM needs to understand both the customer and the system. ChatGPT helps with the first. It cannot help with the second.

The next generation of AI for product managers is not a better chatbot. It is AI that has been connected to your actual codebase and can answer questions grounded in your system's reality.

Code-aware AI works differently from generic AI in three fundamental ways.

It answers questions about your system, not about systems in general. "How does our billing system work?" returns an answer that references your actual files, functions, and database schemas. Not a generic explanation of how billing systems typically work.

It provides effort context grounded in code. "What would be involved in adding a referral program?" returns the specific modules that would need to change, the dependencies involved, and the complexity indicators for each affected area. This is estimation support that generic AI cannot provide.

It surfaces what you did not know to ask. Generic AI answers questions. Code-aware AI also proactively surfaces information: knowledge concentration risks, technical debt in the critical path, features that overlap with a proposed project. It tells you what you need to know, not just what you ask.

Glue is built on this model. It connects to your Git repository, parses and indexes the entire codebase, builds a semantic understanding of your system, and then answers natural language questions grounded in that understanding. The difference between asking ChatGPT "how does billing work?" and asking Glue "how does billing work?" is the difference between a Wikipedia article and a guided tour of your actual building.

For a look at what a PM AI assistant in 2026 can actually do, the capabilities go well beyond document drafting. Feature discovery, competitive gap analysis against your own codebase, spec generation that references real architecture, and dependency mapping are all within reach when AI has access to the code.

This is not about replacing ChatGPT. It is about complementing it. ChatGPT remains excellent for general knowledge, document drafting, and brainstorming. Code-aware AI adds the system-specific intelligence that ChatGPT structurally cannot provide.

The PMs who will do the best work in the next few years are the ones who use both: generic AI for general tasks and code-aware AI for product-specific decisions. That combination closes the visibility gap that has defined the PM role for decades: the gap between knowing what customers want and understanding what the system can deliver.

---

How do product managers use ChatGPT?

Product managers use ChatGPT primarily for document drafting (PRDs, user stories, release notes), customer feedback analysis, competitive research, brainstorming, and communication polish. It excels at tasks that involve generating, structuring, or summarizing text based on general knowledge. The most common use case is reducing time spent on low-value documentation tasks, freeing PMs to focus on customer conversations and strategic decision-making.

What are the limitations of ChatGPT for product management?

The most significant limitation is that ChatGPT has no access to your codebase. It cannot tell you what features exist in your system, which modules depend on each other, how complex a proposed change is, or where technical debt is concentrated. Every product-specific question gets a generic answer because ChatGPT lacks the system context that product decisions require. It is excellent for general product management knowledge but cannot provide the codebase visibility that PMs need for accurate planning and estimation.

Is there an AI tool that understands my codebase?

Yes. AI codebase intelligence platforms like Glue connect to your Git repository, parse the entire codebase, and answer natural language questions grounded in your actual system. Unlike ChatGPT, these tools can identify which features exist, map dependencies between modules, surface technical debt, and provide effort context for proposed changes. They are designed for the questions that generic AI cannot answer because those questions require knowledge of your specific codebase.