Interview with Dmitry Kostyuk, lead frontend developer and creator of the GraphLens extension for VS Code, a tool that fundamentally changes how developers work with AI-generated and complex code in Angular projects
The topic of this conversation is an industry innovation that visualizes Angular project architecture and helps reduce cognitive load: a tool that builds interactive architecture graphs directly in the editor, without manual exploration by developers. In 2026, development tools are becoming "intelligent partners" for programmers: IDE extensions and AI-powered tools help navigate code faster and increase team productivity. According to research compiled by Index.dev, around 84% of developers use or plan to use AI tools in their workflows, and AI-generated code now accounts for about 41% of code written in 2025. Against this backdrop, the GraphLens project stands out thanks to its unique approach to visualizing and navigating existing and often AI-generated codebases—a VS Code extension for Angular created by Dmitry Kostyuk, a lead frontend developer with over 10 years of experience in IT, Web development, and teaching. Dmitry started with satellite communication system modeling in MATLAB/Simulink, at North Caucasus Federal University, one of Russia's leading universities, taught Web development at STEP/TOP Academy, a large international IT academy with branches in over 20 countries, and developed commercial projects in travel and e-commerce before focusing on Angular and creating GraphLens—a tool that maps out project architecture visually and significantly simplifies working with complex, multi-layered code. It is precisely this ability to quickly build a "map" of the project and reduce onboarding time for unfamiliar or AI-generated code that sets GraphLens apart from the broader wave of AI tools focused on generating new code. Dmitry shared how research on program entities formed the foundation of GraphLens, what technical and architectural challenges had to be overcome, how the tool reduces cognitive load and increases team efficiency, and his experience in choosing a closed product model with patent protection.
"To make changes to the project, you need to understand code and relationships between components, services, modules, directives, and other Angular entities, which are often not obvious and hidden behind several editor actions."
Why did you decide to create GraphLens? What problems did Angular developers face that you encountered personally or observed in the industry?
Angular developers constantly deal with one practical feature of this framework—the need to work with a large number of files, which are the building blocks of the project and are interconnected. To make changes to the project, you need to understand code and relationships between components, services, modules, directives, and other Angular entities, which are often not obvious and hidden behind several editor actions.
For example, to accurately identify the parent component for the current one, you need to search for its references, find the standalone component that imports it, and then check the template for a selector or other connection method. Even a verbal description of this process seems overloaded—in practice, it's even more complex.
The situation is further complicated by the fact that Angular, starting from version 14, introduced the Standalone API, which simplified project architecture, but in the old NgModule architecture, relationships between components are even more complex and less transparent. And it is still widely used, more than three years after version 14 was released.
In large Angular projects, mainly in enterprise development, the number of components can reach hundreds or thousands.
And what does this mean for developers?
Obviously, manually reconstructing these relationships reduces overall development efficiency and increases cognitive load for developers, which is detrimental to both teams and companies.
I regularly encountered this in commercial development as a team lead, lead developer, and during code reviews. That's why GraphLens was created to address these practical needs and improve the quality and efficiency of Angular development. And it's important to understand that components are only part of the picture: Angular has other building blocks that GraphLens also has to work with.
Your project relies on several scientific publications, in particular, a whole series of five articles. These works describe the classification of Angular entities, the parsing methodology, and dependency analysis algorithms. How did research on program entities and their relationships influence GraphLens architecture?
Yes, GraphLens is largely based on the theoretical foundation developed in my series of scientific publications. They focus on the classification of program entities—the building blocks of Angular—and on describing the methodology and implementation of the main research algorithms.
One dependency-tree traversal method is based on the classic breadth-first search (BFS), a widely known and thoroughly documented algorithm. Thus, the project relies on both my own research and established scientific heritage, which is characteristic of most modern engineering solutions.
These algorithms underpin source code parsing and cyclic dependency analysis between program entities. As a result, they are linked into data structures—graphs, where nodes represent entities and edges represent their relationships. The name GraphLens comes precisely from these graphs, which are the final form of the extension's output.
"When the program performs the structural analysis from scratch rather than a human, it substantially reduces cognitive load."
What technical or architectural challenges did you overcome when creating GraphLens? What was the most difficult part in visualizing multi-layered Angular projects?
There were indeed many challenges. There is a well-known idea that building a prototype is much easier than bringing a product to a state suitable for mass use. This idea easily applies to tools that must work correctly across a wide range of Angular projects, structures, and patterns.
The most difficult part was finding and implementing universal solutions to handle multiple architectural approaches and structures in the source code. It was important to find solutions that were sufficiently performant while covering as many real-world cases as possible without venturing into rare or overly complex scenarios.
Otherwise, GraphLens development would have stretched indefinitely. Ultimately, as with many engineering projects, balancing incremental feature development with release timelines is essential.
Among the practical results, one example stands out: GraphLens "discovers" old, long-forgotten components buried deep in the architecture and displays them on the graph. What exactly makes these kinds of improvements possible? And in general, how does visualizing project architecture reduce developers' cognitive load?
Visualizing the architecture gives you a ready-made result that the developer would otherwise have to construct manually and keep in mind. Understanding the project's architecture and business logic is a basic requirement for making any code changes—the foundation on which the entire industry relies. When the program performs the structural analysis from scratch rather than a human, it substantially reduces cognitive load.
The improvement you mentioned, for instance, is achieved precisely through automatic dependency graph construction and instant navigation to any entity. This lets developers always keep the real state of the codebase in view and navigate the project much more effectively. In some companies, they still allocate up to a full week just for initial project familiarization and onboarding. GraphLens can shorten and simplify that process down to one day—or even less.
"The Angular community's response has been very positive."
Despite being a very young tool, GraphLens has already attracted serious attention from the Angular community. The very first post in r/angular received over 200 upvotes and more than 180 shares, placing it among the top eight most popular posts of all time in the subreddit. What are the development plans for a project with such promising potential?
It's still too early to talk about large-scale adoption cases. At this stage, we are actively collecting practical examples where the tool has genuinely accelerated teamwork or made code navigation easier. As you pointed out, GraphLens is a young tool and not every type of project is handled perfectly yet. There is an official Roadmap designed to elevate GraphLens to a mature, enterprise-grade product.
I'm confident that as the functionality grows, those real success stories will start appearing. Even at this early stage, the ~65–70% acquisition rate in the Marketplace and the steady stream of feature requests from the community are clear signs that the tool is addressing a genuine pain point.
How has the professional community—VS Code Marketplace, Reddit, GitHub—reacted to GraphLens? Were there unexpected comments or ideas that influenced further development?
The response was very positive. Developers left dozens of comments with gratitude and feature requests. Some of these ideas have already been implemented—for example, identifying and visualizing component projections.
There are currently around 1,400 downloads across the VS Code Marketplace and other platforms, and two positive reviews with a rating of 5. The acquisition rate is about 65–70%, significantly higher than the average 15–20%. This confirms that the tool genuinely addresses developers' needs.
The GitHub repository contains documentation, licensing, release history, a roadmap, along with dedicated forms for bug reports and feature requests. Currently, the repository has 29 stars and is actively used to discuss further project development. This focused engagement provides vital validation, reflecting the professional community's recognition of the project's value.
"The main thing is to see the need and offer a solution."
GraphLens focuses on Angular, one of the top frameworks. How do you see such tools affecting the Web industry as a whole?
Any easy-to-use tools that solve real developer needs positively impact the entire ecosystem: increasing efficiency, productivity, and development profitability. The key is to identify a need and provide a fitting solution.
Angular is one of the most complex frameworks, but far from the only one. In other frameworks, libraries, and languages, the situation is similar: there is code, building blocks are formed from it, they are interconnected, and there is a consistent need for a visual map of project architecture.
The challenge is to implement this as a convenient, performant, and genuinely useful tool—either better than existing solutions or in a fundamentally new way.
You have taught over 35 student groups and conducted thousands of code reviews. How did your teaching experience help in designing GraphLens?
Conducting code reviews helped me clearly see the limitations and difficulties faced first by students and then by professional developers. This experience directly indicated which problems should be addressed first.
"Behind the text code, there are complex relationships that can be visualized."
Your path began with MATLAB/Simulink and satellite communication systems. Which skills from scientific engineering work proved most useful for Web development and its tools?
Simulink and LabVIEW, graphical programming and modeling environments, became references for representing data as graphs.
Later, part of this work was transferred from Simulink's visual environment to MATLAB text code, and it became evident that behind the text code lie complex relationships that can be visualized. This laid the foundation for analyzing web-project code and for creating GraphLens.
GraphLens is a standalone product with closed-source code. Why did you choose this particular development model, and how do you gather feedback from the community with a closed project architecture?
GraphLens is a complex visualization tool in which UI/UX and the algorithms used are closely intertwined. The closed development model was chosen to preserve the architectural integrity and rigor of the final product. In the early stages, open-source projects often lose their architectural cohesion under the weight of diverse ideas, which is why I need to establish and stabilize my own vision of the architecture and the result before opening it up.
In addition, open source requires additional resources for moderation, code review, and onboarding contributors. At this stage, it is critical for the project to quickly test product hypotheses and build the complex architecture of the GraphLens core without compromise.
When the core is mature enough to accept external improvements without risking stability, I may consider transitioning to a more open model. For now, the best way for the community to participate is through honest feedback via GitHub Issues and Discussions, which I really appreciate.
You mentioned that the authorship and results of GraphLens are patent-protected. What is the key innovation of the project, and why was it important for you to secure it in this format?
The key innovation of GraphLens is the combination of multiple code editor capabilities with source code parsing algorithms. This allows analysis to take place directly within the editor workspace rather than being offloaded to separate tools.
It's essentially about the synergy of different systems—code analysis, visualization, and navigation—within a single development environment. Securing this as intellectual property was important because it represents a fundamentally new way to analyze, present, and navigate Angular project code.
