HN Showcase
Back to browse
GitHub Repository

Glupe 🙏🌹. Constrain where AI can generate code. Keep the rest of your codebase untouched.

34 starsC++

Yori – Isolating AI Logic into "Semantic Containers" (Docker for Code)

by alonsovm·Feb 13, 2026·3 points·0 comments
Visit ProjectView on HN

AI Analysis

●MidBig BrainShip It

Sandbox syntax for AI code generation, but unclear if LLM integration actually works.

Strengths
  • •Clever problem framing: AI's all-or-nothing rewriting is real friction, and guardrails are needed.
  • •Local-first approach with no telemetry or subscriptions—privacy-focused positioning is genuine.
  • •Docker-for-code metaphor is intuitive and the semantic container concept is non-obvious.
Weaknesses
  • •White paper and README focus on *intent* rather than concrete working implementation or examples.
  • •Unclear how this integrates with actual AI workflows—does it prompt LLMs with context boundaries, or just post-process? No clear integration path.
  • •7 stars, 0 forks, 2 open issues suggest early-stage adoption; code quality and completeness unclear from repo alone.
Target Audience

Developers using AI coding assistants who want fine-grained control over code generation scope.

Similar To

GitHub Copilot context windows / workspace trust settings · Prompt engineering best practices (e.g., 'only modify this function') · Finetune-based code generation guardrails

Post Description

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!

Similar Projects