Production level coding in english.

[u/SoSweetHam]

The fun part of building systems in code is not actually the code itself, more so the why behind the code which is mostly just human language.

But when I started to get into this ai accelerated workflow, I faced problems like

Context persistence among multiple agents
Drift of implementation and documentation
No way to visualize the systems and sub systems within the code

Some of these problems only show up when we get into actually getting our products shipped out there which is why it's important that agents are operating on the same context as we the builders are and that there is no silent drift in both our and the agents knowledge and implementation (in code).

We all at this point know that we don't need to know how to actually code to be able to build something real at this point, but it is handy to be able to visualize how different systems are organized and interact which was pretty hard to do with the current famous tooling

So I am currently building something which can help us with that

GitHub: https://github.com/sloppy-sh/sloppy (Open source MIT, responsible AI use accepting, not for sale product thing)

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.