2026-07-23 · SALVAGE · AI IDE MEMORY · ~8 MIN READ
The PyQt5 AI Debugger
We Actually Built
i keep hearing “we should build an IDE” like the past never happened... it did. it was local. it was PyQt5. and it was more honest than a lot of the demos floating around now.
this is not a launch post. this is a memory + inventory post. the repo still lives at Victor-Dixon/AI_Debugger_Assistant ... local path D:\repos\AI_Debugger_Assistant. the product name in the window title was blunt on purpose: Advanced AI Code Builder/Debugger.
the good parts were real UI and a real file workflow. the bad parts were also real... and we are not rewriting that history as a win.
The timeline
the portfolio problem is provenance. people remember "the IDE project" and compress three different things into one fuzzy myth. the cleaner map looks like this:
2023-2024
|
v
PyQt5 AI Debugger
Desktop shell
Multi-file generation
Placeholder AI
|
v
Dream.Office
Coordination
Governance
Evidence
Runtime
|
v
Next
Native Coding Agent
One execution surface
that is easier to trust than a vague claim that we have been building AI IDEs forever. here is exactly what existed. here is what worked. here is what did not. here is what survives.
What we had
the root surface was codecrafter.py — a PyQt5 QMainWindow with project dropdown, prompt box, AI response pane, code editor, and build/execution output. that is not a sketch in Figma. that is a desktop shell you can click.
and yes — there was a file-manager shape to it. not VS Code’s full tree panel in the current root file... but the workflow that mattered:
- Select Save Location via QFileDialog.getExistingDirectory
- multi-file write into that directory (# FILE: ... parser)
- ASCII directory tree shown after build so you could see the project layout
- JSON project definitions loaded as templates before generation
if your memory is “PyQt5 + file manager,” that tracks. the intent was: pick a folder, generate a scaffold, see the tree, run/debug. a local operator loop before we had a swarm control plane.
What we would keep today
Local-first desktop workflow. no pretending a hosted chat tab is an IDE. the ambition was desktop... files on disk... run output in the same window.
Multi-file project generation. the builder did not stop at one paste box. it asked the model for a whole tree and tried to materialize it.
Project templates. JSON project definitions were loaded before generation. crude, yes, but the idea was right: the operator should choose a shaped build lane, not just type into an empty prompt.
Explicit save location. asking where files should land is a small thing until a tool writes into the wrong folder. that file workflow is worth preserving.
Planner / dispatcher salvage. under ai_agent_project/ there is planner / dispatcher / task-intake work that still has passing tests when you run that lane explicitly. salvage does not mean trash.
Docs finally told the truth. PRD, production readiness, source classification — as of the 2026-07-03 refresh — stop calling this production-ready. that honesty is an asset.
What we would not keep
placeholder AI is not a product. it is a costume.
run_ai_generation() still returns a stub multi-file string. the GUI looks alive. the brain is not plugged in.
Execution was not sandboxed. generated code could run on the host without a hard timeout/sandbox gate. that is a release blocker, not a footnote.
Alternate GUIs rot. ai_agent_project/src/gui/main_window.py fails to compile. another “GUI” file is really an unsafe exec() error detector. so the repo looks bigger than the working surface.
PyQt5 tests are environment-fragile. default pytest can pass scaffold tests while test_codecrafter.py sits blocked without PyQt5 in CI. green boards can lie.
and the portfolio confusion is real: people remember a Rust-terminal IDE, a PyQt debugger, a Dream.OS coding agent... and mash them into one myth. today the locate pass found no Rust/Tauri IDE crate on this machine. what we can prove is the PyQt5 debugger shell. recover that truth before inventing a new repo.
Where it is now
status label from the repo itself: development / stabilization / salvage review. not shipping as Dream.OS IDE. not deleted. classified.
Dream.OS moved the agent brain into DreamVault/runtime/coding_agent — inspect, edit, test, diff, close with evidence. that runtime is the integration target. the old PyQt shell is a UI candidate to recover and wire... not a second agent core to rewrite from scratch.
operator decision language right now is blunt: RECOVER_EXISTING_AI_IDE, new_repo: false, finish coding-agent parity before polishing a full Cursor clone.
now: salvage classify → native coding-agent runtime → recover UI later → wire, don’t rewrite
Why publish this
because the swarm keeps almost building the same desktop dream under a new name. the antidote is a public receipt: here is what existed, here is what worked, here is what was theater, here is the recover path.
if you are reading this as a buyer or a peer builder... the lesson is not “AI IDEs are fake.” the lesson is: a window and a file picker are easy to show. a safe generate → write → test → approve loop is the actual product. we started the window early. we are finishing the loop now.
three days later, a Weghachi audit would reveal exactly the same lesson from another direction: the missing product was not another editor. it was a governed execution loop.
Quiet next step
no fake “IDE launch” CTA. if you want the live swarm story, stay in the build log. if you want help scoring an automation bottleneck in your own shop, that is Bot Lab — not this salvage post.
Related: A Founding Pass Is Not Another Tool Tab · Execution Contracts, Not More Scripts · The Audit That Found Our Product Boundary