Nothing super fancy.
For me “proof” just means the agent has to make its intent explicit in a way I can check before running it.
For example:
1) If it wants to delete a file, it has to output the exact path it thinks it’s deleting. I normalize it and make sure it’s inside the project root. If not, I block it.
2) If it proposes a big change, I require a diff first instead of letting it execute directly.
3) After code changes, I run tests or at least a lint/type check before accepting it.
So it’s less about formal proofs and more about forcing the agent to surface assumptions in a structured way, then verifying those assumptions mechanically.
Still hacky, but it reduced the “creative workaround” behavior a lot.
The deny list section hit home. I keep seeing agents use unlink instead of rm, or spawn a python subprocess to delete files. Every new rule just taught the agent a new workaround.
Ended up flipping the model — instead of blocking bad actions, require proof of safety before any action runs. No proof, no action. Much harder to route around.
Autonoma is an open-source, local-first autonomous code remediation engine. It analyzes code at the AST level and uses a local LLM (currently Qwen 2.5-Coder) to automatically detect and fix a bounded set of high-impact issues such as hardcoded secrets, insecure password handling, SQL injection patterns, and common linting problems.
This is a pilot edition: single-repository, on-prem only, no governance layer, no audit logs, no RBAC, and no enterprise guarantees. The goal is to explore what practical, bounded autonomy looks like for code remediation — not to claim production or enterprise readiness.
Everything runs locally, the code is fully inspectable, and fixes are intentionally constrained to deterministic categories.
I’m especially interested in feedback around safety, determinism, failure modes, and where this approach breaks down.
Hard agree. As LLMs drive the cost of writing code toward zero, the volume of code we produce is going to explode. But the cost of complexity doesn't go down—it actually might go up because we're generating code faster than we can mentally model it.
SRE becomes the most critical layer because it's the only discipline focused on 'does this actually run reliably?' rather than 'did we ship the feature?'. We're moving from a world of 'crafting logic' to 'managing logic flows'.
The point about 'no such thing as a free lunch with processes' is something I wish more junior EMs understood.
I've seen so many teams treat process as a pure 'fix', ignoring that it's always a trade-off: you are explicitly trading velocity for consistency. Sometimes that trade is worth it (e.g., payments), but often for internal tools, you're just paying a tax for consistency you don't actually need.
This is the classic 'plausible hallucination' problem. In my own testing with coding agents, we see this constantly—LLMs will invent a method that sounds correct but doesn't exist in the library.
The only fix is tight verification loops. You can't trust the generative step without a deterministic compilation/execution step immediately following it. The model needs to be punished/corrected by the environment, not just by the prompter.
I've been working on this problem specifically in the context of autonomous coding agents, and you hit the nail on the head with 'implicit context'.
The biggest issue isn't just that documentation gets outdated; it's that the 'mental model' of the system only exists accurately in a few engineers' heads at any given moment. When they leave or rotate, that model degrades.
We found the only way to really fight this is to make the system self-documenting in a semantic way—not just auto-generated docs, but maintaining a live graph of dependencies and logic that can be queried. If the 'map' of the territory isn't generated from the territory automatically, it will always drift. Manual updates are a losing battle.
I built Autonoma because I was tired of Copilot suggesting code that didn't compile.
Autonoma is a local daemon that acts as an "L5 Autonomous Engineer". It doesn't just autocomplete; it autonomously fixes bugs, security vulnerabilities, and linter errors in the background.
Key features:
- Air-Gapped: Runs 100% locally (Docker). No code leaves your machine.
- Self-Correcting: It validates its own fixes against your compiler/linter.
- Deterministic: Uses Tree-Sitter for AST analysis to prevent syntax hallucinations.
Would love feedback on the install process. The "Enterprise" tier is just for support—the core engine is fully open for the community.
The 'scaling with intelligence' argument often ignores the 'scaling of verification costs'.
As models get smarter and cheaper, the cost of generating complex code or artifacts approaches zero. However, the cost of verifying that output (especially in high-stakes enterprise environments) remains non-zero.
We might see a value shift where the premium isn't on the 'Intelligence' that generates the work, but on the 'Reliability' systems that validate it. In a world of infinite cheap tokens, trust becomes the scarce asset.
The biggest challenge I've seen with these 'infinite narration' layers on top of simulation games is context context window management. As a RimWorld colony grows, the state data (pawns, inventory, health, history) explodes exponentially.
Are you summarizing the history logs to fit it into context, or are you just feeding a snapshot of the current frame state (JSON) to the LLM? I've found that 'narrative coherence' usually suffers if you don't keep a rolling buffer of recent major events.
This is a fascinating pattern—treating 'agent skills' as composable dependencies rather than monolithic prompts.
I'm curious about the execution model: How are you handling the security implications of an agent pulling and executing arbitrary skill code? Is there an inherent sandboxing layer for these skills, or do they inherit the full privileges of the host agent?
In my experience with agentic tools, managing the 'permissions scope' of 3rd party capabilities is the hardest part of moving from demo to production.
Interesting approach. How does this architecture handle the 'lost in the middle' phenomenon when the retrieval volume increases? I've found that simply increasing volume often degrades reasoning quality unless re-ranking is extremely aggressive.
This is a useful collection. As someone building local agents, I find the biggest bottleneck isn't 'discovering' skills, but defining the permission boundaries for them. Does this directory categorize skills by their 'safety level' (e.g., read-only vs. write-access)?
For example: 1) If it wants to delete a file, it has to output the exact path it thinks it’s deleting. I normalize it and make sure it’s inside the project root. If not, I block it. 2) If it proposes a big change, I require a diff first instead of letting it execute directly. 3) After code changes, I run tests or at least a lint/type check before accepting it.
So it’s less about formal proofs and more about forcing the agent to surface assumptions in a structured way, then verifying those assumptions mechanically.
Still hacky, but it reduced the “creative workaround” behavior a lot.