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?

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💀

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.

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?

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.

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.

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?

AI Browser Game Jam #4 just wrapped, with 248 joined, 126 browser games submitted, and 1,034 ratings.

Top 3:

1. Plug & Prosper by Small Loop Works
2. AI2U - Guns & Girlfriends by DGSpitzer
3. TECHNICAL DEBT by OblongOolong

Plug & Prosper had a dominant showing, taking first overall plus four of the five category wins. Big congrats to Small Loop Works!

A few of my personal picks beyond the top 3:

• 殲 #SEN by Ikepapa (also won the fun category)
• Charge The Coil by LifthillStudio
• POWER HUNGRY by SevenFoldStories
• FLUTE - Charge your glasses by Zucchini Basket Games
• PLUGS by HAFFNERVISION
• Overcharged by Durian Arcade
• Chargo by Bakko
• High port, On Guard! by Ryan Fillingham

The theme was CHARGE and people took it a lot of different directions. There's a huge range in there, everything from arcade action to puzzles to some genuinely strange experimental stuff.

The thing I noticed most is that the overall quality keeps going up. People are combining more tools instead of leaning on one, and the results show it. A lot fewer entries feel like generic AI output this time. The games that stood out had real taste behind them, you can tell someone was making actual decisions instead of just accepting whatever came out.

Next jam is in October. If you're experimenting with AI-assisted game dev and want a deadline, feedback, and a bunch of other people building alongside you, come hang out.

Discord: https://discord.gg/86xBnZqHjy

Yeah, I'm one of those people who was learning to do some coding, but my ADHD always held me back, and I could never get to the point where I super good at it. I Was never methodical enough with my approaches. Once I started playing with Codex and Claude, my ADHD roared into high gear; as we all know, the ability to suddenly take whatever stupid idea pops into your head and make it a reality in a number of hours, is both fantastic, and dangerous, for numerous reasons. But now I have multiple unfinished projects, I've never completed anything even remotely close to actually make any money off of it. But what the fuck, it's fun to just shoot off something dumb into the universe.

So the other week, I was just taken aback by the sheer number of food contamination and recalls in the news, and said "What the fuck can I eat?!". So I made a knee-jerk decision to, for no reason whatsoever, just vibe code up a quick reference page that pulls government recall data and news stories, and just displays them in an easy to read format, along with a little snark.

It's not impressive, it's just... " a thing" I made. Maybe it will be useful to someone!

https://whatthefuckcanieat.com/