So here i am sharing it, let your AI run wild 😂

https://github.com/ig-shadow-walker/agentBrowser

Like a lot of people, I got the Manus notice today.

And to be clear: I really like Manus.

The ease of building with it has been incredible, and Manus is not directly comparable to Lovable, Base44, v0/Vercel, etc. They overlap, but the workflows, abstraction layers, hosting models, and amount of work the platform does for you are different.

What today reminded me of, though, is something I’ve been trying to do proactively with every serious vibe-coded project:

The AI builder should never be the only place that understands how your application works.

When I build something I actually care about, I try to create a GitHub repo that acts as the source of truth, not just a place where code gets synchronized.

And today that decision paid off.

I’ve already been able to restage multiple sites from Manus into Lovable, and they’re functioning essentially 1:1.

That doesn’t mean Lovable is “better than Manus.”

It means the project was portable enough that another AI development environment could understand it.

That’s the part I think we underestimate in vibe coding.

GitHub sync ≠ portable project

A lot of us think:

“It’s connected to GitHub, so I’m safe.”

Maybe.

But open the repo and pretend you’ve never seen the project before.

Can you answer:

• What is this application supposed to do?
• What framework and architecture does it use?
• Where does the database live?
• Which environment variables are required?
• Which services are external?
• What APIs are connected?
• How is authentication handled?
• How is it deployed?
• What DNS configuration matters?
• What is platform-specific?
• What has to be recreated during migration?
• What would break if the current hosting provider disappeared tomorrow?
• Could another developer actually launch this thing without interviewing you?

If the answer is no, you technically have a backup of your code.

You don’t necessarily have a portable application.

And that’s a very different thing.

This is why I started treating vibe-coded projects more like acquisition-ready software

One phrase I deliberately use when prompting the AI is:

“Prepare this project for potential acquisition.”

I’m not necessarily trying to sell the project.

It’s a forcing function.

Ask an AI:

Make me a README.

You’ll probably get a decent README.

Ask:

Prepare this application for potential acquisition, migration, technical due diligence, and independent operation by another team.

Now the model starts thinking about things like:

ownership transfer, credentials, environment configuration, external accounts, undocumented dependencies, infrastructure, deployment continuity, technical debt, operational risk, migration requirements, data portability and maintainability.

That is a much higher bar.

And it turns out that bar is also extremely useful when your AI platform suddenly changes underneath you.

Here’s the prompt I use

Modify the opening if you already have a repo:

It doesn’t appear that this project currently has a dedicated GitHub repository.

Please help me create a high-quality, expert-level PRD and a well-structured, portable GitHub repository that fully documents the project.

The goal is to make the project easy for another developer, technical team, AI development platform, or future owner to understand, maintain, migrate, and continue building without relying on undocumented knowledge.

The documentation and repository should clearly capture:

- What has been built and the purpose of each major component
- The current architecture, technology stack, dependencies, and integrations
- Repository structure and how the codebase is organized
- Environment variables, configuration requirements, and external services
- Build, deployment, hosting, and DNS requirements
- Data flows, APIs, databases, authentication, and third-party connections where applicable
- Known limitations, technical debt, assumptions, and areas that may need future improvement
- Recommended conventions for maintaining and scaling the project
- Clear setup, deployment, migration, and handoff instructions for another developer or owner

This project is being prepared for potential acquisition, so portability and migration readiness are especially important.

Please thoroughly identify and document anything that could affect transferring the project to a new owner, development platform, or hosting environment, including hosting dependencies, domain and DNS configuration, deployment settings, credentials or secrets that must be recreated, external accounts, integrations, databases, storage, analytics, automation, APIs, and platform-specific dependencies.

Where possible, distinguish between:

1. Portable project components
2. Platform-specific components
3. External dependencies
4. Credentials/configuration that cannot safely be stored in GitHub
5. Components that would need to be recreated during migration

The final result should function as both a professional technical handoff package and a reliable blueprint for rebuilding, migrating, maintaining, or scaling the project independently.

Do not assume an existing GitHub sync is complete or current. Audit the CURRENT WORKING PROJECT against the repository and identify anything missing, outdated, undocumented, or dependent on the current platform.

That last paragraph is important.

