alonsovm

Hi HN,

I’m a solo dev who got tired of the "documentation hell", either spending hours writing docs that immediately become outdated, or having no docs at all. I wanted a tool that treats documentation generation as a standard build step, so I built Docgen.

Docgen is a lightweight AI CLI tool written in C++ that automates docs-as-code. It sits in your repo (via a .docgen folder and a Docfile) and generates Markdown files next to your source.

A few technical details on how it works under the hood:

- Local-First & Private: It defaults to using Ollama locally so your proprietary code never leaves your machine (though it supports cloud APIs like OpenAI/Gemini if you prefer).

- Smart Incremental Builds: It uses content hashing. When you run docgen update, it only regenerates docs for files that actually changed, saving massive amounts of API credits and compute time.

- Context-Aware (RAG): It automatically analyzes #include dependencies to give the LLM the right context, rather than just blind-feeding it a single file.

- Zero Dependencies: Compiled as a single static binary. Just download and run.

- The "Auto" Mode: This is my favorite part. If you run "docgen auto", it acts as a file watcher with a built-in debounce (waits a few seconds after you stop typing/saving). It quietly updates your Markdown docs in the background while you stay in your flow state.

I’m currently focused on improving the RAG context handling.

You can check it out here: https://github.com/alonsovm44/docgen

I'd love to hear your thoughts, critique on the architecture, or any edge cases you think I should handle!

I built Glupe because I was frustrated that code "rot."

We have Docker to freeze environments, but nothing to freeze logic. If you wrote a sorting algorithm in C++ 10 years ago, that code is "legacy" today. I wanted a way to deal with software rot.

Glupe is a "Reverse engineering engine" for logic. Normally it is intent -> code, I went the other way aroound code -> intent.

It works in two steps:

Refine: It "melts" source code into a high-level Intent file (.glp). This file is pure logic, stripped of syntax. Build: It re-compiles that Intent into any target language (C++, Python, Rust, Go).

I tested it on a legacy COBOL file. It successfully transpiled it to modern Python, correctly handling the PIC 9(5)V99 decimal logic that usually breaks other tools.

Example (COBOL -> Intent -> Python): https://github.com/alonsovm44/glupe/tree/master/experiments/...

Key Features:

Self-Healing: It has a built-in compilation loop. If the generated code fails (e.g., syntax error), Glupe feeds the error back to the AI and fixes it automatically.

Spaghetti Detection: If Glupe detects messy code (global variables, god loops), it attempts to refactor it into clean, modular intent before saving.

Language Agnostic: You can write logic once and deploy to C++ (high performance) and Python (prototyping). It's written in ~3k lines of C++ and runs locally with Ollama or cloud via API.

Repo: https://github.com/alonsovm44/glupe

I'd love feedback on the architecture or the "Intent" paradigm. Do you think this solves the legacy code crisis, or is it just a fancy transpiler?

Hello HN, i want to share Glupe, a hobby project I've been working on for the last 30 days. Nothing fancy.

I've been pretty annoyed by the "all or nothing" approach of most AI coding tools, which are useful, yes, but also risky. If i tell an AI to "fix this bug" it may probably do it, but it can (or will) hallucinate a fake library, mess up my manually optimized code or subtly delete important code without explaination or notice.

Glupe summarized is this: "Stop giving AI root access to your code, Glupe isolates AI logic into semantic containers, so your code stays safe".

Instead of sending your whole file to the LLM and pray it does not break, with Glupe you can surgically tell the AI were to write code and what to do using the $${ logic }$$ syntax. Code outside the container is preserved as is. Instructions inside the container are turned into source code and embedded into the output file.

Containers can be named and are cached and hashed, Glupe detects which containers changed in a source file; when you run `glupe project.txt -make` it only calls the AI to update the "dirty" logic containers and uses cached code for the clean ones, saving time and API calls and allowing for incremental builds using AI.

What if there is a syntax error on the output code? Glupe has a self-healing loop which feeds the error history back to the LLM and tells it to fix it. No more trivial debugging.

Why do I say it is "Docker for code"? It is a metaphor, it applies the same core principle of Isolation to source text that Docker applies to running processes.

In Servers: If you run an app directly on a host OS, it has "root access." If it behaves badly, it can delete system files.

In Coding: If you give an AI access to your file, it has "root access." It can "crash" your architecture by deleting manual code or changing signatures. Docker protects the OS from the App. Glupe protects your Architecture from the AI.

Docker solved "it works on my machine", Glupe aims to solve "

I wrote a white papaer on the subject which is available in the repo.

Any feedback or critcism is welcome and encouraged.

repo: https://github.com/alonsovm44/glupe white paper:https://github.com/alonsovm44/glupe/blob/master/WHITE_PAPER....

Hi HN, I've been a developer for some time now, and like many of you, I've been frustrated by the "All-or-Nothing" problem with AI coding tools.

You ask an AI to fix a bug or implement a function, and it rewrites the whole file. It changes your imports, renames your variables, or deletes comments it deems unnecessary. It’s like giving a junior developer (like me) root access to your production server just to change a config file.

So, 29 days ago, I started building Yori to solve the trust problem.

The Concept: Semantic Containers Yori introduces a syntax that acts like a firewall for AI. You define a $${ ... }$$ block inside a text file.

Outside the block (The Host): Your manual code, architecture, and structure. The AI cannot touch this. Inside the block (The Container): You write natural language intent. The AI can only generate code here.

Example: myutils.md

```cpp EXPORT: "myfile.cpp"

// My manual architecture - AI cannot change this #include "utils.h"

void process_data() { // Container: The AI is sandboxed here, but inherits the rest of the file as context $${ Sort the incoming data vector using quicksort. Filter out negative numbers. Print the result. }$$ } EXPORT: END ``` How it works: Yori is a C++ wrapper that parses these files. Whatever is within the EXPORT block and outside the containers ($${ }$$) will be copied as it is. When you run `yori myutils.md -make -series`, it sends the prompts to a local (Ollama) or cloud LLM, generates the syntax, fills the blocks, and compiles the result using your native toolchain (GCC/Clang/Python).

If compilation fails, it feeds the error back to the LLM in a retry loop (self-healing).

Why I think this matters:

1. Safety: You stop giving AI "root access" to your files.

2. Intent as Source: The prompt stays in the file. If you want to port your logic from C++ to Rust, you keep the prompts and just change the compile target.

3. Incremental Builds (to be added soon): Named containers allow for caching. If the prompt hasn't changed, you don't pay for an API call.

It’s open source (MIT), C++17, and works locally.

I’d love feedback on the "Semantic Container" concept. Is this the abstraction layer we've been missing for AI coding? Let me hear your ideas. Also, if you can't run yori.exe tell what went wrong and we see how to fix it. I opened a github issue on this. I am also working in making documentation for the project (github wiki). So expect that soon.

GitHub: https://github.com/alonsovm44/yori

Thanks!