My development stack for working with AI on Windows

Installing another development tool takes five minutes. Keeping it updated, configuring it, understanding its quirks, and getting an AI agent to use it is a whole different story.

Not long ago I went through everything I had installed on Windows and ended up changing my criteria. Instead of looking for "the best app" for each thing, I started asking myself something much more practical: can Claude Code, Codex, or Gemini CLI work with this without me having to click through it for them?

That filter narrowed the list quite a bit. My original stack was around 30 tools, and the criteria ended up being pretty specific: command line, readable files, useful logs, and APIs.

The terminal became important again

For years many tools tried to hide the terminal behind more comfortable interfaces.

With coding agents, something curious is happening: the terminal has the advantage again.

An agent can run a command, read the output, detect an error, modify a file, and try again. That sequence fits much better with a CLI than with an application designed around buttons, windows, and menus.

That's why my core is now pretty small:

• VS Code as my main editor.
• Windows Terminal to centralize terminals.
• PowerShell 7 for automation.
• Git for versions and changes.
• GitHub CLI or Azure DevOps CLI to avoid jumping to the browser.
• ripgrep to search text fast.
• jq to work with JSON.

GitHub describes its CLI precisely as a way to bring pull requests, issues, and GitHub Actions to the terminal, reducing context switching: GitHub CLI.

That kind of tool fits especially well with an agent.

Claude Code, Codex, and Gemini CLI change how you choose tools

Here's the biggest shift.

Before, I chose a tool thinking about how I was going to use it. Now I also think about how the agent will use it.

Codex, for example, already works on Windows, and OpenAI presents it as a tool capable of working with local files, repositories, and terminals. The current ChatGPT app also integrates Codex within the same environment. OpenAI

Gemini CLI follows a similar approach. Google recommends Node.js 20 or later and Windows 11 24H2 or higher for use on Windows. Gemini CLI documentation. GitHub

The important point isn't deciding which of the three "wins."

It's preparing an environment where you can switch agents without rebuilding the way you work.

One tool per job

This rule is the one that let me remove the most programs.

I don't need three API clients, four editors, and two tools that do practically the same thing.

It doesn't mean the alternatives are bad. It means every additional program introduces another update, configuration, and behavior that both I and the agent have to understand.

Bruno started making more sense to me than Postman

Bruno is a good example of the kind of tool I look for.

Its collections are saved as text files inside the repository. That means they can go into Git, have branches, revisions, and comparable changes just like any other file in the project.

Bruno's own documentation defines it as a "Git-native" API client with no mandatory cloud dependency. Bruno API Client. Bruno

For working with an agent, that has an obvious advantage: it can read and modify those files directly.

It no longer has to learn where a certain button is inside an interface.

Playwright fits perfectly too

Automated testing is another area where AI can work quite well.

Playwright can generate traces that include browser activity, screenshots, and snapshots. When a test fails, you have concrete evidence the agent can inspect instead of just telling it "it doesn't work." Playwright Tracing. Playwright

That detail changes the cycle a lot:

it failed → we see what happened → we fix it → we run it again.

The more observability a tool has, the more useful it ends up being with AI.

For Azure I prefer Bicep

Here I also simplified things.

I work mainly with Azure, so in my projects Bicep makes a lot of sense. Microsoft defines it as a declarative language for deploying Azure resources in a repeatable and consistent way. Microsoft Learn: Bicep. Microsoft Learn

Terraform is still very useful when you need to work with multiple providers.

But automatically throwing it into any Azure project can add a layer you may not need.

The question I try to ask myself now is less "what tool do more people know?" and more "what complexity do I actually need here?".

PHP on Windows has an uncomfortable decision

Laragon is still one of the most comfortable experiences I've used for local web development.

The catch is the license.

Since Laragon 7 it's no longer completely free. Unlicensed use is reserved for non-commercial purposes and commercial use requires a license. Laragon currently publishes an annual commercial license of 49 dollars per device and a perpetual one of 149 dollars. Laragon Pricing. Laragon

If you build sites for clients, this matters.

The alternative that makes the most sense to me if I want to keep the environment free is DDEV.

DDEV is designed for reproducible, versionable, container-based environments. On Windows it can work with WSL2 and Docker, and its documentation even recommends an installation with Docker CE inside WSL2 for a good portion of users. DDEV. DDEV Docs

It's a bit more technical at first.

In exchange, the project describes its own environment and that environment can travel with the repository.

For an AI agent that's an advantage once again.

The stack I want doesn't try to hide what's happening

That ended up being the pattern.

I prefer a tool that lets me see:

• what command it ran;
• what file it modified;
• what error it received;
• what result it produced;
• and how to repeat the operation exactly.

That's where seemingly small tools like jq or ripgrep end up having a lot of value.

A nice interface can save me a few clicks.

An automatable tool can save me the entire process.

What about graphical tools?

I'm not eliminating Photoshop, DaVinci Resolve, or similar applications.

There are tasks where a visual interface is still clearly better.

The shift is in not asking AI to work the way it works worst.

For video, for example, I can use the agent to prepare names, transcriptions, subtitles, files, and automations. FFmpeg can handle many repetitive processes.

Then I do the visual part where it makes sense to do it manually.

The separation works quite well.

What I take away

My environment ended up being less spectacular than I imagined.

And that turned out to be good.

I no longer try to install every new tool that comes out. First I check if it covers something I don't actually have solved, and then I see how automatable it is.

My current filter looks like this:

1. Does it have a CLI?
2. Does it save its configuration in files?
3. Does it produce logs or results that are easy to read?
4. Can it be versioned?
5. Can an agent use it without depending on clicks?
6. Do I already have another tool that does the same thing?

If it fails too many of those questions, I probably don't need it.

Conclusion

The arrival of coding agents made me change an idea I had taken for granted for years.

The best environment is no longer necessarily the one with the most tools or the one with the most interfaces.

For me, it's the one that allows me and the agent to work on the same pieces.

Files.

Terminal.

Git.

Logs.

APIs.

That's where Codex, Claude Code, or Gemini CLI stop feeling like a chat that writes code and start working as a real part of the development environment.

And curiously, to get there I had to install fewer things.