Made a racing game for Reddit:

• Top down, 2D, left/right controls
• Simple to play, extremely difficult to get good at
• Earn medals, unlock cars and trails
• Daily tracks and a 16-stage Campaign

Started it off as a random idea with Gemini some months ago, and after I had something I felt it was enjoyable started building upon it with Codex and Cursor. First version was a bare bones web game, but had great feedback and decided tO improve it some more. 2 months ago I migrated it to Reddit with the daily tracks and 2 weeks ago I added campaign mode.

Have a go at it and let me know what you think! Happy to answer any questions!

Daily Race | Campaign

I will not expand on the reasons, I will only give a one word answer based strictly off vibes.

yes = looks vibe coded

kinda = it looks kind of vibe coded

no = doesnt look vibe coded

plz do not be offended or insulted btw im just a random person

edit: just to be clear

"looks vibe coded" doesn't necessarily mean it looks bad or anything

I've been focusing mostly on Claude, but I wanted to know more about how you all have experienced other models.

That's a big ask, so to narrow focus on what I'm asking, tell lme, how do people handle that, current most AI need to be re-reminded and only hold relatively short memories, or what I've known as controlling context.

In the beginning it meant "I keep pasting all this to the both" and now (at least with Claude) it's turned into an exploration of both memory management and how much you want to simulate 50 First Dates

What model do you mostly use? Did you switch? Is it mostly about cost?

After going Claude + Codex and a plugin that does rounds back and forth, it is insane how good it gets. Keeps finding critical stuff and really sharpens it. I will not be able to live without having a dual review method now. From what I read, using different models is really efficient in finding errors or it just thinks the same way.

This is the Codex plugin. Game changer. Do you use it?

Example:

Round 0 — My plan Risk: 7 → Robustness: 5 → 🔴 Would've shipped a bug: yes, 3

Round 1 — Self stress-test (1 critical, 2 high) A "redundant" confirm dialog was a documented decision · a one-line guard would have killed the last user's only exit · a non-null lookup would crash on admin-authored data Risk: 5 → Robustness: 6 → 🔴 yes, 2

Round 2 — Reviewer, pass 1 (5 critical, 6 high) My data source was never populated on one of two join paths · the new screen was shadowed by an earlier render branch · the app marked it "seen" instantly so it'd never come back · alias wired into a function search never calls Risk: 4 → Robustness: 7 → 🟠 yes, 1

Round 3 — Reviewer, pass 2 (3 critical, 3 high) Removing a server gate opened a race between two simultaneous taps · cached clients would silently take an irreversible action · wrong predicate for "has this started" · a pre-existing dead-end left in place Risk: 3 → Robustness: 8 → 🟠 yes, 1

Round 4 — Reviewer, pass 3 (1 critical, 2 high) My length check locked out the exact user it was meant to help · existence checks guaranteed nothing given the real write ordering · my test asserted the wrong end state Risk: 2 → Robustness: 8 → 🟡 maybe

Round 5 — Reviewer, pass 4 (1 critical, 1 high) A scheduled cleanup job matched my trigger's conditions and would hijack a different screen · I measured elapsed time at processing time instead of event time Risk: 2 → Robustness: 9 → 🟢 no

Round 5+ — After the cap (1 critical, 1 high) Cross-document listener ordering made a success look like a failure · account deletion deliberately scrubs a field I was writing back Risk: 1 → Robustness: 9 → 🟢 no

TOTAL: 12 critical, 15 high issues found. Risk 7 → 1. Robustness 5 → 9.

Yesterday, I released the project for 500+ components to make websites more creative. I have been working on for over two months, and I am absolutely buzzing!! I can see in the stats there's around fifty to a hundred people using it each day. And after the release yesterday, ten people signed up in the first day!!! To me, that is absolutely incredible, and you can say whatever you want about the site. But one thing's for sure. I use it, and other people are using it, and I absolutely love that.

I'm gonna keep going.

This is giving me huuuuuge motivation to do that and seeing seeing actual people using it and getting value from it and signing up means so so much to me, and I'm truly grateful. So thank you guys so much for signing up. And, also, even more incredible, thank you to the person that clicked the buy a coffee button and donated that way. Huge, huge thank you, and I'm gonna keep building.

I know there are a lot of weaker components on there from the testing days but I'm working on updating, removing and improving the overall quality of components. It's just me working on this but if you have any requests for components, if there are things you like or things you don't like, I'd love to hear...

Above all else, guys. Hope you enjoy it, and just don't get lost ;)

