Fnthom

Inspiration

As of now, every popular coding agent strongly abstracts away code: the developer provides a prompt and the agent summarizes what was generated. Developers are increasingly forced to use coding agents to match industry outputs, all while bearing a lack of agency from that same volume of code. As an increasing amount of code in the world has no human who has actually read it, our goal is to provide developers the option to keep up with their agent and understand the code when it matters most.

What it does

Our project is a VS Code extension that lets developers digests AI generated changes one component at a time. We do this by providing a harness that forces agents to split up its work into proposals. Each proposal involves a change to a separable block code (Eg. functions, interfaces, classes), its purpose, and its connection to the rest of the project. A major paradigm that we use is a graph where nodes are blocks of code and edges are predefined relationships Clicking a node opens the corresponding code, highlights its lines, and displays an explanation. Planned functions are visually distinct from implemented ones. Users can accept it, request a rework, or ask follow-up questions before the modification happens. Once the plan is accepted, the extension applies the changes and runs configured checks.

How we built it

We built the extension in TypeScript, with a React interface inside a VS Code webview. React Flow renders the interactive function graph, and the TypeScript compiler API helps analyze the code and its connections. Zod validates structured messages between components.

We created an adapter for the Factory Droid SDK and a scripted demo agent so we could develop and demonstrate the workflow without API access. The default demo walks through adding caching to a small weather API. We use Vitest for automated testing and Vite and esbuild to bundle the interface and extension.

Challenges

A major challenge was keeping the plan, generated code, and graph consistent. Rejecting one function can affect later functions, so reworking a proposal also needs to update the remaining plan.

Graph edges grow exponentially with number of nodes, which means large projects will have an incomprehensible number of edges. We solved this by following abstraction hierarchies and "merging" nodes as the user scrolls out.

We also needed to distinguish proposed behavior from code that actually exists. That shaped how we display planned nodes, link explanations to source, and show check results. Keeping graph navigation accurate after code changes was another important part of the implementation.

What's next

We want to validate the live Factory integration across more repositories, improve graph readability for larger projects, and test the workflow with developers. We would also want to test this in a wide variety of environments, which will likely happen as we use this project ourselves.