Flightdeck: an IDE we built to direct and supervise AI coding agents
Flightdeck is an open source IDE, started by VLO Labs, for directing AI coding agents instead of typing code. It draws each project as diagrams generated from its code and holds the agent's actions for approval.
- Industry
- Software development tools
- Project type
- Open source project
- Status
- Open source under the MIT license, started by VLO Labs
- Platforms
- macOS app, Browser interface on the local machine
The challenge
AI coding agents such as Claude Code and Cursor do most of their work in a terminal, which shows a stream of text and file names. It does not show what the system looks like or where a change is landing. Hand-drawn diagrams go out of date as soon as the code changes.
Agents also need supervision that does not depend on what they report. In early testing, an agent said a command had run and created a file when that command had in fact been refused. Two agents working in the same folder can collide. And any permission file kept inside a project is a file the agent could edit to give itself more access.
Our approach
We built Flightdeck as an IDE for someone who directs code rather than types it. Diagrams take the place of the file tree, chats take the place of the code editor, and code can be viewed read-only when needed. Each chat runs the agent's own unmodified command-line program, so Flightdeck adds visibility and control around the agent without replacing it.
Before building features, we tested the mechanics the design depended on: whether an agent's action can be held until a person answers, whether a run can be stopped and resumed, and whether the login in use can be checked. Those tests corrected the first plan on what happens when an approval times out.
Flightdeck is deliberately small in scope: a single-user tool with no hosted service and no accounts, and its README says to expect rough edges. It was also built with the kind of agents it supervises. Of the 75 commits on the public main branch, 71 list Claude as a co-author.
What we built
Maps generated from the code
Three views per project: architecture, data model and end-to-end flows. A reader can drill into a box, see which files implement it, and see when the code has changed since the map was generated.
Discuss and Build chats
A Discuss chat cannot change files and can only run shell commands known to be read-only. A Build chat can make changes under the project's rules, and only one chat at a time can hold a project's edit lock. Boxes selected on a map are attached to the message, and boxes light up as the agent reads or edits their files.
Approval cards and per-project rules
Before an agent uses a tool, Flightdeck allows it, refuses it, or shows a card and waits for a click. Anything that matches no rule gets a card, and a card left unanswered expires with the action refused.
Plan-first changes
In Discuss, the agent can propose a change drawn over the current map. A person approves one version, Build works from that version, and the result is checked against it afterward.
Requirements workspace
Requirements and feature specs are kept as plain Markdown in the project's own repository, with stable ids. Approving a document freezes that text, and Build receives the approved wording rather than the draft.
macOS app and installer
Opening Flightdeck.app starts the server and quitting stops it. The app runs its own copy of the code, so a chat editing Flightdeck cannot change the running server, and the installer refuses to update while a chat turn is running.
A choice of two agents
Each chat runs on Claude Code or on Cursor's command-line agent, with the same cards, rules, modes and edit lock on both.
Engineering highlights
Limits the agent cannot edit
Approval rules live in Flightdeck's own database, never in the project, and are evaluated outside the agent. The agent's edit tools are refused on requirements files in every mode. Every decision is stored with what decided it.
Maps that separate evidence from inference
A read-only agent generates each map, and Flightdeck validates it before saving. Duplicate ids and circular nesting reject the map, and paths to missing files are dropped. A connection without a citation to a real file is kept but shown as inferred.
Approved versions that cannot be rewritten
Database triggers refuse edits and deletes on plan versions and requirement approvals. Each plan version records the state of the code it was made against, and a stale plan cannot be approved until it is checked again.
Checking results against the code, not the diagram
After a build, each planned item is reported as Verified, Missing, Unexpected or Needs review, using git changes, the files involved and citations in the code. An item that appears only in a regenerated diagram is never Verified.
Failing closed on the second agent
Cursor runs depend on Flightdeck's hook to stop unapproved actions. The hook refuses actions if Flightdeck cannot answer, and a run is ended if a tool ran without passing through it.
Local by default
By default the server listens only on the machine itself and refuses requests from other websites. A run also stops if the agent reports any login other than the user's own, so a stray API key cannot silently change how usage is billed.
Where it stands
- Public source code
- Published on GitHub under the MIT license
- Work on the public branch
- 75 commits from October 10 to November 3, 2026
- Automated tests
- 103 test cases in 20 test files
- Connections on Flightdeck's own architecture map that cite source code
- 60 of 61, on the map generated October 11, 2026
Technology
Links
Related services
Have something similar in mind?
Tell us what you need to build and we will give you a straight answer on how to approach it.
Get a free consultation