My development server is where vibe-coding gets boring enough to work

Every fun AI experiment eventually turns into boring computer chores.

The first prompt is magic. The second prompt needs a package installed. The third one needs a .env file. Then something wants Docker, a callback URL, a cron job, a browser session, a vector database, a tunnel, a deploy token, or a terminal that doesn’t disappear when I close my laptop.

That’s why I keep coming back to one of the least glamorous pieces of my setup: my development server.

Not a production platform. Not a serious homelab. Just a persistent machine where the experiments can live long enough to become real.

What I was trying to do

The goal was simple: remove the “new project tax” from vibe-coding.

I wanted one place where I could:

• clone a repo and start quickly
• leave an agent running without babysitting my laptop
• keep deploy tools and CLIs already logged in
• run small background services like databases, queues, or memory stores
• test cron jobs and long-running automations
• keep secrets out of random project folders and chat transcripts

The laptop is still where I think. The development server is where things run.

That split matters more with AI agents than it did with normal coding. A coding agent is not just editing files; it might run builds, start browsers, inspect logs, install dependencies, generate screenshots, or sit on a task for twenty minutes. That feels fragile on a laptop. It feels normal on a server.

The shape of it

The setup is intentionally boring:

Laptop / phone
     |
     v
Development server
  |-- git repos and worktrees
  |-- Node, Python, Docker
  |-- GitHub CLI and Azure CLI
  |-- coding agents
  |-- local dev servers
  |-- cron jobs
  `-- scratch services

The important part is not the hardware. It could be an Azure VM, a mini PC, or whatever spare box is always online. The important part is that it has a stable identity and a warm environment.

When I come back to an idea, I don’t want to reconstruct the machine first. I want to git pull, run the thing, and remember why I cared.

Why it changes the loop

The biggest unlock is continuity.

On a laptop, an experiment feels temporary. It is competing with battery life, sleep mode, travel, corporate VPN weirdness, and whatever else I was doing that day. On a server, the project has a place to sit. Logs keep accumulating. Cron jobs actually fire. Agents can finish. A half-working demo can still be there tomorrow.

That changes the creative loop:

idea -> prompt -> running thing -> leave it alive -> inspect -> improve -> share

The “leave it alive” step is the underrated one.

For static demos, this site is still the clean end state: markdown file, git push, Azure Static Web Apps deploys it. But before something is ready to become a post, it usually spends time on the dev server as a messy folder with a local URL, logs, and a few half-deleted attempts.

That’s where the work happens.

What broke / what I learned

The server did not magically make development tidy. It mostly made the mess visible.

Disk fills up first. Node modules, Docker images, browser downloads, generated assets, and abandoned experiments add up quickly. The easiest server to use is also the easiest server to turn into a junk drawer.

Long-running things need names. If an agent, tunnel, or dev server is running, I need to know what started it and why. Otherwise “one quick experiment” becomes a process archaeology exercise.

Secrets need boring rules. A persistent server is convenient because CLIs and environment variables can stay configured. It is also dangerous for the same reason. The rule has to stay simple: secrets live in proper config or ignored env files, never in posts, prompts, screenshots, or commits.

Remote dev makes broken setup obvious. If a project only runs because of some weird state on my laptop, the server exposes it. That is annoying for five minutes and useful forever.

Agents like stable ground. The more I use coding agents, the more I notice that they benefit from a predictable environment. Same paths, same CLIs, same repo layout, same build command. Less context spent on setup means more context spent on the actual problem.

The rules I am keeping

I am trying to keep the server boring on purpose:

• every real thing gets a repo
• every throwaway gets a clearly named folder
• every project needs one obvious run command
• anything repeatable becomes a script
• anything public gets checked for secrets and personal data
• anything worth remembering gets written into the repo, not left in chat
• anything deployed has to pass the same build command the host will run

That last one is why this blog’s project doc is so strict about npm run build. The dev server is allowed to be messy. The deploy path is not.

Why I bothered

Vibe-coding is not just about better prompts or better models. It is about reducing the distance between “I wonder if…” and “here, click this.”

The development server helps because it makes the environment disappear. I don’t have to decide where the agent should run. I don’t have to reinstall the same tools. I don’t have to keep a laptop awake for a background task. I don’t have to turn every experiment into infrastructure before I know if it is worth keeping.

It is boring infrastructure for momentum.

And right now, that might be the highest-leverage kind.

Built with

• Tool: GitHub Copilot CLI
• Model: GPT-5.5
• Hosting: Azure Static Web Apps for this blog; the development-server pattern described here is for running experiments before they become posts or demos