vibekoded.com, blank repo to live site

What this is

VibeKoded.com is the experiment. It is the operator's daily practice running in public. The brand is not built around what the operator KNOWS; it is built around what the operator is LEARNING out loud, on camera, with the strengths and weaknesses visible so they can be seen, named, and improved.

That framing matters because it's the load-bearing decision. Most consultants build brands that hide the learning curve. The intent here is the opposite: surface the learning so it can be tested, refined, and shared.

Walking the build, beginning to current.

The decision to commit

What had to be true for this to start was a willingness to put strengths AND weaknesses on display. Not just the polished output, but the moments where the methodology failed, the choices that were wrong, the architectural calls that needed reversing. The brand exists because that visibility is the only honest path to operator-class competence: you can't improve what you can't see, and you can't see clearly when you're protecting the image.

So the brand became center stage. Not a portfolio. Not a service catalog. A live, ongoing experiment.

The pivot

The original frame was conventional: sell websites, sell automations, sell consulting to people who want to pay someone to build their thing. Standard agency posture.

That frame got abandoned. The replacement posture: teach vibe coders who are seeking knowledge. Put the entire operator practice into vibekoded.com itself. Not the deliverables, the discipline. Not the websites, the methodology that produced them. The audience shifted from buyers-of-output to operators-in-development.

The shift sharpened everything. The /log content stopped being marketing and started being teaching. The voice stopped sounding like a pitch and started sounding like a peer. The methodology (SpecMesh) stopped being an internal tool and became the product.

The hardest architectural decision

The mercury-blob header at the top of the landing page. It took the longest to commit to. It was the visual signature, the brand artifact, the "this is different" cue.

It is also, with a thread of irony, the decision the operator would reverse if given a clean slate. The blob is GPU-expensive, makes the page feel heavy, and the brand identity does not actually require it. The terminal scene is the surface that matters. The blob exists because it took the most thought to land, not because it earns its keep.

The lesson there: spend the SPEC effort on what matters. Aesthetic features that demand more thought than functional ones often DESERVE less commitment. Hard architectural decisions are not automatically the right ones. They are sometimes just the longest ones.

That pattern generalizes past websites.

The autoship pipeline as showcase artifact

The moment the brand stopped being aspirational and started being inevitable was when the operator dipped into scheduled tasks for the first time. That was the inflection. Once it became clear that an agent could fire on its own cadence, the whole methodology had a path: research, drafter, SEO, revision, autoship. The full pipeline that runs unattended.

The pipeline shipped V1 in late May 2026. It ran every day, scanning research, drafting posts, gating voice, shipping to production. By June 8 it had landed its first fully autonomous post on main without any operator intervention. That was the 78th post on the site. The audit trail from the SPEC chain through the daily run logs through the live blog index is end-to-end inspectable.

This is the artifact a serious evaluator should look at first. It is also the artifact that most directly demonstrates the methodology in motion: SPEC the pipeline, declare invariants, gate against violations, run the gate continuously, ship when green. The pipeline is SpecMesh applied to itself.

When it broke (V2.6 introduced a branch mishap and the autoship landed a post on the wrong branch), the failure was caught, audited, and turned into a new invariant within hours. That is the methodology being alive.

What broke, what almost broke, what held

Nothing broke during V1 that almost made the operator quit. That is itself a signal. The system held under stress because the SPEC discipline forced reasoning before code, and the reasoning was usually correct. When code went sideways, it was a known-bounded failure: a state file out of sync, a git identity mismatch, a branch race. These are operational issues, not architectural collapses.

The methodology's job is to limit failure to recoverable surfaces. So far it has done that.

What is V2

V2 in the operator's head is community-fed. The Question Box is the first move (visitors submit questions, the agents triage, generate, and post answers, the corpus grows from real demand instead of operator hypothesis). The brain grows. The community builds it with the operator. There is a planned speakeasy section that will appear when the corpus has earned it, and the eventual corpus depth becomes the kind of artifact that, if it has to become a course later, can. Course-ification is the conventional internet move; here it is treated as a downstream possibility, not the goal.

The point of V2 is that the methodology stops being one operator's practice and becomes a system that compounds across participation. The garden gets tended by more than one hand.

The line between brand and operator practice

There is no line. VibeKoded.com is the operator's daily practice in the open. Every interaction with the agent is the same shape: SPEC the work, declare invariants, gate against violations, capture decisions, ship. The brand is the daily practice exposed. The operator does not perform discipline for the brand and then live differently when the camera is off. The camera is always on, and the brand IS the operations.

This is the answer to the "how do you scale consulting" question that other consultants struggle with: you don't separate the practice from the persona. You make the practice the persona. The brand and the operator are the same surface.

What an evaluator should look at first

The honest answer is that the BRAIN folder has grown past the operator's full conscious observation. The agent writes to it as needed. The operator does not always know what is in the journal directory. That is by design. The methodology is alive without requiring constant conscious oversight, which is what operator-class actually means.

If an evaluator has 60 seconds, they should look at the most recent week of session logs. Those show the methodology operating in real conditions, with the operator in the loop where it matters and absent where it does not.

If they have an hour, they should walk the SPEC chain. That walk is the methodology made legible.

If they have a day, they should read the BRAIN end to end, then run the live site, then verify the deployed code matches the SPECs. Audit trail intact.

The first substantive critique

Until June 8, public feedback on vibekoded.com was surface-level: phone loading speed, color scheme, the kind of feedback that targets the apparatus instead of the methodology. The first substantive critique came on June 8 via a Facebook DM. Another operator, who runs a parallel project focused on AI-assisted-work governance, had read the site, recognized the methodological overlap with their own work, and named the gap: "strong signal; now needs stronger evidence."

That critique was correct, useful, and exactly the kind of friction the experiment-in-public posture is designed to attract. The /receipts surface (which this document is part of) exists in direct response to that feedback. Pattern: real critique improves the apparatus; the experiment-in-public posture earns the critiques worth getting.

Convergent discovery validates pattern reality. When two operators arrive at structurally similar architectural patterns from different problem domains, the patterns are probably real. That validation is at a level the operator could not manufacture from inside the system.

If someone offered $10K to take vibekoded.com down

The reflex answer would be no. The smarter answer (and the operator's actual answer) is: figure out why they want it gone, then ship that thing yourself.

If a competitor is willing to pay $10K to remove this surface, the surface is doing something they cannot easily neutralize through other means. The energy goes into amplifying whatever that thing is. The offer becomes intel.

That is operator-thinking. The instinct is not to defend the surface; it is to use the threat as a directional signal toward the work that matters most.

Current status

V1 shipped. V2.6 Question Box is queued. Daily autoship pipeline runs on schedule. Brain compounds. /receipts surface demonstrates the methodology in artifact form. Next layers: community contributions, speakeasy section, deeper corpus work.

The experiment continues in public. That is the entire commitment. If you are reading this and you build software using AI orchestration, watch the methodology and decide for yourself whether it holds.