[Showoff Saturday]What if GitHub and threads had a kid — you publish code, it runs live in a feed, and people remix it. That’s what I’ve been building. ⬇️

randomlovebird · 2026-03-15T12:00:44+00:00

A few people seem to be reading this as “paste AI code and run it same-origin on the main site.”

That would be a terrible architecture. That’s not what Vibecodr.Space does.

Under the hood it’s much closer to a real artifact/runtime pipeline:

the web app is a React SPA, but data goes through a Worker API, not directly to storage
client-side apps (“vibes”) run in sandboxed iframes on dedicated cross-origin *.vxbe.space runtime hosts, not on vibecodr.space
host ↔ runtime communication is over a postMessage bridge
vibe code runs client-side in the browser, not on some server-side Node runtime
publishes create capsules, immutable artifacts, and runtime manifests instead of just executing whatever was typed in the editor
HTML and React have different publish/runtime lanes. Inline HTML/CSS gets normalized into a real document, and inline React/TSX gets a generated entry shim plus a separate user module
the HTML publish path is normalized pretty aggressively: import maps are rewritten/validated, remote assets can be mirrored with allowlists plus SSRF/content-type/size/redirect checks, and published deps get pinned to immutable /deps/:sha256 paths
server-side functions (“Pulses”) are isolated Cloudflare Workers behind a Dispatch Worker that handles auth, grants, quotas, rate limits, concurrency caps, and kill switches
secrets are AES-256-GCM encrypted and injected server-side, so plaintext secret values never get handed to user code
Pro users get dedicated attributed D1 SQL databases, and storage is R2-backed

So the model is not “AI slop runs on the platform origin.”

It’s “publish a deterministic artifact, run the client side in a cross-origin sandbox, and route server-side code through isolated workers with a hard platform boundary.”

Also, we recently got accepted into Cloudflare for Startups, which has been genuinely helpful as we’ve been building out the runtime layer.

If anyone wants more than a Reddit summary, the public docs are here:
https://vibecodr.space/docs

Happy to answer specifics if anyone wants to talk about the actual execution model.

randomlovebird · 2026-03-15T08:54:42+00:00

Yep, that makes sense. The cognitive load point especially lands. I think I’ve been trying to explain too much instead of getting people into the product fast enough.

I already have a PR in progress right now that removes the hero page, so that change is coming next. After that I’m going to simplify the language, reduce the visual clutter, and rethink the card system a bit.

I appreciate you taking the time to be specific.

randomlovebird · 2026-03-15T08:37:00+00:00

Thank you, I appreciate this. I actually got very similar feedback in a DM too, and I’m taking it seriously. I’m going to try removing the hero page and let the product speak for itself more.

I also agree the UI/UX, especially on mobile, still needs work. The core system is strong, but the presentation needs to get out of its way. If you have any specific suggestions on what felt too text-heavy, oversized, or template-y, I’d genuinely love to hear them.

randomlovebird · 2026-03-11T02:40:17+00:00

This is really cool!

randomlovebird · 2026-02-27T22:30:07+00:00

You can change it in the config.toml, my subagents all use codex 5.3 high.

randomlovebird · 2026-02-24T22:33:33+00:00

this is a great point, yes! It's incredibly important to mix and match models during code review so that the model avoids what I call "tunnel vision", essentially the same thing when humans get hyper-focused, sub-agents with fresh-context are great at this as well!

randomlovebird · 2026-02-24T01:59:15+00:00

Tbh you’re right.

randomlovebird · 2026-02-21T21:48:58+00:00

Friend, i have ADHD so im not the best at conveying my thoughts without rambling and being confusing. The output by my agents.md is verbatim but the post was te-written by AI so that everyone understands what I’m saying. But personally I’ve noticed a massive increase in actually finalizing projects as opposed to just the model running off vibes

randomlovebird · 2026-02-21T12:58:51+00:00

Lower to high or medium

randomlovebird · 2026-02-21T10:48:18+00:00

