AI for Repeatable Systems, Not Vibe Coding

I watched a developer on Twitter celebrate that they had "vibe-coded" an entire SaaS app in a weekend with AI. The demo looked impressive. Then someone asked about tests. About deployment. About what happens when the second feature conflicts with the first. No answers. The repo went quiet a week later.

That is the vibe-coding trap. AI is extraordinary at generating code — but if you use it to improvise every project from a blank prompt, you end up with a collection of unrepeatable prototypes instead of a compounding engineering system.

I use AI differently. I use it to build the things that make every future project faster: CLIs, scaffolds, test harnesses, agent skills, deployment scripts, and plugin templates. The AI output I care about most is not the feature code — it is the infrastructure that makes feature code reliable and repeatable.

The problem with ad-hoc prompting

Vibe coding works like this: open a new chat, describe what you want, accept whatever the AI generates, fix the errors manually, ship it. Next project, start over.

The issues compound fast:

• No accumulated context. Every session starts from zero. The AI does not know your conventions, your schema patterns, your deployment targets, or your test expectations.
• Inconsistent patterns. Monday's AI session uses one auth pattern. Tuesday's uses another. By Friday you have five approaches to the same problem across five features.
• No regression safety. Generated code is not tested against your existing system. It works in isolation. It breaks when it meets reality.
• No leverage. The work you did yesterday does not make today easier. You are paying the same prompting cost for every task.

This is fine for throwaway prototypes. It is not fine for production systems that need to survive longer than a demo.

How I actually use AI

Building repeatable tools, not one-off features

When I need something more than once, I build a tool for it. AI helps me write that tool faster — but the output is a durable artifact, not a chat transcript.

Examples from the LaunchThat ecosystem:

• Plugin scaffold CLI. Every new Portal plugin starts from the same template: Convex component schema, hook registrations, admin settings page, test stubs. The CLI generates all of it from a plugin name. I built it once with AI assistance. Every plugin since then starts from a consistent, tested base.
• Test harness generators. Integration tests for Convex mutations follow a pattern: seed data, execute mutation, assert state, clean up. AI helped me build a generator that produces test files from a mutation signature. New plugins get test coverage from day one instead of "we will add tests later."
• Deployment scripts. Cloud-init templates, Docker Compose configs, Helm chart values — these follow patterns. AI helped me write parameterized generators. New infrastructure spins up from configuration, not from re-prompting.

The pattern is always the same: use AI to build the system that builds the thing. Not the thing itself.

A stable base, then extensions

Portal is the clearest example. The core platform — authentication, tenant isolation, plugin hooks, role definitions, notification bus — was built carefully with AI assistance over months. Every architectural decision is documented. Every boundary is tested.

When I build a new plugin, I am not vibe-coding a new app. I am extending a known system. The AI session starts with context about the hook system, the Convex component interface, the admin settings patterns. The plugin I build on Tuesday is structurally identical to the one I built on Monday. The only difference is the domain logic.

This is what separates tool-assisted engineering from vibe coding. The base is stable. The extensions are predictable. AI accelerates both, but neither is improvised.

Compare this to the alternative: starting every plugin from scratch, re-prompting for auth patterns, re-discovering the settings page API, re-building the test structure. That is the vibe-coding version of plugin development. It is slower, more error-prone, and produces inconsistent results.

Agent skills and tools: the compounding layer

The most impactful thing I have built with AI is not application code. It is the set of agent skills and tools that every future AI session has access to.

What agent skills are

An agent skill is a documented, reusable instruction set that an AI coding agent can read at the start of a session. It contains:

• The context the agent needs (architecture, conventions, file locations)
• The patterns it should follow (naming, testing, error handling)
• The tools it has access to (CLIs, scripts, MCP servers)
• The constraints it should respect (security boundaries, dependency rules)

I maintain skills for:

• Release and deploy workflows — how to cut a release, which deploy hooks to use, how to triage CI failures
• Plugin development — the hook API, the Convex component interface, the admin settings contract
• Infrastructure provisioning — cloud-init patterns, Docker setup, Cloudflare tunnel configuration
• Frontend patterns — component conventions, Tailwind usage, accessibility requirements

Why this changes everything

Without skills, every agent session is a cold start. You explain your architecture. You describe your conventions. You correct the same mistakes. You lose 20 minutes of context-setting before any real work begins.

With skills, the agent reads the skill file and starts with your full context loaded. It knows your auth pattern. It knows your test structure. It knows your deployment targets. The first output is already aligned with your system instead of fighting it.