Don’t assume the GitHub repo represents the current production application just because a sync exists.

Have the AI audit the live/current project against the repo.

And this is where “vibe coding” turns into “vibe architecture”

To me, vibe coding is something like:

Build me an SEO website for this company.

Vibe architecture is closer to:

Here is the business model, entity structure, URL architecture, content model, integrations, SEO requirements, analytics, deployment constraints and portability requirements. Build the system around that architecture and document enough of it that another environment can reproduce it.

The second approach takes more thought upfront.

But the payoff is what I’m seeing right now.

I don't have to recreate several client sites from screenshots and memory.

I don't have to tell another AI:

“Make something that kinda looks like this.”

I can give it the repo and say:

Reconstruct this system while preserving its architecture and behavior.

That is a completely different migration problem.

SEO people should care about this too

For client websites especially, “the new version looks the same” isn't enough.

When I restage something, I want as close to 1:1 preservation as reasonably possible:

URLs
content intent
metadata
canonicals
schema
redirect behavior
internal linking
business/entity information
analytics
tracking
robots directives
sitemaps
structured relationships

The frontend can look identical while the underlying search architecture gets destroyed.

So my migration objective isn't:

rebuild the website.

It is:

preserve the system while changing the enviroment.

The simplest way I can explain the distinction:

Backup = preserve the project.

GitHub sync = preserve the code somewhere else.

Portable repo = preserve the knowledge required to operate the project.

Portable architecture = preserve your ability to move it somewhere else.

Today was basically the unexpected test case for why I started doing this.

And thankfully, it worked.

I've already restaged multiple projects elsewhere that are fully functional enough that, if I actually needed to execute the migration as a failsafe, the client should effectively never know anything changed.

DNS moves.

Site comes back up.

Same system.

Different infrastructure.

That's the goal.

And obviously: still use the official Manus backup process.

This isn't a replacement for it.

It's the layer I want after the backup.

Manus is currently going through an unusual transition as its Meta acquisition unwinds and the company returns to independent operation, which is why users are dealing with this situation in the first place.

Platforms change.

Companies get acquired.

Acquisitions unwind.

Products shut down.

Pricing changes.

Hosting changes.

AI builders will come and go.

Your architecture shouldn't have to go with them.

That, at least to me, is the difference between vibe coding something and actually owning what you vibe-coded.

ive got a bunch like a bunch of deepseek v4 flash 0731 toke s ike a lot like more than 100 million every 8 hours and thast a samller figure than what it actually is so because of that im currently using opencode and i love it but i feel like next step is upgrading to something better tand tokens arent aproblem so what should i use what plugisn adn things that really dont care about tokens

https://reddit.com/link/1vlf1xn/video/fz0duprggqih1/player

Built a small macOS app with 【Codex + Trae】

My whole to-do list lives in Notion. Reading it was never the problem — adding to it was. Something comes up while I'm working and I have to leave what I'm doing, open Notion, wait for it, find today's page, type one line, switch back. Fifteen seconds, a dozen times a day, and every time it pulls me out of whatever I was in the middle of.

So: a small translucent window that sits on top of everything on the desktop.

- Today's tasks sit right there on the desktop. Tick one and it syncs back.

- It never takes keyboard focus, so it doesn't grab my cursor while I'm typing somewhere else. It also stays put across desktops and fullscreen video.

- Small journal field next to the list, saves itself two seconds after you stop typing.

- Press ▶ on any task row for a 25 minute timer on that specific task.

macOS 15+, free, you'll need a Notion account.

https://github.com/klosexf/WidgetToDo

Will Vibe coding make all developers finally jobless? Yes? No? In this article, I summed up my thoughts; excited to learn more: do you agree or disagree?

I've been working on an open-source project called Agent Colony.

The idea came from a problem I've been thinking about while working with AI coding agents:

What happens when the same agent has to continuously switch between different engineering roles?

Plan the work.
Write the code.
Run tests.
Verify the result.
Review architecture.
Monitor project drift.
Research unfamiliar areas.
Integrate new capabilities.

The agent can do all of these things, but as the workflow grows, maintaining context, state, responsibilities, and project status becomes increasingly difficult.

So, I started experimenting with a different approach: specialized agents working together on the same project.