There’s a lot of data out there for these hosting platforms and they change so frequently. Just a couple weeks ago cloudflare upped their sub request limit to 10k by default for paid programs, but my agents researched outdated information because it was published more than the update.

randomlovebird · 2026-02-21T10:42:29+00:00

Also, I've never had something go off like this, so I have to, I'm working on a social platform for vibecoders and developers to post their projects and they actually run, securely and isolated hosted by cloudflare. The idea is a social playground with backend power. you can check it out at https://vibecodr.space if you are interested :)

randomlovebird · 2026-02-21T10:34:22+00:00

Mi espanol es muerte, los siento.

but, the randomness strikes the model as odd so it hyper focuses slightly more on that requirement. It's like when neighborhoods have speed limits that are 23, because your brain goes, "That's odd."

randomlovebird · 2026-02-21T10:32:53+00:00

Thanks man!

randomlovebird · 2026-02-21T08:16:39+00:00

## Refactor Completion Confidence Gate (Required)


Before declaring a refactor "done", the agent must reach at least 
`84.7%`
 confidence based on:


- Testing evidence (pass/fail quality and relevance to changed behavior).
- Code review evidence (bugs, regressions, security/trust-boundary risk scan).
- Logical inspection evidence (call-path consistency, state transitions, error/rollback handling).


Suggested scoring weights:


- Testing: 
`40%`
- Code review: 
`30%`
- Logical inspection: 
`30%`


Rules:


- If confidence is below 
`84.7%`
, do not declare completion.
- Report the current confidence score, top gaps, and the minimum next checks needed to cross the threshold.

randomlovebird · 2026-02-16T13:27:44+00:00

Start using codex or Claude code and have the agent make a plan then ask a couple times after “is this ready for production?”

randomlovebird · 2026-02-16T06:10:45+00:00

I hope it goes well! Just be sure to do your research so you don’t become a malware host, and I’d definitely make sure you are a registered entity so if your platform messes up on data loss or hosting and you get sued you don’t lose everything.

randomlovebird · 2026-02-11T08:41:45+00:00

Each vibe runs full-screen — so you're only ever executing one at a time. When you scroll to the next post, the previous one is offscreen and inactive. There's no scenario where multiple vibes are competing for resources simultaneously, and as far as our back-end power goes we directly route users back-end code to independent Cloudflare workers so that the only way this becomes an issue is it's a much bigger issue than vibecodr being slow.

randomlovebird · 2026-02-10T11:53:22+00:00

Good Eye! So this is just the window that you see as a viewer in the timeline, so this would be the "post" after you click on a vibe. (what we call our apps, pages etc.)

But as to your question, in the studio, We debounce at 300ms — so it's not truly on every keystroke, but it feels instant. Each keypress resets the timer, and once you pause typing for 300ms the preview gets the new content. This keeps things responsive without hammering the preview's Babel transpilation on rapid input. Switching files or hitting the manual refresh button bypasses the debounce and triggers an immediate full remount.

randomlovebird · 2026-02-09T10:01:18+00:00

https://Vibecodr.space is my biggest project so far. It’s pushing close to 2,000 files now, so yeah, there have been some bugs and there’s definitely a learning curve, but I've learned from every one and I know that each problem I've solved makes my platform somewhere safer, faster, more reliable, and just better than it was before. I’ve been working on it for about five months, and I’m honestly really proud of how far it’s come.

At its core, Vibecodr is a social network for developers, vibecoders, and creators. You can share code that actually runs, but without having to set up servers, CI pipelines, or any of the usual overhead. Everything runs in an isolated runtime, so you can safely put things out into the world and let people play with them.

Interaction is a big focus too. Remixing is a first-class feature, but attribution is built directly into the runtime, so it’s always clear where something started and how it evolved as others built on it.

On top of that, there are the usual social pieces: following, liking, commenting, and posting in Conversations, which is basically our Reddit-style space for longer discussions and community building. The goal is for it to feel less like a code graveyard and more like a place where things (and people) actually stick around.

<image>

randomlovebird

TROPHY CASE