From the Terminal to a Visual Workflow

The Problem

For months my entire workflow lived in a WSL terminal. It worked, in the sense that projects shipped, but working command by command meant I only ever saw one narrow slice of the system at a time. I could run the deploy, tail the logs, and edit the file, yet the way those pieces fit together as a technology stack stayed fuzzy. I was executing steps instead of understanding conditions.

On top of that sat real clutter. My home directory had accumulated loose scripts, backups, and one-off project folders. My editor carried more than three dozen extensions, many left over from college coursework, pointing at settings and toolchains I no longer used. Every session started with a low-grade tax: visual noise, stale configuration, and tools competing for attention. If you have ever opened your environment and felt tired before typing a single command, you know the feeling.

Step One: Remove Before You Add

The temptation was to install more tools. Instead, the first pass was pure subtraction, done deliberately and in order:

• Consolidated the home directory. Everything in ~ was reorganized into four top-level folders: websites/, business/, personal/, and a gitignored archive/. Old site copies, tarballs, and a retired bare repo, hundreds of megabytes of "just in case," moved into the archive where they no longer cluttered daily navigation.
• Audited every editor extension. Each one had to justify itself against the current workflow, security and automation work, not past coursework. Twenty-two class-era extensions were removed: an entire Java toolchain, a Jupyter stack, unused cloud toolkits, and duplicate AI assistants.
• Cleaned the settings behind them. Removed configuration keys pointing at class folders from semesters ago and telemetry settings for services no longer installed. Also tightened workspace trust from "open everything" to "prompt first," a small change with real security value when you handle untrusted files.
• Kept the road back open. Nothing was destroyed. Archived material still exists, and any removed extension is one click to reinstall if a course or project needs it again. Decluttering is not deleting your history, it is moving it out of your working view.

The result was a baseline of sixteen extensions, each with a job: Python tooling, Docker, GitLens, remote development, and a handful of others. Knowing exactly what is installed, and why, turned the editor from an attic into a workbench.

Step Two: Build the Visual Workflow

With the noise gone, each repository got its own .vscode/ configuration so the editor adapts to the project instead of the other way around:

• Recommended extensions per repo, so opening a project surfaces exactly the tools that project needs.
• Tasks wired to real commands. Deploys, test runs, log tailing, and sitemap regeneration are now one keystroke from the command palette instead of a command recalled from shell history.
• API endpoints as files. A REST Client file in the website repo holds every monitoring-agent endpoint, with secrets kept in a gitignored env file. Testing an agent went from assembling a curl command to clicking "Send Request" above a saved definition.

Then came the layer that genuinely changed how I think about the work: MCP connectors and AI tooling running inside the editor. Model Context Protocol servers let an assistant reach the things around the code, calendars, documents, deployed services, while extensions like GitLens and the Docker tools make the state of the system visible instead of queryable. The terminal is still there, embedded, one pane among several rather than the entire world.

The Results

The surprise was not speed, although it is faster. The surprise was comprehension. When the file tree, the git diff, the running task, and the API response are all on screen at once, you stop memorizing steps and start seeing conditions: what state the system is in, what a change touches, and what has to be true for the project to move forward.

• The stack became legible. Relationships I had been reconstructing in my head every session, which function serves which endpoint, which config drives which deploy, are now simply visible.
• Context switching got cheap. Each repo opens with its own tools and tasks ready, so moving between the website, the security lab, and business projects no longer means mentally reloading everything.
• Creativity went up. With MCP connectors and the right extensions, ideas move from "I wonder if" to a working experiment in the same sitting. Less friction at the start means more attempts, and more attempts is where the interesting work comes from.

Lessons Learned

If you work in tech and feel overburdened by your own environment, you are not behind, you are carrying accumulated weight that nobody scheduled time to remove. This project convinced me the fix has an order of operations:

• Subtract before you add. New tools layered onto clutter just become more clutter. The cleanup is what made the upgrade land.
• Archive, don't agonize. Moving old work out of view is reversible, which makes it easy to actually do. Nothing here was deleted, only relocated.
• Make the stack visible. The terminal teaches you commands. A visual environment teaches you the system. Both matter, but the second one is where understanding compounds.
• Let each project declare its own needs. Per-repo configuration means the environment carries the context so you don't have to.

What's Next

The workflow is now the foundation everything else runs on: the website monitoring agents, the home network security lab, and client work all operate out of the same clean, per-project setup. Next up is deepening the MCP layer so more of the surrounding business context is reachable from inside the editor.

Interested in the Details?

If you're feeling buried by your own setup and want to talk through the cleanup process, the per-repo configuration approach, or how MCP connectors fit into a security-focused workflow, I'd be happy to walk through it.

• Email — [email protected]
• LinkedIn — MFranklin, LLC