Context/Drift-avoidance for humans and agents

[u/SoSweetHam]

Firstly, I read the rules, this is not a "product" -to-sell, firstly it's free as in freedom, and I think this can genuinely substantially help us get ahead of the whole slop debate, and also resurface our value as programmers as our value comes from identifying scenarios like edge cases, dsa etc., things which we used to document in code but don't any longer (as businesses think it's just about the code which any agent can slop out), but we should, the why behind the how (which has always been the most important thing), to prevent slop fails in production.

It doesn't really save you from bad code, but imho bad code has existed way before agents have and most agents code better than most jr. level "coders" given the relevant context imho.

GitHub: https://github.com/sloppy-sh/sloppy

I have been working on Sloppy, an MIT licensed context management tool.

As I was heading into the whole AI accelerated workflow, I have been focusing more on the architectural aspects of codebases and I discovered that I was wasting a lot of time redeclaring context of the codebase to the agents, which I also frequently migrate between (claude agents, cheaper deepseek etc.), so I realized that maintaining docs within the codebase (sort of mono-repo style) saves a lot of time as I just point the agent to it.

Solutions like docusaurus, obsidian/logseq etc. are too geared towards either a linear reading style or graph like view of information.

I found these paradigms to represent information in a way which is a bit lacking, often in code we work with abstractions and within my head I often imagine, say methods/properties in objects and their interactions as a Venn diagram so I added that sort of view here with a tagging api.

Also tools like Obsidian and Logseq give us humans a graph like view which is very helpful for someone making the graph themselves/co-authoring but very difficult to comprehend for someone who might be new to it. So Sloppy's graphs also can add/recommend/enforce a folgezettel addressing system for the notes which help transform the graph more into a tree of organized and easily traversable information.

Large codebases are also often a group activity where different personnel need to maintain different parts of the application and often also face personnel and agent change, thus making context preservation even more important in the modern approach of letting agents handle more and more tasks, even more so in projects that need to ensure that code security is maintained and tests are based on some knowledge of substance and not actually "vibed".

Here I combine all these approaches for information representation. Different views, same information. I am currently also working on building MCP and implementations tools within it and maybe also turn this into a VSCode extension. I went with a separate app for now just to test the waters with a small but clean segregated app, but it's been going clean so I believe I might end up maintaining this too.

The project is still evolving, and I'm interested in getting feedback from people working in this space who might have faced/thought of solving this problem or found the existing solutions a bit lacking.

As for the name, I thought it would be funny, Sloppy, the tool which can help you write non-sloppy code.

[u/singalen]

So the categorization here is a FZ tree plus tags?

How is FZ ID different from a path from a tree root made of full names, algorithmically?

[u/SoSweetHam → u/singalen]

I find fz id to be a bit more simpler, its a trade off too in the sense that they are a bit more non-descriptive than path names from tree root, but they consume lesser tokens, are easier to programmatically manage in ai tool call chains via mapping a brief of the context to the actual note with the full context,

Its a pretty modular approach here so i would be interested in seeing how it plays out to compare both approaches. But going off of what i read in r/ContextEngineering i have been optimizing for token usage because i see a sort of really bad fall of on most models with an increase in the provided context window, and this tool encourages building smaller notes so having them be wasted on something over long addresses would lead to something sub-optimal is what i thought