← All writing
August 5, 2026 · 3 min read

The execution gap: why GodForge won't let an LLM touch your files

GitHub Copilot suggests code, then leaves you to copy, paste, and run the rest of your workflow yourself. GodForge — my VS Code extension — closes that gap with deterministic logic for anything risky, and hands the LLM exactly one job. It's now a peer-reviewed, published paper.

Multi-Agent SystemsAIDeveloper ToolingVS CodeResearch

Every AI coding assistant I'd used shared the same shape: it suggests, and I execute. Copilot writes a function — I still paste it in. It suggests a git command — I still switch to the terminal, type it, and run it myself. That gap between what a model proposes and what actually happens to my project — file edits, git operations, documentation nobody has time to keep current — is what I started calling the execution gap. It's the whole reason I built GodForge.

GodForge is a VS Code extension I built to close that gap, and it's now a peer-reviewed paper too — published in Springer's Intelligent Strategies for ICT, the ICTCS 2025 proceedings, in the Lecture Notes in Networks and Systems series. Read it here.

The design decision the whole paper is built on

Most "agentic" coding tools hand the LLM the keys to everything — file operations, git, docs — and trust its probability-weighted judgment to hold up on a rename or a commit. I didn't want that. GodForge draws a hard line instead:

I ended up calling this logic-first, LLM-second: automate everything you can trust to a script, and spend the model's non-determinism only where it's actually worth the risk.

Three agents, each doing exactly one job

GodForge is a small multi-agent system, but not the "simulate an entire engineering team" kind you see in tools like MetaGPT. Each agent here is a plain, single-purpose module — not an LLM persona:

The agents don't talk to each other automatically. Every action starts from an explicit button in the VS Code UI, on purpose — no open-ended prompt, no ambiguity about what's about to happen to your files.

The part I actually care most about: undo

A tool that's allowed to touch your filesystem is only trustworthy if everything it does is reversible. Before any file or folder operation runs, GodForge snapshots the original into a hidden .godforge/history/ folder — restoring it later is a plain copy-back, not a re-generation, so it's bit-for-bit exact. Git actions record the branch and commit SHA beforehand, so "Revert Last Commit" is a real, native GitHub revert, not a force-push hack. Every README update keeps its previous version one click from being restored.

The system also writes its log entry before it acts, not after — so if VS Code crashes mid-operation, GodForge knows exactly what state you were in and can recover from it, instead of leaving a half-finished edit behind.

Why this became a paper, not just a side project

The more I built this, the more it turned into a real answer to a question the field hasn't settled yet: when should an AI coding tool be allowed to act, not just suggest — and how do you make that safe enough to actually trust? That's the argument I wrote up formally, working through the full architecture and comparing GodForge against Copilot's suggestion model, LLM-based semantic file systems, and existing multi-agent frameworks. It's now published and citable.

If you want the full architecture, the safety mechanisms, and the comparative analysis in detail: GodForge: A Hybrid Multi-Agent Framework for Execution-Driven Workflow Automation in Visual Studio Code — Springer, Intelligent Strategies for ICT, ICTCS 2025.

The project
GodForge
More writing
Chrome ships an LLM now — no API, no server, no rate limitExploring an enterprise repo without cloning it first