Great article! This is an impressive piece of work. I particularly appreciated the detailed documentation and the choice of keeping the semantic knowledge graph 100% local. It's clear a lot of thought went into the architecture. I’m definitely going to give Kirograph a try very soon.
I was also reflecting on the technical trade-offs of this "local-first" approach. While it's a game-changer for privacy and tactical refactoring (like renaming or extracting constants across the codebase), I wonder how it scales when it comes to high-level architectural changes. Since the system uses a filtered semantic graph to provide context, do you think there's a risk of losing the "big picture" needed for complex design pattern implementations? I'd love to hear if you’ve considered adding some form of hierarchical summarization to help the LLM grasp the overall intent without compromising the local-only soul of the project.
I think this should be used mostly to reduce token usage for reading files and understanding the details or implementations. It should basically cover the expensive action of searching file using the AST engine and embeddings to add value to it.
It's a good point anyway, do you have any suggestion?
In my perspective the best way to say the LLM patterns used or to be used, are still skills, steering and markdown doc which coule be coupled with this approach. But if KiroGraph could handle in any way also the "big picture" would be a big step forward for it.
Also, I'm reflecting on enabling a cloud engine option (s3 vector?) mostly to serve teams working on the same codebase which could then share the same semantic engine, backup indexes or to enable folks which prefer a lightweight local configuration.
Thanks for the insights, Davide! Your point about KiroGraph filling the 'expensive gap' of AST searching is spot on. I’m actually preparing a talk for an event in Florence about 'Smells to Spells' (builder.aws.com/content/3CJ7RbTRAn... ), and your tool is the perfect missing link for what I call Level 3: Architectural Refactoring.
Regarding the 'big picture' and your question for suggestions: I think a Hierarchical Summary Layer could be the bridge. Imagine if KiroGraph, during the indexing phase, didn't just store nodes but also used a local LLM (like a small Llama 3 via Ollama) to generate 'Module Summaries'.
In my framework, Level 3 smells (architectural debt) often cause AI to suffer from 'Algorithmic Over-zealousness': it might implement a complex Strategy Pattern where a simple if would suffice, simply because it lacks the 'Big Picture'. If KiroGraph could store these high-level 'Architectural Nodes' in its SQLite graph, the AI could query them to understand the intent before querying the specific call graphs for implementation.
This keeps KiroGraph 100% local but gives it the 'vision' it needs to avoid over-engineering. I'd love to chat more about how we could map these 'Summary Nodes' in your schema!
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
Great article! This is an impressive piece of work. I particularly appreciated the detailed documentation and the choice of keeping the semantic knowledge graph 100% local. It's clear a lot of thought went into the architecture. I’m definitely going to give Kirograph a try very soon.
I was also reflecting on the technical trade-offs of this "local-first" approach. While it's a game-changer for privacy and tactical refactoring (like renaming or extracting constants across the codebase), I wonder how it scales when it comes to high-level architectural changes. Since the system uses a filtered semantic graph to provide context, do you think there's a risk of losing the "big picture" needed for complex design pattern implementations? I'd love to hear if you’ve considered adding some form of hierarchical summarization to help the LLM grasp the overall intent without compromising the local-only soul of the project.
Thanks for sharing this, truly inspiring!
I think this should be used mostly to reduce token usage for reading files and understanding the details or implementations. It should basically cover the expensive action of searching file using the AST engine and embeddings to add value to it.
It's a good point anyway, do you have any suggestion?
In my perspective the best way to say the LLM patterns used or to be used, are still skills, steering and markdown doc which coule be coupled with this approach. But if KiroGraph could handle in any way also the "big picture" would be a big step forward for it.
Also, I'm reflecting on enabling a cloud engine option (s3 vector?) mostly to serve teams working on the same codebase which could then share the same semantic engine, backup indexes or to enable folks which prefer a lightweight local configuration.
Thanks for the insights, Davide! Your point about KiroGraph filling the 'expensive gap' of AST searching is spot on. I’m actually preparing a talk for an event in Florence about 'Smells to Spells' (builder.aws.com/content/3CJ7RbTRAn... ), and your tool is the perfect missing link for what I call Level 3: Architectural Refactoring.
Regarding the 'big picture' and your question for suggestions: I think a Hierarchical Summary Layer could be the bridge. Imagine if KiroGraph, during the indexing phase, didn't just store nodes but also used a local LLM (like a small Llama 3 via Ollama) to generate 'Module Summaries'.
In my framework, Level 3 smells (architectural debt) often cause AI to suffer from 'Algorithmic Over-zealousness': it might implement a complex Strategy Pattern where a simple if would suffice, simply because it lacks the 'Big Picture'. If KiroGraph could store these high-level 'Architectural Nodes' in its SQLite graph, the AI could query them to understand the intent before querying the specific call graphs for implementation.
This keeps KiroGraph 100% local but gives it the 'vision' it needs to avoid over-engineering. I'd love to chat more about how we could map these 'Summary Nodes' in your schema!