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.
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!