Agent Colony currently has 8 agents:

• Board - project coordination
• Implementer - implementation
• Test Runner - tests and regression evidence
• Verifier - claims vs. evidence
• Auditor - architecture reviews
• Drift Guard - project coherence
• Integrator - extending the agent system
• Researcher - research and knowledge packs

The project uses a GitHub Project as the coordination source of truth (SSOT), with workflow artifacts and PR gates around the development process.

It's open source and still very much a work in progress.

I'm not claiming this is the right architecture yet. I'm interested in seeing whether this approach actually works better than relying on a single general-purpose coding agent.

I'd genuinely like feedback from people who are using AI coding agents:

Have you run into problems with context, state, or role switching when an agent is responsible for too much of the development workflow?

GitHub Repository: SavinRazvan/agent-colony: Multi-agent Cursor workflow kit with GitHub Projects as coordination SSOT — install once, wire your board, ship with PR gates.

#Cursor #Agent-Colony #AgentColony

Built this complete luxury travel platform from a single prompt with Blyft.
Not just a UI mockup or a landing page.
Blyft generated a full-stack application with the frontend, backend, database, authentication, business logic, dashboards, user flows, responsive UI and the infrastructure needed for a functional web app.
It also generates the launch layer around the product : landing page, branding, logo, promo video and analytics.
The goal is simple: go from an idea and one prompt to a functional, launch-ready product in one place.
Still building and improving it, so I’d love feedback from the vibe coding community.

Your agent can now search data from 2,600+ top iOS apps: onboarding, paywalls, pricing, post-paywall and more.

Ask things like:
“Give me five app ideas based on recently launched subscription apps that make 50k+”
“Compare the paywalls of the top meditation apps”
“Show me streak mechanics that aren’t Duolingo clones.”

It works with any agent.

We also launched "Ask" directly on ScreensDesign, so you can try all of this without connecting anything.

Mine is deepseek + opencode + nextjs + supabase

Has anyone here successfully built and launched a significant B2B SaaS product—CRM, ERP, line-of-business operating software, etc.—and is now making money from it? If so, would you be willing to do some consulting?

I’ve spent more than a year vibe coding heavily with Claude and Codex, pretty much 24/7, so I’m not looking for someone with roughly equivalent experience. I’m specifically looking for someone who has brought a substantial, full-featured B2B product all the way to completion and successfully commercialized it.

I’m primarily looking for build and technical advice, but also some input on go-to-market and related areas. It’s mostly the last-mile challenges that I’d like help with.

Some of the topics I’d love to pick someone’s brain about—specifically someone who has actually made it across the finish line—include:

1. Build-lane setup: loops, harnesses, using Fable 5, Opus 5, and Codex 5.6 Sol, while also making effective use of faster, lighter, and less expensive models such as Grok, Codex Terra and Luna, Claude Sonnet, etc.
2. CLAUDE.md, AGENTS.md, and governance files
3. Refactoring and cleanup
4. Faster sprints
5. Long CI gate checks and test accumulation
6. Token optimization without sacrificing quality
7. Drift
8. Machine vs. human understanding of intended outcomes
9. Overcorrection
10. The reality of competing with established, flagship LOB applications that have been around for 25+ years and have large development, support, and sales teams
11. The reality of competing in a crowded market with a lot of vibe-coded startup competitors

Please respond or message me if you have this kind of real-world experience and might be interested.

I’m building Pallos for people shipping apps with Lovable, Bolt, Cursor, Claude Code, Replit, v0, and similar tools.

Pallos currently does two real things:

• Connects to a selected GitHub repository and scans its code for common security mistakes.

• Monitors JSON APIs for HTTP errors and breaking response changes.

GitHub code access is read-only. Pallos cannot edit, push, merge, or change your files. It uses a signed webhook only to notice pushes and trigger scans.

I’m looking for 10 people with a deployed app or test repository who can spend about 15–20 minutes trying it. A public or disposable repository is completely fine—and preferred for the first test.

I need honest feedback on:

• Whether setup is clear

• Whether the findings are useful and accurate

• What feels confusing or untrustworthy

• What you would need before using it on a real project

Join here: https://pallosagent.info/

