The only thing I'm wondering is: when will the software become enjoyable to edit and expand? Because so far it's been a real pain in the ass...

When you find out that deep down you don't understand anything about software and your app only works because it's a big workaround, where half of the logic is processed in python and the other half of js... Playing to create software is the most punk strategy game I've ever played!

Today I implemented the first integration of a concept that is very important to me within my app. Basically, all the app's functions, such as saving and moving files, are interface functions, but they are exactly the same tools available to AI agents. More complex scripts and even orchestration that combines agents and deterministic scripts are tools that agents can use, but now they are also building blocks, as simple as writing a .md file via the internal SDK. That is, with a 100-line HTML file, it's possible to create a mini-app with all the tools available in the app, and any AI agent can do this. In other words, the interface can be created on demand with a single HTML file and saved in any folder, as if it were any text file... with automatic integration into the app's theme or fully customized to the user's liking 😁

added native support to HTML miniapp :-)

I don't know exactly how long it's been, but I've been dabbling in "vibecode" for quite a while now. And since I can't write a single line of code myself, something that's been working really well for me is reading and understanding software concepts and architecture. Recently, I started applying some concepts that make sense to me or that I feel more personally aligned with in my project, so I'm in a major process of refactoring and adapting the architecture. Something I've noticed is that, despite the codebase having increased substantially, the AI hardly makes any mistakes anymore, and best of all, adding features or any other refactoring doesn't generate a chain of bugs; everything is resolved surgically. Another point is the documentation and the workflow (code -> documentation update -> commit); this has become essential in my process. The only drawback is that currently the complete documentation has 60k tokens, but it's worth it!

Lens should just support native RSS...

Remember when exploring the web actually felt like an adventure? You’d start on a niche tech blog, follow a hyper-specific hyperlink rabbit hole, and end up on a personal site designed in 1998 that completely melted your brain. Every site had a unique layout, a different soul, a weird vision.Now? Everything is pasteurized, algorithmic, and identical. We traded the digital wild west for three corporate walled gardens designed for maximum cognitive sedation.They feed us colorful thumbnails and TikTok dances to trick us into feeling alive, but let’s be real: we’re not exploring the jungle anymore. We’re sitting on our bedroom rug, playing with a plastic action figure, pretending it’s an expedition.The pleasure of discovery didn’t just fade. It was optimized to death.

Since the core idea of the app I'm creating is that it can be modified by users (with the help of the app's own AI agents), the weekend implementation was: (generated by AI) 😆
When working with AI coding agents, one of the biggest risks is context blindness. An agent modifies a function without knowing what breaks downstream across routers, templates, and state stores.In Kith OS, we solved this by implementing a native, local-first Code Graph and Blast Radius Engine.Instead of relying on heavy background language servers or external SaaS indexers, the engine uses Python's standard AST and our existing knowledge graph ontology to parse the entire codebase into an in-memory directed graph. In under 50 milliseconds, it maps nearly 11,000 relationships connecting Python functions, FastAPI routes, pytest cases, and frontend Alpine.js actions.We packaged this engine as a native agent tool. Before the AI agent writes or refactors any code, it queries the target symbol. It instantly receives a deterministic report listing every direct caller, exposed HTTP endpoint, UI touchpoint, and affected test file.We also introduced architectural hub analysis. By calculating graph centrality across incoming callers, outgoing dependencies, and test coverage, the system automatically highlights its most critical foundational primitives.By turning architectural governance into a fast, local graph query, AI agents no longer guess the impact of their changes. They operate with complete structural awareness.

Finally (I think) I managed to arrive at a simple and efficient graph system with nodes and edges, 100% contained in .md files (front matter) + an automatic system for approving terms outside the closed vocabulary (quarantine), among other things. 😁

My experiments creating my own AI "harness" app...😅
---The Mystery Revealed: How did LLM get everything right?LLM followed the instruction with surgical precision:
It read the preview of call 1 and called:
readpipe(pipeid="pipe://2026090615541800101listvaultdirectory.json", extract_field="files", compact=true)The "Friendly Fire" of resolvepipeargs:
Our pipe interceptor on the server saw the pipe:// prefix in the pipe_id argument and thought:
"Whoa! A pipe! Let me replace it with the actual data before running the tool!"
And it replaced "pipe_id" with the Python dictionary containing all 14 raw files!The Comedy of Error [EXPIRED_PIPE]:
The readpipe tool received a dictionary in the pipeid parameter, tried to read the dictionary as if it were a URI, didn't find it, and spat out the error:[EXPIREDPIPE] Artifact for '{'directory': 'knowledge', 'totalfolders': 4, 'total_files': 14, 'files': [... 14 files ...]}' is no longer available...The Cleverness of the LLM:
The LLM Gemma 4B read the error message, saw that all 14 files and 4 folders were printed within the error text, extracted all the names from there, and delivered the perfect final answer! 😂---PS.: It might seem silly to divide a simple process into 2 steps, but since this is a test, the amount of information limiting the single step is set to an unrealistic (very low) limit. In fact, this process is designed so that the LLM, instead of loading information into context that will later be filtered, loads the information into RAM and applies the filter (tool call) directly to what is loaded in RAM (which is very fast), without polluting its context with irrelevant information, saving many tokens. That is, it can perform several deterministic filters 100% in RAM and after X steps receive only the relevant information (all with a fallback of files on disk, in case the session is resumed later with clean RAM).