VS Code

How I Got Into It

VS Code became my main editor because it was the place where everything I needed could live together. Code, terminal, extensions, git, AI tools, quick tests, all in one space. After a while it stopped feeling like an app and started feeling like the room I work inside.

I did not choose it for status. I chose it because it made sense and stayed useful.

The Learning Process

The hard part was not learning the editor itself. It was learning not to overload it. VS Code can become messy fast if you keep installing things just because they look useful. Over time I got better at keeping only what actually helped me build.

I also learned how important editor comfort is. When you spend enough hours in one place, small frictions become real. Good shortcuts, a clean workflow, and a setup I trust all matter more than they seem at first.

How I Use It Now

It is where I do most of my real technical work now. Next.js projects, scripts, quick experiments, debugging, edits across the stack, and day-to-day work with GitHub. It is also where Claude and Codex fit most naturally into my process.

Because my work moves between front-end, backend, automation, and deployment, I need one place that can keep up with all of that without making me feel scattered. VS Code does that well.

What It Changed

It made coding feel less segmented. I do not feel like I am switching environments every time the task changes. I can stay in flow longer, which matters a lot for how I work.

It also made AI-assisted building feel practical instead of theoretical. Once those tools lived inside the same environment as the code, they became part of the workflow rather than a side experiment. That was a real shift for me.

Related

Claude and Codex · GitHub · Next.js · Node.js · AI-Assisted Development