I want to establish a simple and repeatable workflow for how I set up and use my Windows machine. The goal is not to install every developer tool available, but to create a fast, clean environment where AI can take care of much of the mechanical work while I focus more on architecture, problem solving, and judgment.

Windows Terminal as My Daily Driver: I would like to stop using cmd.exe or the old PowerShell as my primary terminal experience and instead use Windows Terminal, with PowerShell 7.x as the default profile. Windows Terminal is the application, while PowerShell and cmd.exe are shells that run inside it.

The main advantages are tabs, split panes, better copy/paste, customizable themes, and GPU-accelerated rendering. The GPU acceleration is for rendering the terminal UI itself—text, scrolling, cursor, etc.—not for accelerating Python, PyTorch, OpenGL, or other GPU workloads. For someone who constantly has Claude Code, Python scripts, Git, MCP servers and other processes producing terminal output, this makes the overall experience smoother.

Git and Python Environment: I want to configure Git globally so that basic settings don’t need to be repeated for every repository. For example, setting my name, email, and core.autocrlf=input globally gives me a consistent Git environment on Windows. I also want to use an SSH agent so I don’t have to repeatedly enter my SSH key passphrase when pushing code.

For Python, my default practice is to create a .venv for each repository. This keeps dependencies isolated between projects, and VS Code can automatically detect .venv and use it as the Python interpreter. Manually running Activate.ps1 is not necessarily required; activation mainly affects the current terminal session, while VS Code can directly use the selected interpreter.

VS Code will be my main coding cockpit, with the Python, Pylance, GitLens, PowerShell, YAML and Excel Viewer extensions. I also like simple automation such as autosave and format-on-save. The philosophy is to let the tools handle small things automatically rather than spending time managing them manually.

Keep Git and OneDrive Separate: One principle I want to follow is simple: Git repositories never go into OneDrive. OneDrive is for documents and other non-code assets; code belongs in Git and GitHub. I also prefer a relatively flat project structure rather than deeply nested folders and duplicate copies of projects.

Credentials should never be committed into Git history. Project-specific configuration should stay associated with the project, while secrets should be handled through appropriate environment variables or credential-management mechanisms.

I also want to develop a stronger daily backup habit. For every active coding project, git status, commit and push to GitHub should become part of the normal workflow rather than something I remember to do occasionally.

Performance thoughts: For a development workstation, especially one used heavily for AI and quantitative work, I want to remove unnecessary performance bottlenecks. When plugged in, a High Performance power plan can make sense.

I may also consider Windows Defender exclusions for my active development folders. Scanning every file operation can slow down Git, Python package installations, virtual environments and projects with thousands of small files. This should be treated as an optional optimization, however, because excluding a folder also reduces antivirus protection. I would only consider it for controlled development folders, not system directories or arbitrary downloaded files.

Moving Toward Local AI

The bigger change is that I want this workstation to become an AI development machine, not just a traditional coding laptop.

If I get a sufficiently powerful NVIDIA GPU with enough VRAM, I want to experiment with local LLMs. The basic stack is quite simple:

Open WebUI
   ↓
Ollama
   ↓
Llama / Qwen / DeepSeek / other models

Open WebUI is the browser-based interface, while Ollama is the local LLM runtime and API server. It handles running the model locally and typically exposes an API on port 11434.

Then I can build applications around it:

Python application
       ↓
   LangChain
       ↓
     Ollama
       ↓
    Local LLM

Ollama runs the model; LangChain helps orchestrate what happens around the model, including workflows, tools and potentially MCP.

MCP + Local AI

This is where I think the architecture becomes particularly interesting. MCP gives an AI model access to tools such as SQL, SharePoint, Snowflake and other internal systems. A local LLM can become another “brain” behind that infrastructure.

Eventually, I could have a local AI gateway that decides which model should handle a request:

             Query
               ↓
       Local AI Gateway
               ↓
        Policy / Router
          /          \
         ↓            ↓
    Sensitive     Non-sensitive
         ↓             ↓
      Ollama       Cloud AI
      Local       Claude/Devin

The important point is that the routing decision happens locally. I don’t want a cloud agent such as Devin to receive sensitive information and then decide whether it is sensitive—the information has already left the local boundary.

The goal is therefore not simply to replace cloud AI with local AI. Rather, I want to build a workflow where local models, cloud models, MCP, Git, Python and my development tools work together, with each doing what it is best at. Ultimately, I want AI to handle more of the repetitive coding work while I spend more time on the parts that actually require judgment: designing systems, solving problems, and deciding what should be built in the first place.