How I Build: A Vibe Coder's Workflow in 2026

I can't write a binary search tree from memory. I don't know the Big-O complexity of a hash map off the top of my head. I've never passed a LeetCode hard. By the traditional definition of "software engineer," I'm not one.

And yet: 17 repos built, a multi-agent SaaS boilerplate with 22 passing tests, an MCP server with 13 tests, a RAG knowledge engine with 11 tests, production patterns extracted from systems I've actually run. All of it shipped in the last six months.

This post is about how that's possible in 2026 — and how other people in the same position can use it.

The Honest Starting Point

I am what the industry now calls a "vibe coder." The term was slightly pejorative when it emerged in 2025, but it's normalized fast. By 2026, 92% of US developers use AI-assisted coding tools daily, and 60% of all new code written is AI-generated. The question isn't whether to use AI for coding — it's how to use it with enough judgment to produce systems that actually work in production.

The difference between a vibe coder who ships working systems and one who ships demos that break in week two is not fundamentals. It's mental models.

My Tool Stack

The Mental Models That Make It Work

1. Separate "what" from "how"

The only thing I need to provide is "what" — what the system should do, what constraints matter, what failure modes to avoid. The AI handles "how." But "what" requires real judgment, and it's where most vibe-coding projects fail. A vague "what" produces vague code.

My prompts are dense with constraints: what data structures should be used, what failure cases to handle, what the expected inputs and outputs look like, what the tests should verify. I've learned to front-load that detail instead of iterating endlessly on shallow prompts.

2. Architecture before code

Every system I build starts with a rough architecture in plain English. Not a formal spec — just: what are the components, what does each do, how do they connect, where's the shared state. Claude Code is excellent at this conversation: I describe the system, it proposes a structure, I push back on parts that seem wrong, we align on the shape before touching a file.

This is where my "understanding systems by experience" actually matters. I've seen what happens when agents share state through direct calls (tight coupling, cascade failures). I've seen what happens without a retry strategy (silent data loss). The AI can generate the code for the patterns — I provide the judgment about which patterns belong where.

3. Tests as the contract, not the afterthought

I don't write tests. Claude Code writes tests. But I specify what the tests should verify before asking it to write the code. This forces clarity on the actual behavior — you can't write a meaningful test spec for a function you haven't thought through. The test spec IS the specification. Code generation follows from that.

Every repo in my portfolio has tests that pass. They weren't an afterthought. They're how I know the system does what it's supposed to do, because I can't walk through the code manually at the speed I build.

4. The "no surprise" principle

When I get code back that I don't understand at all, I don't ship it. I ask for an explanation — not a line-by-line breakdown, but: what does this do at a system level, what could fail, what's the key assumption. If I can't answer those questions, the code is a liability. Understanding the contract of each component (inputs, outputs, failure modes) is the minimum bar, even if I don't understand the implementation details.

The Graduate Workflow

There's a workflow gaining traction in 2026 called the "graduate workflow" — prototype fast in a browser-based tool (Bolt, Lovable, v0), validate the idea, then move to Claude Code or Cursor for production refinement. I use a version of this:

1. Spike: Get something working fast. Ignore structure. Verify the core pattern works at all.
2. Restructure: Claude Code refactors the spike into the right module boundaries. Tests get written here.
3. Harden: Add error handling, edge cases, the retry logic, the circuit breaker. This is where production patterns go in.
4. Document: README with honest descriptions — what it does, why each design decision, how to use it. No marketing fluff.

Where Patterns Come From

Every pattern in my repos has a real origin. The SCAR pattern (store failure signatures + resolutions, look them up before retrying) came from watching an agent hit the same JSON parse error 40 times in one run before I added the loop exit. The blackboard pattern came from debugging an agent-to-agent communication failure where direct function calls turned into a circular dependency. The SHA-256 response cache came from an accidental $60 API bill on a batch job that made 2000 identical requests.

You don't need CS fundamentals to learn from failures. You need to pay attention, name what went wrong, and build the prevention into the system. That's what the portfolio demonstrates.

What This Looks Like in Practice

A recent session: I needed an MCP server exposing three tools to a Claude agent. No prior MCP server experience. Here's what I actually did:

1. WebSearch: "MCP server Node.js 2026 tutorial" — read the official docs and two tutorials.
2. Claude Code conversation: describe the three tools I need, the data model, the test cases. Let it propose the file structure.
3. Review the structure — does it match how I understand MCP to work? Push back on anything that doesn't.
4. Generate the code. Review each file for the contract: what does it take in, what does it return, what fails and how.
5. Run the tests. 13/13 pass. Wire into Claude Desktop. Verify tools show up.

Total time: about 3 hours. A traditional SWE would write the same code faster — maybe an hour if they knew MCP well. But I ship it in 3 hours with 13 tests and a production-quality README, starting from zero MCP knowledge. That's the value of the workflow.

The Honest Limitations

There are things this workflow can't produce. Systems that require deep algorithmic optimization won't benefit from my approach — I can't catch an O(n²) when O(n log n) is needed. Fine-tuning a model requires ML fundamentals I don't have. Performance profiling at the hardware level is out.

But for the layer most businesses actually need — systems that connect models to tools, route work intelligently, handle failures gracefully, persist state reliably, and expose clean interfaces — the mental models and the AI tooling get there. That's the bet I've made on how to be useful in 2026.