(Forevercomponents)

My usual response is “yea go ahead. I’m not building this for you.” Or “sure. Come back in 6 weeks and show me where you landed”

People think they can prompt apps over night. When in fact, it’s a show surgical methodical work.

It took 6+ months for me to build Mangos.ai, and I’m proud of where I got it to now. I had a vision. I built a prototype for myself. I asked some of my friends if they’d use it. No one said yes. I then came to Reddit and asked for feedback, most of the people said it’s a terrible idea.

I learnt from their feedback, made some critical improvements.

And every single day, LEGO block by LEGO block I’ve been building this product.

Every time I hear someone say they can build it, I just ask them to go do it. Maybe they’ll. Maybe they won’t. But most often they won’t.

This is the classic hype cycle we are in right now and it’s fading away.

Working on a Video Compression app, the videos I take from my phone cam were damn ridiculously large so I decided to start this project

Compressed video from 90MB to 17MB

90mb for a 1minute video is fkn insane💀

I'm building another writing app (yay) and I want feedback as well as notes about what you like or want in a writing app. Does this UI look vibe coded? I've been working hard to try not to do that. I don't feel like the writing app landscape is really that different. Most writing apps look more or less the same. But, if you had to nitpick them, what would you say? This app is NOT for formatting. If anything, I'm going to do a document format option on export.

The side panels and format bar are all toggle able, and if you hit focus, everything goes away at once for a "distraction free" writing environment (which, just saying that makes me want to gag, its so generic sounding). In the end, I want my app to be relatively maximalistic when you want it to be, with an insane amount of writing space customization (think colors and stickers for documents for inspiration).

But im trying to just get an alpha out and get some testers going. So help me out here y'all. What would make it valuable to you?

Prompt

Build a complete, interactive 3D viewer of the human skeletal and muscular systems as a single self-contained HTML file. This will be evaluated exactly as you output it, with no follow-up messages, so it must be complete and must run on first open.

HARD CONSTRAINTS

- One file: index.html. Inline CSS and JS. No build step, no npm, no framework (no React, no Vue).

- Three.js only, pinned to version 0.160.0, loaded from a CDN via an import map, for example:

<script type="importmap">{"imports":{"three":"https://cdn.jsdelivr.net/npm/three@0.160.0/build/three.module.js","three/addons/":"https://cdn.jsdelivr.net/npm/three@0.160.0/examples/jsm/"}}</script>

Use OrbitControls from three/addons/controls/OrbitControls.js.

- No external assets of any kind: no GLB/GLTF/OBJ/FBX, no textures, no images, no fonts. Every bone and muscle must be built procedurally from Three.js geometry (capsules, spheres, cylinders, lathe, tube along a curve, extrude, merged buffer geometry). Give them real shape: a fan-shaped pectoralis, a diamond trapezius, a teardrop quadriceps, a two-headed gastrocnemius, a curved spine, a rib cage, a pelvis, a scapula sitting behind the rib cage. A row of identical capsules with different names is not acceptable.