This is the difference between a new hire who has read the docs and one who has not. The AI is the same model. The skill file is the onboarding.

Tools compound too

Beyond skills, I build MCP tools and CLI commands that agents can invoke directly. These are not prompts — they are executable capabilities:

• A CLI that scaffolds a new plugin with all required files
• Task management tools that track progress across sessions
• Deployment scripts that can be triggered from an agent context
• Linting and validation commands scoped to the current work

The agent does not need to figure out how to deploy. It calls the deploy tool. It does not need to remember the test file structure. It calls the scaffold command. The tools encode decisions I have already made so the agent does not have to re-derive them.

One agent per task, not one agent for everything

I run multiple AI agent sessions in parallel. This is a deliberate architectural choice, not a workflow preference.

Why separate sessions

A single long-running agent session accumulates context — but it also accumulates confusion. By message 50, the agent is juggling three features, two bug fixes, and a deployment issue. Its responses get less precise. Its suggestions start conflicting with earlier decisions.

Separate sessions solve this. Each session gets:

• One clear task. "Add the email notification plugin." Not "work on the platform."
• Relevant skills loaded. The plugin development skill, not the infrastructure skill.
• Scoped tools. The plugin CLI and test generator, not the Kubernetes deploy script.
• Fresh context. No residue from yesterday's debugging session.

How the architecture supports this

The reason this works is that the underlying system is designed for bounded work. Portal's plugin architecture means a new plugin is a self-contained unit. An agent working on plugin-crm does not need to understand plugin-lms. The Convex component boundary ensures schema isolation. The hook system ensures integration points are explicit.

When I spin up an agent session for a new plugin:

1. The agent reads the plugin development skill
2. It has access to the plugin scaffold CLI
3. It generates the initial structure from the template
4. It implements domain-specific logic within the established patterns
5. It runs scoped tests
6. It produces a PR-ready branch

The agent does not need to understand the entire platform. It needs to understand the interface it is extending. The skills and tools provide that interface. The architecture ensures the boundaries are clean.

The multi-agent parallel pattern

On a productive day, I might have:

• One agent session building a new plugin feature
• Another session writing integration tests for an existing module
• A third session updating deployment configuration

They do not interfere because they operate on different bounded contexts. The skills ensure they all follow the same conventions. The tools ensure they all produce consistent output. The architecture ensures their work can be merged without conflicts.

This is the same principle that makes microservices and plugin architectures work for human teams. Clear boundaries, shared contracts, independent deployment. AI agents benefit from the same structural discipline.

The compounding effect

Six months ago, starting a new plugin took a full day of setup. Today it takes under an hour. The time savings did not come from faster AI models. They came from:

• A scaffold CLI that generates 80% of the boilerplate
• Agent skills that eliminate context-setting overhead
• Test generators that produce coverage from mutation signatures
• Deployment templates that configure infrastructure from parameters

Each tool I build makes the next project cheaper. Each skill I write makes the next agent session more effective. Each pattern I encode into a template eliminates a class of ad-hoc decisions.

Vibe coding does not compound. The 50th project takes exactly as long as the first. Repeatable systems compound. The 50th project benefits from every tool, skill, and template built during the first 49.

What this looks like in practice

Here is what I actually do when I start a new feature:

1. Spin up a fresh agent session — clean context, no baggage from prior work
2. Load relevant skills — the agent reads the plugin skill, the testing skill, the deployment skill
3. Scaffold the structure — the agent calls the CLI to generate initial files from templates
4. Implement domain logic — this is the only genuinely new code; everything else is derived from patterns
5. Run scoped validation — linting, type checking, and integration tests scoped to the changed surface
6. Ship — the PR follows the project's conventions because the tools enforced them

The AI is essential at every step. But it is not improvising. It is operating within a system I have built for exactly this kind of work.

The meta-lesson

The best use of AI in software development is not writing code. It is building the systems that make writing code predictable. CLIs, scaffolds, skills, tools, test generators, deployment templates — these are the high-leverage outputs.

If you find yourself explaining the same architecture to an AI for the third time, stop and write a skill file. If you find yourself fixing the same structural mistake in generated code, stop and build a template. If you find yourself re-prompting for the same deployment steps, stop and write a script.

The goal is not to remove AI from the process. The goal is to give AI better starting conditions so its output is useful on the first attempt instead of the fifth.

Vibe coding is a sugar high. Repeatable systems are compound interest.

---

For more on the plugin architecture that makes this workflow possible, see From Monolith to 34 Plugins. For the AI safety patterns that govern model output, see AI Safety and Guardrails in Production Systems.