For years, my VS Code environment kept getting more complex.
More extensions, more automation, more tools supposed to make development easier.
On paper, everything looked efficient. In practice, I spent more and more time fixing side effects.
Files reformatted themselves on save.
Indentation changed unexpectedly.
Two projects could look different simply because an extension behaved differently.
The tools were supposed to help.
Instead, they were removing control.
The problem with automatic tooling
Automatic formatting is convenient — until it stops being predictable.
Some extensions rewrite code structure without real context.
Others apply different rules depending on language or local configuration.
Nothing is necessarily wrong, but the environment becomes unstable:
- invisible changes appear in commits
- code readability changes between projects
- and it becomes harder to understand what actually changed
At some point, I realized I was spending more time supervising my editor than writing code.
What I actually wanted
I didn’t want more automation.
I wanted fewer surprises.
A simple and predictable environment:
- no automatic changes without intent
- consistent rendering across projects
- formatting executed only when necessary
The goal was not to make the editor smarter,
but to make it more reliable.
Moving back to control instead of automation
I gradually removed everything that modified code automatically.
No format-on-save.
No extensions rewriting files in the background.
No hidden actions.
Instead, I adopted a simpler approach:
- cleanup actions are manual
- scripts run locally
- every modification is intentional
The code is never modified unless I explicitly decide to do it.
At first this feels less modern, but it has an immediate benefit:
everything becomes predictable again.
What changed in practice
The biggest change wasn’t technical — it was mental.
Less friction.
Fewer broken files caused by unexpected formatting.
A more stable and readable codebase over time.
My editor stopped making decisions for me.
It became a tool again.
All my projects started behaving the same way, regardless of system or context.
Local backups changed how I work
Another important change was how I handled file safety.
Instead of relying on extensions or external tools, I added a simple local backup system: every time a file is saved, a timestamped copy is created locally.
It’s not complex, but it removes unnecessary stress.
A file can be modified, broken, or even deleted by mistake — a previous version still exists.
This kind of local safety changes the way you work.
You experiment more freely because losing a stable version of your code becomes much less likely.
Conclusion
Over time, this setup became reusable because I wanted the same stability across projects.
But the real change wasn’t the configuration itself.
It was the mindset behind it:
tools should never modify code without intent.
Eventually, this environment evolved into a reusable setup at Palks Studio, but the main benefit remains the same — clarity, control, and predictability.