Lately I have been reworking my development environment. I brought in herdr to handle multiple AI agents, and moved from the JetBrains IDE I had used for years to VS Code.

Changing environments definitely slows you down at first. You relearn shortcuts, migrate settings, and stop at operations you used to perform without thinking. Even so, I decided it was a chance to review the daily work itself, not just to swap tools.

One of those is deployment.

Deploying with a single click

Until now I opened a terminal, checked the target project and environment, and typed the commands I needed. The work itself is not hard. But the less often a command is used, the more its details slip away. Small interruptions appear — looking up options again, digging an earlier command out of the history.

So I registered routine work — type checking, tests, data inspection, deployment — as VS Code Run Tasks. Now I pick a task from the list and it runs. Deployment is, so to speak, a single click away.

This is not sophisticated automation. It only replaces remembering and typing commands with a named operation. Even so, the cognitive load of deciding what to run and typing it correctly goes down. Typos become less likely.

It is a small improvement, but when one person handles design, implementation, testing, release, and operations, this kind of small switching cost is not negligible.

What organizations avoid can be optimization in solo development

In team development, a setup that only runs in one person’s environment is a problem. It matters that anyone can follow the same steps, and that the work continues when the person in charge changes. That is why standardized procedures and consolidation into CI/CD are called for.

Solo development is different. The user and the operator are basically just me. Rather than preparing something averagely usable for everyone, matching my own habits and train of thought is sometimes faster.

Build a development environment with little friction for me, not a general one. Put differently, this is optimization through person-dependence.

The word person-dependence usually carries a negative ring. But person-dependence is not bad in itself. The problem is depending on a person while ignoring headcount and the possibility of handover; optimizing for one person something that will be run by one person from the start is reasonable.

What may depend on the person is the operation, not the processing

That said, not everything may be shut inside the development environment.

If deployment is impossible without pressing a VS Code button, and what runs behind it is unknown, the convenience turns directly into a black box. When you change editors, or want to move to CI, you rebuild the mechanism from scratch.

So I think the actual processing should be defined as npm scripts or shell scripts, and the VS Code task should only call them.

• The real processing can be reproduced from the CLI
• Everyday operations can be run quickly from VS Code
• The same processing can be called from CI when needed

With this structure, VS Code is not a box that hides processing but a launcher that puts an easy entrance on existing commands. I can optimize the operations for myself and still keep the mechanism reproducible.

What may depend on the person is the way you operate, not the conditions under which the processing holds. I think this line matters in solo development too.

Six months from now, I am almost a different person

In solo development there is no handover to another person, but a handover to my future self still happens.

When I pick up a project I have not touched for six months, the fine steps and the reasoning behind decisions are lost to a surprising degree. At that point, settings only my earlier self understood, and commands that survive only in the terminal history, are barely different from an opaque mechanism someone else built.

Naming operations, as with Run Task, is not only a time saver but also simple documentation for my future self. Because I can choose the processing by purpose — release to production, check types, inspect data — I can resume the work even after forgetting the details of the commands.

But what runs when I press that name should stay readable as code. Holding both together makes the environment easy to handle for my present self and my future self alike.

Standardization can be extended when it becomes necessary

If developers increase in the future, or the release frequency rises, personal tasks may need to move to CI/CD. But there is no need to build an organization-oriented mechanism from the start, on the premise of a team that does not yet exist.

What matters is keeping a form that can be moved later. If the real processing can be reproduced from the CLI, I run it from VS Code now and call it from CI when the need comes. Only the entrance changes.

In solo development, over-standardizing has a cost too. Time spent generalizing settings, preparing documents, and making a mechanism anyone can use competes with time spent building the product. Prepare too much for future possibilities and you lose present speed.

So: optimize for the current headcount, but do not block the exit. That much feels about right.

Allow person-dependence, but not a black box

A solo development environment may be mine alone. Shortcuts, screen layout, the entrances to tasks — all of it may match my own thinking and operation. The speed gained there is a different kind of strength from standardization in team development.

But the processing behind the convenience should always be inspectable, and runnable from another entrance.

Allow person-dependence, but not a black box.

In the short term, progress drops because time goes into migrating and configuring the environment. Even so, as long as I carry everything from design to release alone, the effect of building an environment where I can move without hesitation lasts a long time.

I think this is not merely switching editors, but rebuilding my own development process, for myself.