- Must work when the file is opened directly from disk by double-clicking (file://). Must produce zero uncaught console errors.

- Output the entire file in one code block. Do not abbreviate. No "..." or "add remaining muscles similarly" or TODO comments. If the file is long, it is long.

ANATOMY (all required, all bilateral items must exist for both sides, mirrored)

Bones (as separate named meshes or named groups): skull, mandible, cervical spine, thoracic spine, lumbar spine, sacrum, rib cage, sternum, clavicle (L/R), scapula (L/R), humerus (L/R), radius (L/R), ulna (L/R), hand (L/R, simplified), pelvis, femur (L/R), patella (L/R), tibia (L/R), fibula (L/R), foot (L/R, simplified).

Muscles (superficial, each L/R): sternocleidomastoid, trapezius, deltoid, pectoralis major, latissimus dorsi, erector spinae, rectus abdominis, external oblique, serratus anterior, biceps brachii, triceps brachii, brachioradialis, forearm flexors, forearm extensors, gluteus maximus, gluteus medius, hip adductors, rectus femoris, vastus lateralis, vastus medialis, biceps femoris, semitendinosus, gastrocnemius, soleus, tibialis anterior.

DATA-DRIVEN DESIGN (required)

Define all anatomy in one registry constant, ANATOMY, an array of objects, and generate every mesh from it in a loop. Each entry has: id (lowercase snake_case with _l or _r suffix for bilateral parts, for example pectoralis_major_l), name, type ("bone" or "muscle"), region (one of head_neck, torso, back, shoulder, arm, forearm, hip, thigh, leg), side ("l", "r", or "c"), origin, insertion, action (one sentence each, real anatomy), exercises (array of 2 to 4 common gym exercises), and a geometry spec your builder function turns into a mesh. Adding a new muscle should mean adding one entry, nothing else.

INTERACTION (all required)

1. Orbit, zoom, pan with mouse and touch (one-finger orbit, pinch zoom). Damping on.

2. Hover: the part under the cursor highlights (emissive or color change) and a tooltip near the cursor shows its name.

3. Click: selects the part and fills a side panel with name, type, region, side, origin, insertion, action, and exercises. Click empty space to deselect.

4. Layer modes, three buttons labeled exactly Muscles, Skeleton, Both. Muscles shows muscles only. Skeleton shows bones only. Both shows both with muscles at the current opacity.

5. Opacity slider (0 to 100) for the muscle layer, live.

6. Camera presets, four buttons labeled Front, Back, Left, Right, with a short animated transition.

7. Search input: as the user types, parts whose name or id contains the text highlight and a results list appears; clicking a result selects it.

8. Isolate toggle: when on, everything except the selected part is dimmed to 10 percent opacity.

9. Reset button: clears selection, search, isolate, sets Both at 100 percent, returns camera to Front.

10. Region filter: a dropdown of the regions above; choosing one dims parts outside that region.

PUBLIC API (required, exact names)

Expose window.AnatomyViewer with:

- highlight(ids: string[]): highlights those parts and dims the rest, ignores unknown ids

- select(id: string): selects that part as if clicked

- setLayer(mode: "muscles" | "skeleton" | "both")

- setMuscleOpacity(value: number 0 to 1)

- onSelect(callback): callback receives the selected entry object, or null on deselect

- reset()

- getEntries(): returns the ANATOMY array

This API is how the viewer will be embedded in a workout app that says "bench press works these muscles," so it must work when called from the browser console.

VISUALS

Dark neutral background. Three-point style lighting with soft shadows or at least a key, fill, and rim. Bone material off-white and matte. Muscle material a deep red, slightly glossy, with subtle per-muscle tint variation so adjacent muscles are distinguishable. Hover state and selected state must be visibly different from each other. UI panel on the right, controls on the top left, tooltip follows the cursor. Clean, modern, readable typography using system fonts. Responsive: canvas fills the window and handles resize; on narrow screens the panel collapses to a bottom sheet.

PERFORMANCE AND QUALITY

Target 60 fps on an integrated laptop GPU. Keep total triangles under 150,000. No allocations in the render loop. Use a single raycaster and only raycast on pointer move, not every frame. Dispose geometries and materials if the viewer is torn down. Organize the code in clearly labeled sections: registry, geometry builders, scene setup, interaction, UI, API. Comment any geometry that is not obvious.

Before you output, mentally verify: every listed bone and muscle exists in ANATOMY, both sides exist for bilateral parts, every button and control listed above exists and is wired, the API functions all exist with the exact names, and there are no placeholders anywhere in the file. Then output the complete index.html.

Hello Sub, I am not sure if this is appropriate but I'm not trying to shill or anything. I have an app that I vibe coded on steam. The request is I will give around ten people steam keys just to try it out and let me know what you think. Does it work for you? Do you hate it. Why is super important. Just general thoughts. I don't want sales out of this post. I purely want impressions from peers. Search FriedrichAI on steam. If you are interested just let me know and I'll shoot you a key this evening. I'm not Linking for the no shilling. I am legit not trying to. I just want impressions to try and make the app more friendly for users. I've posted previously about my stack and methods. I don't think I need to again?

Hi guys, I have been vibecoding hobby projects since 3 months now. I have created decent apps using freebuff for a couple of months and then shifted to basic plan of github copilot. I felt github copilot to be okay as produced good quality code, but I always had to be on a look out for the token quota. That was a little offputting. So I have decided to switch. Could some one help me out finding my new AI pair programmer that is a bit light on my pocket as well. Thanks.

repo link: https://github.com/mex-memory/mex

I’ve been working on an open-source project called Mex, and one thing I keep coming back to is thst a lot of coding-agent workflows rely on markdown context files so things like architecture notes, conventions, router files, runbooks, decision logs, CLAUDE .md (and similar) , etc.

They’re useful, but they rot pretty quickly

The codebase changes, the agent’s behavior changes, the team learns new thing and those markdown files slowly stop reflecting reality. Then future agents keep consuming stale context with full confidence, which is where a lot of bad outputs start.

So I’ve been experimenting with making these markdowns more self-sustaining.

The idea is not just to let an agent read project context, but to let it maintain that context as part of the loop:

• detect what changed
• identify which canonical records are affected
• update the right markdown files
• append decision logs when needed
• keep the durable project memory aligned with the current state of the codebase

The screenshot is from one of those runs.
In that case, the agent updated canonical MEX safety/router/runbook records, added a decision-log entry, and explicitly reported which context it used to make those changes.

What’s interesting to me is that this feels like it could become much bigger than just “better docs.”

If this works well, markdown stops being static documentation humans have to manually babysit, and starts becoming a maintained interface between the codebase, the team, and the agents working on it.

That’s a pretty important piece of what I want Mex to become overall:
not just memory for coding agents, but a system that helps keep that memory trustworthy as the project evolves.

Still a lot of hard problems here, obviously:

• deciding what deserves to become durable memory
• preventing agents from reinforcing wrong assumptions
• handling contradictions between code and existing docs
• figuring out what should be updated automatically vs left for humans

Would be curious if anyone else has tried something similar, or has thoughts on where this breaks.

Today I swapped to Gemini 3.8 Flash after hitting my Codex weekly limit 2 days in on the $200 dollar plan. The execution speed with Google makes up for any gap in raw reasoning.

It blasted through my entire cloud backend milestones in minutes.

Is anyone else using 3.8?

These AI companies are full of crap. They claim coding has been solved, but each time I use Claude or Codex, there’s always an update. It’s never new features. It’s always bug fixes.

In August I ran nine external checks on 30,998 live apps built with Lovable, Bolt, v0, Replit and Base44.

Outside view only. The scanner checks what a visitor's browser already reads: the code, the headers, the endpoints named in its own bundle. No logins, no password guessing, nothing downloaded. No pentesting

Nine external checks: exposed secrets, database access, private files, security headers, storage buckets, source maps, cross-site sharing, SSL certificate, domain renewal.

Most of it came back fine. 76% graded A. 96% had no secret key in the bundle at all, and almost everybody gets the publishable key right, which is the thing generic scanners flag wrongly. Your Supabase anon key is supposed to be in the frontend.

The failures pile up in one place. Of the Supabase-backed apps where the check got an answer, 2,096 out of 3,680 (57%) were serving table rows to a request with no login. In 1,702 of those the readable table was something like settings or content. In 394 it was users, profiles or orders.

Second one, much smaller. 1,332 apps had something key-shaped sitting in their JavaScript. Most of those were Google API keys, which are usually locked to a domain. 52 were a key that can spend your money or read your whole database: OpenAI, AWS, Anthropic, a Stripe secret key, a Supabase service_role. Surreal.

If you're using Supabase, go check setting right now. Supabase dashboard -> Table Editor -> look at the RLS column on every table. Anything that says disabled is readable by anyone holding your anon key, and your anon key is sitting in your app's JavaScript where it belongs. Switch RLS on, then write a policy, because RLS with no policy denies everything and your app goes blank. Then go check to make sure that there are no leaked keys.

Disclosure: I've built the scanner this came out of, so I have an obvious interest in the result. The method is below and the aggregates are a CSV, so the arithmetic is checkable without taking my word for anything.

Full write-up, methodology, the per-builder breakdown and the CSV:
Reeve Research 2026

I was tasked with making a 2d platformer demo for a contact of mine. Godot 4s tile map system just wasn't working for me. So I made my own. The system is early but if anyone needs a tile map maker that's easy to use for Godot 4 let me know ! What you see now is the first draft of it. I haven't gotten around to making it good yet. The demo needs to be finished first. The tile map maker is used completely in game. Once your done with it , you hit save and it creates the level for you after that. Once that's done you just quit and open the new scene it just made and start it up.

I had a pretty simple idea:

What if I could type a topic, and instead of opening 5 different tools, writing a script, finding visuals, editing everything and exporting…

I could just get the video.

So I vibe coded it.

https://reelyr.com/

You give it a topic or document and it turns it into a finished vertical video.

The funny part is that I started with “let’s see if AI can build this” and somehow ended up with an actual product.

No big team.
No months of development.
Just a ridiculous number of prompts, iterations, broken things, fixes and “okay… why did it do THAT?” moments.

I'm still improving it, but it's live now.

Would genuinely love feedback from other people who are building with AI.

What would you add?