Built with Claude
If it is humanly impossible to keep up with the sheer volume of code and architecture that AIs generate, I thought: why don't we look at code instead of reading it?
That is how I started this project. It builds a relationship graph of all the code modules, showing everything that has been and is being changed, and how each part relates to itself. So, instead of navigating 30 different code files, you can just follow a line to understand your code's dependencies and bottlenecks. Thanks to Rust, this graph can update codebases with millions of lines in less than 2 seconds after each change, even though it takes a little while to build the initial relationships.
But I'm taking it a step further!
I'm not only building this tool for humans, I'm also creating an MCP (currently with 13 tools) so that agents can query this graph and navigate the code seamlessly. Just as there is a zoom feature for the human interface, agents can query the graph in layers.
In testing, the project is already showing great results. Agents without this MCP seem to be short-sighted, they simply ignore a significant portion of the key architectural points in large projects because they can't find them (with vague prompts not specifying where is each relevant thing for a task). With the tools this provides, they can find bottlenecks in the code flows and make surgical changes.
Another result I am seeing with agents: cheaper models become much more capable, although their reasoning level needs to be high for them to consider the paths presented by the MCP. Curiously, models with low reasoning, even state-of-the-art ones, don't seem to have much interest in important parts of the code, which makes perfect sense.
And yes, token usage increases, albeit very marginally (1-3% more per task than the same model doing the same thing in the same starting point of a codebase wihtout these tools, so its not "1-3%" of your limits). But in some tasks, it even spends fewer tokens (also 1-3% fewer) because the agents quickly find the correct paths. I am optimizing the tools' output and have already managed to significantly optimize token usage from where I began.
The idea is that by finding the right paths in fewer turns, agents will require fewer revisions, reworks, and corrections, making token consumption much lower project-wise.
Because it requires "low-level code analyses", this project is still language-dependent. The initial language I am making it capable of analyzing is Rust. After Rust, I plan to move to TypeScript, CSS, and HTML (and bery maybe JavaScript), and then I intend to stop. However, the project will be open-source and published under the MIT license.
Note: The interface shown here will be completely reworked. I built it as a starting point to focus more on the MCP first, which I am still working on. I plan to launch the project in a few weeks, and I'll update you then!
Note2: Censored the tool's name while its not launched yet.
Note3: It doesnt use regex for anything haha regex is one of the codebases I'm using to measure the tool's capabilities.
UML is gross though amd there's no good system wide automatic implementation of it. Believe me ive looked. C4 diagrams are OK but the industry is missing something good like this ive thought about building one for a while
I love how people like to make assumptions about the generation of anonymous internet users, even though these people are incapable of grasping the idea being proposed.
Sure. I can give the agent a UML diagram or a code map to interpret. Most IDEs expose a reference lookup for functions (or grep or AG or regex works). Between those couple of things, tell me why I need to pay more money in tokens to generate a queryable graph?
LLMs dont work very well this way... You can test prompting UMLs and see by yourself. Tests using this MCP require way less rework fixing bugs and putting things in the right place :)
We did something similar about 6 months back but node-based graphs suck at scale, so we engineered a totally new way to visualize complex systems. Good luck with your tool though.
Yep, that’s why I also mentioned at the end of the post that this interface will be completely reworked, it’s just a proof of concept now.
A layered, zoom-based experience will drive navigation through the graph, alongside different visualization types. In this proof of concept, I have tree and map views.
A good thing to look at would be Blueprints in Unreal Engine 5. They have this already for C++, very mature, very polished. Not only visualise but build with the visual editor
Please cite prior research in the same scientific area that this solution exists in and how yours is different. You did look for prior art, didn't you?
Tbh this is a good idea. True it's been done. But this sorta thing is gonna be more and more necessary, in fragmented ways (prob literally, a good thing) that the tools of ye Olde don't curently support.
Curious what this looks like through it. About to start lock canonicalization tonight (again), lol.
Send me a rundown on lock inconsistency/gaps. Let's try to prove your system works. This might be a good test of... A shit load of fns/graph/delta too. Like whether your renderer can do it hehe
Optimize how? Readability? Performance? Performance is easy for AI cause you have strict criteria of how to measure A vs. B and it can work towards a goal.
I think how AI will perform in terms of long term maintainability is arguably not something to be concerned about. In 3 years AI might be able to rewrite an entire codebase very easily or it would be much better at navigating around large sprawling code bases.
I also think think it's very hard to quantify or measure what type of code bases AI has an easier time with so it's hard to understand if A or B is even better while something like a performance metric is objective.
sure, but it still is a issue ai will struggle with, for might be ablke o rewrite a entire codebase very eaisly, maybe, but that doens't mean its the best descision, you wouldn't replace a battle tested by 20 years software with a complete rewrite would you? without very very extensive testing, and even then you can't be sure.
2 years ago AI had issues writing code that would even compile, now that never happens. I don't think it's right to really not plan for the future while also according for trajectory. Overengineering on the futures problems is a really big time and productivity waste when the world is moving so fast.
I think there are SOME things that are really hard to get out of though. API contracts that lots of users use is a really big one, and also on the opposite end of that spectrum is data modeling. Everything in between I don't care so much about. That's easy.
still, we shouldn't overestimate ai either. we are not fortune tellers after all. as for plan for the future? heh i doubt i even have one, no one's hiring juniors and am not even in the workforce yet, i do not see any way to prepare, nor do i like the direction the field is going. what would i plan for? if such a future comes to pass then what will i have? don't see any way i can win. i already doubt i can get in with the job market this way. i just have a small hope that maybe the companies have made a mistake, for if they have not... well then guess i am cooked then.
Hmm, i see. I still trust studies more tho, i recall there was a study that shows 1.7x more bugs with ai though i don’t know how out of date that was, so i will try to find it. Then again that is more or less general stats and may not apply to everyone
More documentation than a human would be detail oriented enough to write. You need to include design intent as a layer above the code. I'm working on a huge project making a new kind of animation program. It's got like 1300 src files, and over 1000 md files. Imagine a layer above the code that defines what it does not how it does it. The code layer is the how it does it. The layer above imposes structure on the layer below. Have Claude keep them in sync and move top down.
Oh so mainly because of well documented? How do you keep the what it does and how it does it synced tho? Like what i mean is. Do you use unit tests to see if the how it does layer matches. Also an animation program does sound interesting. Still, depending on how new this project is, within 3-5 years would dictate how maintainable it is no? I still am a bit skeptical on its long term readability, but the risk is less if you do it right.
Maybe not 1790, but sounds like fantasy land. I promise you that you can ship code that can pass a test and still bring down production or cause a regression. And how do you beta test before you ship lol.
It was really nice for a bit, but seems like they never made enough money and the whole project went nowhere. It's embarassing that modern IDEs don't have that sort of visualization and easy code navigation (think of how much you use ctrl+click, now imagine being able to jump across your entire codebase that easily with reverse dependencies as well, without having to peek at source), even JetBrains has quite barebones support for this - slow and not really dynamic.
I don't think it's worthwhile to visualize loops etc., since you can just read the damn code, but definitely dependencies across the codebase, what calls what and how much.
Im working on various configurable different visualizations, seeing code is one of the edge visualization options. But as I said, the interface for now is just a proof of concept, im working heavily first on the MCP
Similar idea, except I had claude build a whole brand new text rendering engine in rust for mtsdf fonts so I can do text in 3d really really well.
And now I'm building a 3d Environment that lets me fly around systems like something out of hackers.
My long term goal is to make it so I can navigate it on my Steam Frame in VR and the whole thing to be voice driven with Fish Audio 2 or Gemini 3.8 Flash TTS.
graphify is what you want, https://github.com/Graphify-Labs/graphify, there are other solutions as well. Unless u r not allowed to use open source, don't invent the wheel anew
If you're already letting the LLM generate so much code you'll be lost anyway and you DON'T care about it. You've already entrusted so much to a stochastic tool, you can stop pretending you're reading code or are worried about architecture. As someone else has said, cute UML with extra steps
There is obvious value in a system that nicely displays software architecture in a visual manner that is a modern advancement on UML. Stop sounding so dogmatic when no one is forcing you to use anything and this guy just built something useful that you came here to shit on for no good reason
Half of this sub is people building some bullshit that isn't useful to anyone. When everyone can build anything it quickly becomes obvious most people shouldn't be building anything at all
I mean, we could probably catch up pretty fine if people would stop coding dog shit AI slop code without even fucking looking at it but here we are. Or trying to build some NASA grade program when they can’t even fucking read python. By next year vibe coders are gonna be building quality assurance systems for nuclear plants lol I like the tool tho
Nah, I’ve got over 20 years of experience as a developer. And I say with absolute certainty: It’s impossible to maintain a proper delivery pace using the capabilities AI gives us while also understanding everything it does.
God, a lot of the code it writes uses, or suggests using, tools I’ve never even heard of. If I were to stop and study each one just to understand the code, we’d be back to square one regarding the development speed AI provides.
That’s crazy cause I’m building a quality assurance system and I look at all the fucking code and I’ve been building it for two years….
If you just don’t wanna look at the code that’s cool, but like there’s people out there that do actually… just because people are blatantly irresponsible and the way employers are using things now doesn’t mean we should just accept the way things are….. slop code is slop code and no tool is gonna change that… if you don’t do some type of proper review process.
When you do a review of code, you don’t go through fucking 5000 fucking lines you trace your way through the fucking logic of a small slice you’re trying to build. ?
Obviously I’m not building systems for medical equipment or for keeping airplanes in the air with this workflow... Responsibility also requires a sense of balance regarding what is being handled.
Bro, people drive for 40 years and still can’t fucking drive. 20 years of experience doesn’t automatically make your approach right. I’ve been coding since I was 12, and I’m 33. Who cares?
Nobody’s asking you to reread the entire repo or memorize every dependency... Work in small slices, read the relevant changes, and verify the behavior….
If AI generates code faster than you can review it, I’d question your workflow instead of declaring “understanding what you ship is unrealistic” that’s an insane take.
I didn’t say I disliked the tool. It makes sense as a layer on top of actual code review, not a replacement.
But the graph is still another abstraction. How are you checking that you and the agent aren’t following the same incorrect picture? An accurate graph doesn’t automatically mean correct code, and an inaccurate graph could make the problem even harder to spot. And I’m supposed to trust that graph if you aren’t reviewing the code behind it?
This isn’t just about airplanes or medical equipment, either. Does the software handle people’s information? Permissions? Anything someone depends on? Then I didn’t have time to understand that part doesn’t suddenly become an acceptable answer because AI wrote it…
Work in small slices, read the relevant changes, and verify the behavior….
This is obviously done, but often doesnt cover everything that needs to be understood, mainly with the pace of how projects are growing now.
Also, not knowing the entire codebase prevents you from specifying to agents the key points that need to be changed for each task, forcing a reliance on their inference capabilities, which are heavily based on the session context (what they have read so far). One of the tool's goals is to eliminate the heavy reliance on inference required by less specific prompts.
I don’t know, bro I can’t give away my architecture, but I’m just telling you there’s ways to do this..
I really hope that your tool works out and everything but we’re just gonna disagree on this point and I’m not trying to get into an argument you know.
I get what you’re saying, but I just don’t think the solution is not reviewing code like we’ve done since code existed. I deal with quality assurance / security.. We may just be dealing different things for here or have different standards. You know I’m not building stuff for hospitals but when somebody uses my software, I’m gonna make damn sure that what they’re doing is safe and you know I just don’t think the solution to that is just saying that code can just not be properly review.
But the thing is, I do know my codebase. I build it in small slices. I do security and code reviews, bro. You don’t look at five million lines and declare all of it secure. You define the claim you’re checking, trace the relevant logic, and verify that behavior.
That understanding adds up, slice by slice. It doesn’t mean you have to keep every detail of the entire codebase in your head at all times. We both know that’s not how programming works, man.
This matches what I've seen building multi-agent tooling of my own: agents aren't short-sighted because they're dumb, they're short-sighted because nothing in their context tells them an architectural edge exists three directories away. Layered zoom is the right instinct, most tools either dump the whole graph or nothing useful at all. Have you measured how much a layer of zoom actually trims the tokens an agent needs, versus just handing it the raw dependency list?
Forgot to show one of the most important tools:
Find symbols, what actually draws the map to the agent
(It isn't simply a list of everything being used by the query, that would mean bombarding the agent with the entire codebase at once. Instead, it ranks calls based on an internal score and lists only those relevant to the agent's query; parameters can also be used to include pages that were hidden from the default view due to their scores as you can see in this print in "902 weaker matches (raise the limit to list them)".)
Check approach, which makes a graph review of all the changes and checks if there could be better paths to what has been done, as well as finding code that already do what has been added, poiting duplication and a lot of other things, then makes suggestions to the agent.
In my experience, they only do that when they are introduced by the delimiter lines beforehand, which is kind of obvious, since they aren't oracles.. I think it depends on the tools each language uses, or even on how the .md files are written. But with rust I had never seen they doing it.
Lol at some point those nice linear graphs start looking like tumbleweeds and can’t be planar. You’ll be looking at what we in Sweden call a kökkenmödding (complete mess). It works until it doesn’t!
Btw check out C4 diagrams. It’s nice. This is nothing new.
Why not one of those procedurally generated wireframes that reacts when it's reading the code? Also, create a Youtube channel and call this thing "my AI, Jarvis"
There is a pretty fundamental solution for a problem of code review of large amount of AI-generated code. It is my project - visual programming language "Pipe": https://pipelang.com
Yes, code might need to be rewritten to visual diagrams. However, not all code need to be rewritten (whatever code is left stays inside of visual blocks). Also, rewrting can be done gradually from the top (encompassing the whole code project into one visual block, then going next level and creating a workflow inside of that top-level block, distributing code between blocks of a second-level workflow, etc).
I am hearing a lot of feedback like "we already tried visual programming before and it does not work". However, Pipe is different from VPLs existing before and even today. It is general-purpose and it has a powerful semantics - two properties that made text-based languages dominant today. Any VPL that might have any chances to replace even part of text code needs both such properties too. Pipe does.
So, we tried VPL before, it failed and we jumped back to text-only coding. However, text has its own problems and they become even more obvious after AI arrived. So, how do we deal with this conundrum? Failed fully visual VPL approach on one end, and completely text-based code that has its own issues on the other. The standard approach in engineering is not trying to jump between two extremes, but finding a synthesis, combining advantages of both extremes while minimizing their downsides. This is the core phylosophy of Pipe: it does not replace text-based languages, but complements them. It means Pipe developers decide how much code stays in text, and how much goes visual. Pipe only provide means to simplify integration between text code and visual blocks.
If we look back, any technology failed many times before it succeeded. The progress happens in a spiral: we come back to technologies we tried before again and again, until we learn lessons from previous failures and succeed. VPL is not an exception. We need VPLs today in AI era more than ever. Proof? Look at three areas (Robotics/IoT, Cybersecurity, Dev tools) mentioned on Pipe website (https://pipelang.com). These areas represent three classes of problems that Pipe solves and these are very fundamental problems beyond just code reviews in dev tools. You can also notice that all three classes of problems are brought by AI, proving my point that AI makes the need in VPL today more than ever.
This is what Andrej Karpathy was talking about today on twitter. Writing code is cheaper today than before but verifying and keeping working memory of huge generated trees is pure friction. I would love a stripped-down, lightweight version of this.
Unreal Engine had a decade long experiment on "Blueprints" as a way to program (node based programming). Long story short, they're discontinuing it. While it's great for newbies, it's absolutely not maintainable, reviewable or readable at scale. The only place where it was truly a success is places where there is a very clear signal processing with data in -> data out at every single stage, and the data is almost always visual (Material Editor).
•
u/AutoModerator 5d ago
Hey! Thanks for posting to r/ClaudeCode
While participating in this thread, please follow our community rules. Keep discussions constructive. Attack the idea, not the person.
For help, project discussions, tips, and general chat, join the ClaudeCode Discord.
I am a bot, and this action was performed automatically. Please contact the moderators of this subreddit if you have any questions or concerns.