Building Lockout: Why I’m Forcing Myself to Stop Vibe Coding

We are living in the golden age of "vibe coding."

You know the feeling. You open an IDE, type a comment, hit Tab, and an AI generates twenty lines of boilerplate. You chain a few SaaS APIs together, deploy to a serverless platform, and suddenly you have a working product. It feels incredible. It feels fast.

But recently, I realized something uncomfortable. I was building width, not depth.

I could deploy a website in seconds using Vercel or Netlify, but I had stopped thinking about what actually happens when I push that commit. I was trusting the abstraction layers to handle the hard stuff: the queuing, the isolation, the retries, the state management.

I want those problems back.

Enter Lockout

To fix this, I am starting a new project called Lockout.

Lockout is a deployment pipeline for static sites. It takes code, builds it in a container, and uploads it to object storage.

Functionally, it is a tiny, simplified clone of the platforms I use every day. But the goal isn't to build a competitor. The goal is to build it from scratch, intentionally handling every piece of the system architecture myself.

The core design is simple:

1. Control Plane: Accepts requests and manages state.
2. Queue: Decouples the API from the heavy lifting.
3. Workers: Isolated environments that run untrusted build commands.
4. Storage: The final destination for the artifacts.

The "Anti-Vibe" Constraints

The most important part of this project isn't the code. It is the rules I am setting for myself.

In a normal project, I would optimize for speed. I would grab the library that handles job queues for me. I would use an orchestrator that manages container lifecycles automatically. I would let Copilot write the error handling.

For Lockout, I am doing the opposite.

1. No Agentic Coding

I am banning myself from using AI to write the code. I can use LLMs for research, to explain concepts, or to critique my design docs. But the actual implementation—the logic, the bugs, and the fixes—has to come from my own fingers. I need to feel the friction to learn from it.

2. Design First, Code Second

I am forcing myself to write a design document for every component before I open a code editor. If I can't explain how the worker handles a timeout in plain English, I am not allowed to code it yet.

3. Embrace the "Dragons"

I am actively looking for the hard problems.

• What happens if a worker dies mid-build?
• How do I ensure a malicious build script doesn't take down the host?
• How do I handle a "thundering herd" of requests?

These are the systems engineering concepts that get abstracted away in modern web development. I want to bring them back into focus.

Why Do This?

This project is going to be slow. It will likely be frustrating. I will probably spend three days debugging a race condition that a managed service would have solved for me instantly.

But that is exactly the point.

"Vibe coding" is great for shipping products, but it is terrible for growing as an engineer. Real seniority comes from understanding the layers beneath the tools. It comes from having the battle scars of a failed distributed system.

Lockout is my training ground. It is time to stop trusting the magic and start understanding the machinery.

I will be documenting the entire process here, starting with the Architecture and Data Model in the next post.

See you in the logs.