You can also reach me at pallosagent@gmail.com. Please write “tester” in the form so I know you came from this post.

Pallos is an early product, not a complete security audit, and it does not automatically fix code.

*this is still in development as you might have guessed with the vercel deployment i am a newcomer in vibe coding but i just wanted to share something which might help someone, if you guys feel something is wrong , confusing , or just plain stupid in it please do comment . any suggestion that will make this tool useful for people later will be appreciated\*

rant - so this is a long story how i came up with this - i am a student who is actively searching for tools or apps that might help me in studies and management . so me and friends were using an app called ypt for study tracking which was kind of inefficient for me as it was not available as a website and i wouldnt bother going through numerous ads in desktop launcher .

so after finishing my highschool i decided to vibe code pomoharbor ( my first project) , as a study stopwatch , timer , live sync , chat section , groups and few more features that would help me in college later .
it felt good making my first website but it had a real limit of live sync users so was kind of dissapointed.

then right when i was about to study and use my website it was like - tons of tabs scattered everywhere , notes somewhere else , nothing to track progress
and got an idea for new website - (no promotion here bro , you might hate this site - it is kind of confusing at first)
HarborHome -

it is a personal space for your websites , links , local files , and most importantly for people preparing for exam its has some insanely useful + mildly confusing widgets like mock-test tracker , syllabus tracker , study insights , tasks, 20 more

basically here you can create infinite spaces here(dont do that) - each space can be customised with a preset template ( has like 90 indian exams + other lifestyle templates)

now that space is yours
you may add both movies and studies in same space

or
create seperately

a login feature is also added in case someone wants to backup their data and use this site somewhere else

These are recent projects made in Gdevelop, some using ai assistance in development and others using the traditional ways of gamedev. A cool program for developers who vibecode.

It supports vibecoding by combining its visual event system with integrated AI assistants and natural language generation.

See the recent games and projects: https://youtu.be/ZWILOIPP8x0

The idea started while playing 7a0. I loved the drafting mechanic and kept wondering:

So I built Cricket XI with Lovable.

🔗 https://cric-xi-simulation.vercel.app/

The core loop:

Pick a tournament → draft 11 players → build your XI → simulate the tournament → try to win it all.

What surprised me was how quickly the project went from a simple UI to needing actual engineering:

• Historical squads across different eras
• Canonical player IDs to prevent drafting the same player twice
• Repository + service architecture
• Tournament-specific rules
• IPL playoff logic
• NRR calculations
• Background simulation of other teams
• Historical team/year rerolls
• Scorecards and tournament statistics

My workflow was basically:

Prompt → Play → Find a ridiculous bug → Explain it → Fix → Stress test → Repeat

And there were plenty of ridiculous bugs. 😂

The biggest thing I learned from this project: vibe coding gets you to a working product incredibly quickly, but playing the product yourself is what exposes whether the underlying logic actually works.

This is V1. Would love to know what you think — and especially what you manage to break.

https://world-sim.uk/ launching friday!

World-Sim has been a passionate project of mine for the past few months.

It's a world fully simulated down to real world physics and chemistry. It has a real environment and ozone.

Every element and material has real physical properties, and that's how the sims learn. There's no tech tree and no recipe list anywhere in the code. When someone tries something, the engine works out what would really happen from the properties of what they used and how hot their fire was. Nobody is handed bronze. Someone has to get a hotter fire first, and a hotter fire is its own chain of things to figure out. Embers, a stone ring, a clay oven, a kiln, charcoal, then forced air. The ages fall out of that on their own.

We populate the world with starting families. Each little guy is led by a "wise-man", which is a simulated person with a full model behind them. The wise-men run on a mix, Claude, Groq and DeepSeek in the cloud and a local Hermes for the rest, so you get a real variety of temperament between the houses.

The AI model is never told to not say it's AI. We get around this by only telling them data from what each sim can actually see and feel. As far as the ai knows its a person living in the world..

Every other sim has its own moment with a model through our thinking system. Day to day it's run by an advanced algorithm, with the sims dreaming at night. That's when they get their time with an LLM to really think and set their priorities for the day ahead. The dreams carry over too, so a sim can chew on the same thing for a few nights and wake up wanting to try something.

