If everyone is vibecoding, and SaaS plays have no moats anymore, and everyone says they are mad at Github's reliability...why aren't there like 10 viable replacements already?

Why are you still using Github?

- And yes, GitHub is a massive product with like 50 different huge features. No reasonable person would say you can trivially vibecode that. Vibecoding would still make it easier. I feel this argument is a bit silly, no? "Ah, you can't vibecode GitHub in a weekend? That proves vibecoding was a mirage!" Surely even the most fervent anti-AI skeptic must admit there must be some middle ground between "a mirage" and "can literally replace millions of man-hours of work".

Open-source projects, yes I can sort of get it, you want to be where the contributors are (but there are downsides to that also).

Then they came for the three nines And I did not speak out Because I was not paying for Enterprise

Then they came for the two nines And I did not speak out Because the status page said all systems operational

Then they came for the one nine And I did not speak out Because I was a manager, and outages are just extra standup material

Then they came for the coin flip And there was no one left to merge my PR Because Actions was down And so was Pages And so was Codespaces And the status page said all systems operational

I have yet to see literally anyone say this.

I have yet to even see anyone claim that software can't constitute a moat anymore but I expect that there are people saying that. GitHub has a huge non-software moat in the form of network effects, brand recognition, and good will.

The hardest part isn't making a "forge", it's making money off of making a forge. Getting a sufficiently large number of paying customers.

If GitHub doesn't get their quality issues under control someone probably will manage to breach that moat and take over the market. It's not like there's a lack of competitors (Pre-llm: GitLab, BitBucket, Gitea, Source Hut, etc. Post LLM: Tangled, esrc is promising something any day now. Probably more in both camps that don't come to mind).

I've heard a lot of people say this...including myself after a root beers. I think you just have to look to any time an AI feature is announced and some related companies stock price crumbles. Just google something like "stock price tumbles after anthropic announces" or something like that.

I'm using GitHub for my open source projects as:

1. While GitHub Actions has its issues and doesn't work for everyone, I've found it easy to build and test an IntelliJ plugin against multiple IntelliJ versions.

2. I don't have to pay for and manage the hosting of the git repository.

Because everyone wants the fake internet points (sorry, stars) to mention on their CV.

Because there are already a number of viable alternatives, them not being chosen has nothing to do with AI coding but other factors like market momentum & network effects and familiarity. They are used, just much less so. If there are already good alternatives, why would anyone vibe code a new one any more than they would write a new one manually? Forges are not sexy stuff, and the existence of numerous decent free ones means that you aren't going to be able to sell a new one in any way (paid accounts, stalking/advertising, …) at least not until it has a significant following and that is unlikely to happen because of the reasons above.

People not wanting to use github (or one of the common alternatives that already exist) are more likely to just use git as-is, and other tolls as needed for issue tracking, CI, etc, than to create a new forge.

https://youtu.be/f3u57jkwBFE?si=FJuxZfmc-i7EkPlx

I still have a GitHub account I actively use.

GitHub outages and stuff don’t really affect me, so I have no great reason to leave. But I have good reason to stay, because that’s where everyone else is already.

Github is struggling because of compute, which comes from everyone vibecoding and triggering actions 10x more.

I can vibecode an alternative, but once i have users, who is going to secure this amount of compute? Compute+talent to manage it(devops isnt vibecoded *yet) is a moat

So I’m working on waza.sh. I have NO intent on making it commercial, nor open-source (unless someone wants to collab on it).

Will it need compute? Yes! For my team only. So a dedicated box at OVH/Hetzner for 30eu is more than sufficient.

This is a personal pet project, just to see what it might look like, how it would work, to satisfy personal curiosity. If it comes to the point that it actually becomes usable for the team (read: actually add value), then it's up to $TEAM to decide whether to use it or not.

I would hate my team to waste company time on such an endeavour. ;-)

Show me the VCs who are willing to fund the marketing effort that would be needed to conquer the network-effects moat, and I'm in.

I've been building OctopusGarden (https://github.com/foundatron/octopusgarden), which is basically a dark software factory for autonomous code generation and validation. A lot of the techniques were inspired by StrongDM's production software factory (https://factory.strongdm.ai/). The autoissue.py script (https://github.com/foundatron/octopusgarden/blob/main/script...) does something really close to what others in this thread are describing with information barriers. It's a 6-phase pipeline (plan, review plan, implement, cold code review, fix findings, CI retry) where each phase only gets the context it actually needs. The code review phase sees only the diff. Not the issue, not the plan. Just the diff. That's not a prompt instruction, it's how the pipeline is wired. Complexity ratings from the review drive model selection too, so simple stuff stays on Sonnet and complex tasks get bumped to Opus.

On the test freezing discussion, OctopusGarden takes a different approach. Instead of locking test files, the system treats hand-written scenarios as a holdout set that the generating agent literally never sees. And rather than binary pass/fail (which is totally gameable, the specification gaming point elsewhere in this thread is spot on), an LLM judge scores satisfaction probabilistically, 0-100 per scenario step. The whole thing runs in an iterative loop: generate, build in Docker, execute, score, refine. When scores plateau there's a wonder/reflect recovery mechanism that diagnoses what's stuck and tries to break out of it.

The point about reviewing 20k lines of generated code is real. I don't have a perfect answer either, but the pipeline does diff truncation (caps at 100KB, picks the 10 largest changed files, truncates to 3k lines) and CI failures get up to 4 automated retry attempts that analyze the actual failure logs. At least overnight runs don't just accumulate broken PRs silently.

Also want to shout out Ouroboros (https://github.com/Q00/ouroboros), which comes at the problem from the opposite direction. Instead of better verification after generation, it uses Socratic questioning to score specification ambiguity before any code gets written. It literally won't let you proceed until ambiguity drops below a threshold. The core idea ("AI can build anything, the hard part is knowing what to build") pairs well with the verification-focused approaches everyone's discussing here. Spec refinement upstream, holdout validation downstream.

The attractor loop is closer to gradient descent than to an agent conversation. Generated code is treated as opaque weights, and only externally observable behavior matters (scored 0-100 by an independent LLM judge against holdout scenarios). "Things going sideways" just means the satisfaction score is low on that iteration, which naturally feeds back as context for the next one. Build failures, test failures, partial correctness: they're all just points on a convergence curve rather than catastrophic failures requiring forensic replay.

So the observability you need shifts from "what did the agent think at step 12?" to "is the loss curve trending down?" We persist per-iteration satisfaction scores, failures, and token costs, which gives you the audit trail. But it's a pretty compact one: a number, a list of failing scenarios, and a cost.

The spec durability point is a good one to raise. In this case specs aren't documentation that drifts from code over time. They're the actual input to the system. If the spec is wrong, you fix the spec. The generated code is disposable by design.

You're absolutely right that multi-run observability becomes important as this scales though. Watching N specs converge simultaneously will need a proper dashboard. But it's N loss curves rather than N conversation traces, which should be fundamentally simpler to reason about.

For approvals, the current model is that the spec is the approval. If the spec is right and scenarios pass at 95%+ satisfaction, the code ships. There's no PR review step by design (the "code is opaque weights" philosophy).

That said, you could totally layer approvals on top. Gate on spec changes, require sign-off before a run kicks off, or add a human checkpoint between "converged" and "deployed." The tool doesn't enforce a deployment pipeline, so that's up to your org's workflow.

Worth noting: this is purely a hobby project at this point. It hasn't been used in any commercial setting. The guard rails and approval workflow stuff is where it would need the most work before anyone used it for real.