Developers build muscle memory around opening a terminal as soon as they open a project in a code editor like VS Code to run the project locally. For a long time, it was my routine as well. I would open VS Code, then immediately open a terminal window, and start typing the same command I had already run tens of times before. npm run dev for React frontends, uvicorn app:main for FastAPI, and go run main.go for Go backends and then Docker Compose and watch commands. None of these commands were too lengthy or difficult to remember, but they were repetitive in each session.

The repetition started to create friction since I was manually rebuilding the same environment every time I opened a project. My typical full-stack setup included a Vite frontend, a FastAPI backend, PostgreSQL, Redis, and Docker Compose. Each service required a separate terminal tab and the same startup sequence each session. That was when I decided to experiment with VS Code Tasks to handle the repetitive startup commands automatically. A week later, it hadn’t replaced the terminal for me, but it had quietly reduced the manual work of every startup.

I stopped retyping the same commands every day

The repetition finally became obvious

My day-to-day workflow looked like navigating from one Vite project to another Next.js project, from a FastAPI backend to another Go backend, and from VS Code to Antigravity and Claude Code. One thing common in all these was opening a code editor and then immediately opening a terminal window to `cd` into projects' directories and run respective projects. Whether it was a Vite project or a Next.js project, I was always running the same command: cd ../frontend && npm run dev. And the same with FastAPI and Go backends; the uvicorn and go commands were common, respectively, as were the Docker Compose builds.

I was repeating the same commands daily; they weren’t hard, just redundant. I’d built muscle memory: open VS Code, then immediately start the backend. And in case there were any dependencies such as PostgreSQL or Redis, I needed to run them first and then finally the frontend. I was rebuilding the same environment every session.

When these started creating friction, I decided to try VS Code’s built-in task runner to reduce repetitive workflow setup. It was nothing new on the VS Code side, but I was experimenting with automation already built into the code editor I use. The setup was pretty simple; it created a tasks.json file with all the reusable commands and instructions as a script that can be called in a few clicks or a shortcut. The good thing about the setup was that it was living inside the project locally, so I didn’t have to remember which commands to run for each project.

This simple execution instantly removed the friction of opening multiple terminal windows each time. The terminal was still there, but the command execution became standardized. Most of my terminal usage wasn’t interactive problem-solving; it was repetitive execution.

One shortcut started my entire development environment

The terminal tab never opened

The real friction was when I was dealing with a full project startup and not just a single service. For one service, to be frank, I didn’t need a separate setup to start it. I could just open a terminal inside the code editor or a standalone terminal app like Termius and run npm run dev. The main friction started to build up when starting up a full-stack project. Vite frontend, FastAPI backend, PostgreSQL, and Redis needed to start and become ready; tasks can sequence commands, but you may still need health checks or wait scripts.

My previous workflow was opening one terminal window for the frontend and another to start or build the Docker container, waiting for the container to initialize properly, and then starting the backend. There were no technical difficulties, but it started to feel annoying because of the repetition at some point. What the task runner helped me do was to orchestrate the whole process in one single command or, to be precise, one single shortcut, Ctrl/Cmd + Shift + B. For each project, I combined three or four commands into one master task.

Since every project had a separate tasks.json file inside the project directory (.vscode/tasks.json), I didn’t have to change the command if the project backend changed from FastAPI to Go. I just had to hit the shortcut, and the task runner took care of everything. The workspace started initializing itself without any additional interaction. I was no longer assembling the environment step-by-step. I was already using the editor constantly, but the Tasks made the editor aware of the project workflow itself.

I still needed the terminal, just far less often

The terminal didn't disappear completely

Once I started using the built-in task runner, it immediately reduced the repetitive workflow setup, but didn’t entirely replace the terminal for me. There were times when I specifically needed to open the terminal window to troubleshoot issues. Whether it was debugging failing containers or checking logs manually, the terminal was the only place for it.

These workflows are interactive and unpredictable, unlike repetitive startup commands, things like monitoring running services or testing quick fixes. The task runner only helped me with the first part of the workflow; after that, the terminal stopped being the default starting point. But the interactive workflows still belonged in the terminal.

VS Code Tasks resulted in fewer terminal tabs and less manual setup. But it didn’t mean Tasks removed the complexity; they standardized the repetitive execution. Many devs probably underuse automation already built into their editor because terminals become habitual very quickly. They have the same muscle memory I had of using the terminal even when parts of the workflow no longer need manual interaction.

The terminal was still essential and part of my daily workflow. It just stopped being the first thing I opened every time I started a project.

The terminal is still there, just quieter

When I started experimenting with VS Code Tasks, my aim wasn’t to replace the terminal. After a week of usage, I found they were not supposed to replace anything. What VS Code Tasks did was to reduce the manual work of starting up each session. Once I started a project, I didn’t have to open the terminal window and start the services manually; instead, I could focus on the actual work. I still used the terminal for tasks that needed real interaction, such as debugging, troubleshooting, and one-off commands. After using VS Code Tasks for a week, I still knew the commands; I just didn’t type them from memory every session anymore.