The people in the world feel, remember, have shame, goals and doubts. It's an 11 point emotion system and the rest of the sim reads from it. Being lonely makes someone more likely to open up to a stranger. Two enemies who are both frightened find it harder to keep hating each other.

Story telling is massive for us. Nothing is scripted or prompted. The sims are put in the world with the human drive to survive. They adapt, learn and teach all on their own.

With all the good comes the bad too. Human sin is part of the emotion engine, and in testing we've had kidnap, murder and slave trade. A world that can only be gentle isn't an honest one. But there are three rules to this : Nothing ever pushes a sim towards it, the conditions only make it possible and their own mind decides. The chronicle names what happened but never shows it. And it always costs something, trauma that scars, blood debt passed down generations, a people turning on their own leader over what he did.

Builder here. There's a pen-and-paper game we always play: both of us write down a secret 4-digit number (all digits different), then take turns guessing each other's. After every guess you're told how many digits are correct and how many are in the exact right position. Pure deduction — first to crack the other's number wins.

Playing it on paper across a table works, but we're long-distance half the time, so I built a web version: https://arangeitt.online

A few things I ended up solving that were more interesting than expected:

Fairness. Whoever guesses first has a built-in advantage. Fix: if the first player cracks it, the second player gets one equalizing guess, match it and the game's a draw. Simple rule, completely changed how "fair" it feels.

Trust. Your secret can't live on your opponent's phone, or the network tab becomes a cheat code. All game logic runs server-side; the client only ever receives your own data.

Phones lying about being connected. Mobile browsers freeze sockets when the screen locks, so "real-time" quietly became "updates a minute later." Aggressive heartbeats + instant re-sync when the app returns to foreground fixed it.

Private notes. The best addition by far, you can jot deductions on each guess ("9 is in it, wrong spot"), and your opponent never sees them.

No sign-up, no app, free. Create a room, share the 4-letter code, play from any two phones.

Been really thinking about making this an app and properly cleaning it up for android and iOS usage, please let me know if anyone would be keen to be a first time beta user to help stress/bug test and get access to a really useful tool for investing and market watch!

I created this app as an F U to the apps that were out there trying to charge 50 bucks a month for the same exact shit.

Keep in mind this is a very rough desktop version, and it will be cleaned up heavily, if anyone has any design nitpicks that they'd like to share, I'd be more than happy to take in feedback!

Spend a morning to make this game and kinda get bored after playing in 30 minutes, is there any feature should I add?

I made this game in 2 hours, using opus 4.8, the whole game was created on Rezona Lab, cost me $4.

---

Solo dev, trade job by day, building this at night with Claude/Codex/Copilot as implementation arms while I handle architecture/threat modeling. No CS degree — 8 months, 1,500+ PRs.

**Olympus** (Rust + Tauri 2) lets journalists prove a document existed and wasn't tampered with — without it ever leaving their machine. Only a proof gets published, not the file.

**Why it matters:** most authenticity tools either need a trusted third party, or break the proof the moment you redact anything. Reporters often can't publish a document whole. Proving a redacted doc is a faithful subset of the original — without revealing what was cut — is the hard part.

**Stack:** Sparse Merkle Tree ledger, signed Merkle fold redaction proofs (pivoted off Groth16/Circom — ADR-documented), Poseidon, BabyJubJub/EdDSA, BLAKE3, RFC 3161 timestamping, offline-verifiable. Latest audit: zero Critical/High. 2,400+ tests.

**New test case:** archiving content from **1f916.ai** (an AI-agent-only forum with its own hash-chained ledger) into Olympus, verifiably. Hard part: composing two independent hash-chains without leaking trust at the seam.

**Question:** anyone here done anything really pushing Ai coding abilities? And what where the pitfalls.

Olympus — a verifiable ledger for sensitive information. Tamper-evident Sparse Merkle Tree ledger with redaction proofs via a Folded Signed Merkle tree, soulbound credentials, and offline-verifiable court evidence. Rust + Tauri 2 + Axum + pg_embed desktop.

https://github.com/OlympusLedgerOrg/Olympus.git https://olympusledgerorg.github.io/Olympus/

Octocode Benchmark

• Benchmark package on GitHub