> ## Content Index
> Fetch the complete content index at: https://vill.ar/llms.txt
> Use this file to discover other available public pages before exploring further.

# My Dev Stack as a Non-Developer
- URL: https://vill.ar/my-dev-stack-as-a-non-developer/
- Published: 2026-10-23T02:00:00.000Z
- Updated: 2026-10-23T06:42:06.000Z
- Author: Mike Villar

Every line of code in my projects is written by an AI agent. I come from marketing and product, so I know what the software should do and who it's for, but I don't write it myself. What I own is everything around the code: where it lives, how it runs, how it gets checked, and how it reaches production.

The popular name for this is "vibe coding." I don't like the term, because it suggests there's no structure behind it. There's quite a lot. This is a walkthrough of it.

## **Where I Started**

I started where most people do, in VS Code with an AI assistant built in. It was the obvious place to begin: it's where software gets made, so I assumed it was where I should be.

I noticed fairly quickly that I was barely using it as an editor. I wasn't writing code. I was describing what I wanted in a chat panel, waiting, and reading what came back. The editor was a very capable window I mostly kept closed. The work was also stuck on my laptop. If I closed the lid, the session stopped, and I couldn't check on anything from my phone.

What I needed was a place to assign work, watch it, answer questions, and review results. [Paseo](https://paseo.sh/?ref=vill.ar) is built around that, so I moved.

## **Paseo**

Paseo runs the agents. The daemon lives on a server, and I connect from a desktop client or a mobile client. Both show the same agents, workspaces, and terminals, and an agent keeps working whether or not anything is connected.

The feature I rely on most is permission requests. When an agent wants to do something outside its normal scope, it stops and asks, and I answer from whichever device is nearest. In an IDE I was the one doing the work and the assistant helped. Here the agent does the work and I approve it. The interface reflects that.

## **The Servers**

Three servers: one hosts Paseo and the agents, and the other two are production for two of my products. A third project's hosts several more. All three use a shared SSH key that never gets printed or committed. The Paseo server is shared with other agents and is where all the code generation happens.

## **Where Projects Live**

Project code sits on the server's disk, outside the Paseo container, and is mounted in for the agents to edit. Nothing lives inside the container: no code, no databases, no dependency installs. If Paseo breaks or needs an upgrade, I replace it and the projects don't notice.

Each project runs in its own Docker Compose stack, so projects share no runtime. Every project also has a small wrapper script that agents use to run commands in its containers. A fresh agent session has no memory of how a project runs, and it was too easy for it to install packages in the wrong place or start a second database. Giving it one blessed way to run things stopped that, and since I can't always tell a correct command from a plausible one, I'd rather make the correct one the only one available.

Every dev stack serves a preview on its own port, and I open those from any device. 

## **Worktrees**

Each agent gets its own git worktree, managed by Paseo, so several can work in the same repository at once without stepping on each other. One fixes a bug, another builds a feature, a third reviews a diff. When a task is done or abandoned, I archive the workspace. Since worktrees share a stash, I use temporary commits instead.

## **The Agents and Models**

I run four providers through Paseo, and switching between them doesn't change the workspace or the repository state. Only the model changes.

**Claude:** Opus 5.5, Fable 5.1, Sonnet 5.5, Haiku 5.5

**OpenAI/Codex:** GPT-6.1-Sol, GPT-6-Astra, GPT-6-Luna

**Kimi:** K2.8 Preview, K3, K2.7 Code Highspeed

**GLM:** GLM-5.3, GLM-5.3 Flash, GLM-5 Turbo

I match model and reasoning effort to the job: the top models at high effort for planning and changes that span many files, the lighter ones for scoped edits and quick questions.

Paseo also has patterns for combining agents. An advisor gives a second opinion on a task without taking it over. A committee of two high-reasoning agents steps back, finds the root cause, and writes a plan, which I use when I'm stuck. A handoff passes a task and its context to another agent. I found all of these useful at some point in my sessions,

I can't always judge whether an agent's output is correct, but I can cheaply get a second opinion from a different model family and notice when they disagree. A disagreement tells me to slow down.  
  
The handoff pattern which allows me to pass work to another model is particularly useful when I'm trying to stay within my plan budgets but would like to carry on work. 

## **Why I Pay for the Top Tier on All Four**

I subscribe to the top-tier plan for Claude, Codex, Kimi, and GLM. That's a lot of monthly spend for someone who doesn't write code, so here's why I think it's worth it: limits.

My usage doesn't look like someone chatting with an assistant. Agents run for long stretches, several in parallel, often at high reasoning settings, and advisor and committee sessions add more load on top. The models are good enough on every provider. What stops me is running out of allowance partway through a task. Because the agents run unattended, that usually happens when I'm away from the screen, and I come back to a stalled task. The top tier makes that rare.

Four providers also act as a safety net. If one hits a cap, I hand the task to another in Paseo and keep going. And a flat monthly plan is a number I can plan around, where per-token billing for this much agent time would not be.

## **QA**

My QA layer is [Playwright](https://playwright.dev/?ref=vill.ar), and it's deliberately cursory. I don't maintain a large end-to-end suite. I want to know a page loads, looks right, and works on a phone, and Playwright answers that well enough.

The agents write small scripts against a seeded dev stack. Each one signs in with a development session cookie, opens a page at a phone-sized viewport and a desktop one, and takes a screenshot, which I look at myself. The scripts log page errors and check for horizontal overflow, which is the mobile problem I see most. When I want to see how a page handles an awkward case, such as a very long title, the agent mocks the response instead of me creating the data.

It catches blank pages, broken layouts, console errors, and text running off a phone screen. It doesn't prove the logic is right. Lint, type checking, and unit tests run in CI, and Playwright sits on top as a visual check. As a non-developer reviewing from a phone, a screenshot is a format I can judge.

## **Deployment**

Agents write and test the code, and releases follow one path across my projects. Production steps need my explicit go-ahead.

Work happens on a branch in a worktree and gets checked against the dev stack. The pull request to main runs lint, types, and unit tests, plus a test build of the Docker images where a project ships them. Releases are cut from main only: the release script refuses to run unless I'm on main with a clean tree that matches the remote, then bumps the version and pushes a tag. The tag triggers GitHub Actions, which either builds images and pushes them to a registry or connects to the server over SSH and runs the deploy script. The server then pulls the update, backs up the database, runs migrations, restarts services, and health-checks the result.

Several details came from mistakes. Building images on the production server took 15 to 20 minutes, so Actions builds them and the server only pulls. Restarting the backend on every tag was killing long-running jobs, so the workflow compares against the previous tag and only deploys what changed. The backend reloads with a five-minute grace period, the web deploy keeps the previous build's static files so stale pages don't hit missing assets, and a concurrency rule stops deploys from overlapping. Any past tag can be re-run from the Actions tab, and credentials live in GitHub secrets.

## **MCP Servers**

### **Paseo**

[Paseo](https://paseo.sh/?ref=vill.ar) has its own MCP server, which lets an agent create workspaces, start other agents, read their activity, open terminals, and drive a browser. The advisor, committee, and handoff patterns depend on it.

### **Design research**

Left alone, an agent designs like an average of everything it has seen: a centered hero, three feature cards, generic spacing. I wouldn't brief a human designer that way, so I don't brief an agent that way. I give it references, and that's what gives it design taste.

[**Mobbin**](https://mobbin.com/?ref=vill.ar) for real product screens, interaction patterns, and multi-step flows, which is how an agent learns how shipped products handle onboarding, settings, and empty states.

[**Refero**](https://refero.design/?ref=vill.ar) for visual directions, websites, and user journeys, which is where an agent finds a direction to commit to.

[**Subframe**](https://www.subframe.com/?ref=vill.ar) for landing-page composition, typography, and visual direction. It isn't my source for complex product workflows.

These are three separate subscriptions on top of everything else, and I think they're worth it. The difference shows up in spacing, hierarchy, type choices, and how a flow is structured. For product UI I start with Mobbin and Refero, and for landing pages I add Subframe. 

Agents adapt what they find to the project's existing components and tokens. The references inform the design and don't override the codebase. They're for reference search by default, and generation credits or design-system changes happen only when I ask.

### fal.ai

[fal.ai](https://fal.ai/?ref=vill.ar) is a hosted catalog of generative media models behind one account, and I connect to it through its [MCP server](https://mcp.fal.ai/mcp?ref=vill.ar). Claude, Codex, and Kimi pick it up from their normal configuration. GLM agents don't, so a small Paseo plugin adds it to each new GLM agent. Runs are billed per use, so agents don't start generation unprompted.

I mainly use two models. Nano Banana 2.1 handles image generation and editing, usually in a batch of variations. My request history shows eight jobs in parallel, each taking 20 to 90 seconds. Bria's background remover handles cutouts in a few seconds each. An agent building a page can produce its hero image, illustrations, and transparent cutouts in the same session without me opening another tool.

## **A Typical Task**

I describe what I want in product terms: what it should do, who it's for, and what done looks like. Paseo creates a workspace and I pick an agent and model. The agent reads the repo's docs, works in the project's containers, and for UI work searches design references first. It asks permission when it needs it, and I answer from wherever I am. When it's done it runs its Playwright check, and I open the preview, look at the screenshots, and read the summary. If I'm unsure, a second agent reviews the diff. If it's right it goes through CI and the release path above. If not, I send it back with better instructions or archive the workspace.

Most of my time goes into deciding what to build, looking at the result, and checking it. That part of software work was always the part I did. The typing is what changed hands.

## **Working Across Devices**

Because the state, the code, and the runtime all live on servers, switching devices doesn't interrupt anything. I can start a task at my desk and follow it from my phone, and the device only needs a client and a connection. Several agents can work at once, and a mistake in a dev container stays in that container.

## **Limitations**

**I maintain the infrastructure.** The servers, mounts, wrapper scripts, deploy workflows, and ports are my responsibility.

**The Paseo host is shared.** Restarting services or changing its configuration can affect other agents.

**Credentials need discipline.** A shared SSH key is convenient, which is why it has strict rules.

**Review is the bottleneck, and I'm not the strongest reviewer.** Agents work faster than I can read. Second opinions help, but they don't replace understanding what I'm approving.

**Subscriptions add up.** Four top-tier model plans, three design tools, and fal are all paid separately. Limits are why I pay for them, but it's a real monthly cost.

None of the individual pieces is exotic: a few servers, Docker Compose, GitHub Actions, and a handful of models and subscriptions. What makes it work for someone who doesn't write code is the separation. Orchestration, code, runtime, and production each live in their own place, so I can replace or fix any one without disturbing the others, and the fact that I can check on all of it from my phone and "Vibe code" on the go is a huge bonus!