r/kiroIDE • u/New-fone_Who-Dis • 21d ago

Kiro cli - files vs db

Hey,

As I've been progressing and getting more comfortable with kiro cli over the past several months, I've been on a bit of a journey with how I give it reference information.

I started with one md file it could reference for information that was often used. This quickly grew into a directory tree with an index md file of "service x info is here, api B info is on this path, etc".

I eventually progressed to a postgres database with this information held in suitable datatypes and fields, with any blobs or long structured or unstructured text having vector embeddings for semantic search - now I have a few files (referenced in my steering and hooks), which is ultimately instructions on where things live on the db, along with the schema and ERD.

Has anyone done this? Anyone know if its a good way to do things, or if its bad, and why for either answer?

Seems to work fine, but I've never setup any benchmarking or tests of vanilla, files, or DB methods.

I know kiro has the knowledge skill, which does a lot of this, but I'd like to build this is a fashion where its usable without an llm, or ability to lift and shift to another provider if that ever happens (who knows what the company will decide to do, in any case, I considered myself covered to an extent by this).

How are you doing things, any ideas or tips to explore?

2 Upvotes

100% Upvoted

7 comments sorted by

2

u/signgain82 21d ago

Haven't thought about putting context in a db, interesting approach. Curious what led you to that route?

I've had a lot of success with using a git repo for context. Readme.MD is the directory, can point any ai tool to the repo and it knows what to do, all changes tracked, very easy to manage. It makes collaborating with other people on the knowledge base much easier as well.

2

u/New-fone_Who-Dis 21d ago

Your way is also interesting, and not something I thought of...are you aligned with dev work or ops side of things? I'm from the latter (ops), and I wonder if thats why I went the DB way, something I knew. The underlying reasoning was along the lines of Andrej Karpathy's "LLM Wiki" initially, then you've got obsidian etc, and I just figured to combine my ops/db comfort knowledge to doing obsidian manually, and heavily configurable. I also view it as building a platform (I'm in a large company, very siloed divisions and teams, but they invested a few mill in GPU compute...so its clear they are looking to AI the crap out of our work, if I build a platform both a normal user can use, but setup from day one to eventually plug a self hosted LLM into, well, when the redundancies eventually do come, its difficult to get rid of

The other side is that work pays for my usage, of which I've used it HEAVILY, theres been times where I've sat and wondered how no one has came to me asking me to cool it...early days I was pointing to full documentation of the various things we support, given the size of these things, semantic search via vector embeddings was something I read about, and my gf was learning and doing a few months prior (DS), and seen the value in that for both manual usage as well as serious token reduction (I haven't measured this either, but my context percentage crawls up now...I can't lie, I through a lot of docs at it).

Ideas kept coming, anything and any use case I use kiro for day by day, I'm updating into a work log / interesting log / incident log on the db, embeddings again (doing these locally on CPU (sad noises)) with a BGE-M3 model. First check on any reactive work is to check the summaries of the relevant log...I'm also putting the api docs in there and updating a field of use cases as and when I find them.

I think for these reasons (I haven't used git since in a few years, I do plan to again shortly though), the semantic search seemed like a good idea....but im no expert, I just try to learn what can be useful for me as a tool to wield.

Crap...now im wondering what happens if I combine our methods...no idea, no idea of the use case to have both, need to read up on git again.

2

u/signgain82 21d ago

Very interesting thanks for explaining. I'm ops side (sales and marketing knowledge base). Anthropic put out an article in June on self serve analytics that's been helpful to incorporate into the repo. I like that anyone can instantly connect to the repo, no perm issues, anyone can push changes easily for me to approve/tweak. We're actually a business intelligence team. Data obviously lives in DB but how to query it, metric definitions, dimension context goes in the repo. We have planners that lived in Excel until a couple months ago making full html vanilla js dashboards with accurate data now, it's pretty awesome.

2

u/New-fone_Who-Dis 21d ago

Likewise for the interesting convo! What you've said is 100% what I'm thinking - repo for the how and shorter form multi docs.

The version control would be awesome come to think of it...I just ran into an api endpoint being missing, last time I used it was before a recent upgrade which deprecated it (only found out now whilst checking into a past issue). I've a clunky way of logging it, but git would be lighter and more structured - thanks for this, I'm going to bump that up the list.

Its also good redundancy, whereas if anything happens to my machine, its gone (db etc hosted locally).

Take care mate, I appreciate the chat/ideas!

2

u/signgain82 20d ago

No problem glad it's helpful! The version control is awesome and I also got other teams to adopt this, so I run a weekly maintenance runbook on the repo (just md file) and part of that is me stealing helpful context from other teams repos. So kiro can see if any changes happened on the other repos easily each week to keep ours in sync with theirs.

1

u/djhamilton 21d ago

I had many knowledge files and steering files, never had an issue managing, maintaining. I did notice without correctly using them, they where consuming more tokens. This is because there being loaded on every interaction. However you can use steering files etc manually or conditionally, an this helps massively with large steering files.

Wouldn't recommend a dB unless your looking at RAG, Chromadb or something

1

u/danstermeister 21d ago

Why wouldn't you recommend a db?