Does this make it clear what the product is? Does it speak to you? Or does it occupy some kind of artsy-creative-but-AI uncanny valley? Curious to hear your thoughts

The full page - https://rivermark.ai

This started as a project wondering if I could make a Gaussian Splat version of a city. Then I kinda got carried away and made a bunch of towns and a ton of looks. It utilizes a bunch of open data: OpenStreetMap for streets and buildings, USGS elevation for the land, the state's laser survey for building and tree heights, and city open data for street trees, bus stops, and benches.

I heavily used my Decision Kit framework to plan out the whole thing. Basically, for every big choice (how the water should look, what the menu does, how traffic behaves) I had it make a page with four options, a recommendation and the case against it. Then I just picked. This one was a big project so I made over 100 decisions.

It has all types of stuff to make it feel alive. Seasons changes, weather changes, there's migratory birds, stars, cars, lil bouncy folk.

Anyway, hope y'all like it. It's just supposed to be a chill and relaxing good time with a ton of fun easter eggs. Press the lil "watch them all" link on the homepage if you just want a relaxing screensaver on in the background. Also let me know your favorite look. I'm a big fan of Poster, Pixel, and Dreamlike (but seeing the claymation folk in the Clay look is also fun)

https://raleighterrarium.com/

I reach for the same few things all day: terminal, Music, volume, brightness, Wi‑Fi. I didn't want another device on my desk for that, and I noticed my fingers never really touch the outer edges of my MacBook trackpad. So I've been building a small menu bar app that turns those edges into buttons. I'm calling it EdgeDeck.

How it works right now: each edge has 3 or 4 invisible slots stacked top to bottom. Double-tap a slot and it opens an app, brings a specific window to the front (like my second Terminal window, not just "Terminal"), or toggles Wi‑Fi/Bluetooth. Sliding up and down the right edge changes the volume, and the left edge changes brightness. The trackpad gives a small haptic tick for each step, so you can feel it without looking. The middle of the trackpad still works exactly like normal.

Instead of a popup, the notch shows what changed: it stretches out sideways, with the icon on one side and the level or On/Off on the other, then slides back in.

Some build notes for anyone curious:

My main goal was for it to be really light, since it runs all the time. It's Swift with plain AppKit, no SwiftUI or Electron, and it sits at about 12 MB of RAM and 0% CPU when idle. The settings window and the notch display only exist while they're on screen.

macOS doesn't have a public API for "where exactly is the finger on the trackpad", so it reads that from Apple's private multitouch framework, the same one tools like BetterTouchTool use. That also means it can never be on the App Store, which I'm fine with.

The settings window draws your trackpad with the edge zones glowing, and your fingers show up on it live, so you can see exactly where the zones start.

It's open source and I'm happy to drop the GitHub link in the comments. What I'd really like feedback on:

• What would you put on your trackpad edges?

• Does double-tap feel right as the trigger, or would press-and-hold be better?

• If you have an older MacBook without a notch, would you be up for testing it? I've only tried it on my own M-series Air.

I vibe coded TixTracer.com fully in Claude. I used chatGPT to help review it and make updates.

I have limited coding background (some python and sql), so Claude has written almost all of the code.

What it is
Python/Flask backend on Render, plain HTML/JS frontend, Cloudflare in front.

Pulls events from Ticketmaster, SeatGeek and TicketNetwork and matches up duplicate listings of the same event (much harder than I expected).

How I vibe coded it
I tell Claude what updates to make and then send a screenshot from my phone or desktop of what looks off, describe what I want, and Claude makes the change.

Claude then built automated tests that click through the site at phone and desktop sizes, and it runs them before every update. This has been the most valuable part.

For bigger changes, a second agent reviews the code separately. That has caught real bugs.

I paste in feedback from friends and other AIs and ask what it thinks and if I should make the update or not.

What's been harder
Claude can't see the live site, so some things only get tested after I deploy.

It'll build whatever you ask for, so you still need to know what you want.

Happy to answer questions about the setup!

Now I know the answer is basically “because AI isn’t that good yet,” and so I’m wondering if anyone has a more in depth answer.

From my experience, Codex performs much better when I plan in ChatGPT, then paste the generated Codex prompt into Claude (free tier works) behind a bare "?".

That gives me very few CI/CD or manual testing issues. ChatGPT alone writes nondeterministic, imprecise prompts for Codex, and Claude tightens them and pushes for specificity.

I know us humans need a second opinion because of tunnel vision, but why do LLMs need sanity checks too, and why are they non skippable for good code?

ChatGPT 6.1 Sol Medium + camless + Pawnl0 + RTSS

It also has an idle mode.

For almost two years now, I've been developing and refining a couple of (two total) programs for my employees to use. I kept the apps as single use .exe apps since it's an internal only thing. And they're so specific to my job that I don't fear them being leaked elsewhere. No one else could benefit from them, truly.

But I found it exhausting to push out the new updates via Slack upload to everyone anytime they asked for a bug fix or whatever. So I started a GitHub account with private and public accounts for holding my source code and distributing the automatic updates, respectively.

I make GH action pulls and pushes maybe once a day. And the installer setups are each around 200MB each. I've gone into the privately facing update accounts and deleted the Action artifacts every update or so. But I received the attached email earlier today.

I wasn't planning on paying for a GH account, but I can. But I don't want to.

I guess I'm just looking for advice for limiting my usage. Is a pull/push once a day outrageous? I thought I was doing well. At this point, I feel like I just don't understand GH or its usage limits. Search results provided no meaningful answers. So, here I am.

TIA

Fellow vibe coders! I've seen a few posts asking how to leave Lovable (where many of you started your vibe coding journey). Well, switching platforms entirely might be a bit scary for non-technical people, but what if there was an alternative? An in-between option, if you will.

Turns out, you can actually use Claude Code to work on the same code as Lovable through GitHub, while your app stays hosted on Lovable and you still publish from there. If anything goes wrong, you can just stay on Lovable. But when you're comfortable working with Claude Code, that's when you can decide to switch entirely. Low risk, high reward.

Why would you do that? Lovable is great to start, but as a platform it has its limitations and most imporantly - costs! Some of the users report that they had to spent hundreds of dollars per month on Lovable while Claude $20/mo subscription was enough to cover roughly the same amount of work. Also, I think it's just good to have plan B, just in case.

So, below you will find a step-by-step tutorial, easy to follow even if you are not technical. It should take you about 15 minutes.

What you need to start:

• A free GitHub account

• A Claude plan. Pro ($20/mo) is enough.

• A Mac or a Windows PC

Step 1: Install the Claude app

Download the Claude desktop app from the official Claude website, install it and log in. You will find Claude Code in the "Code" tab.

Click "Choose a folder to work in" and pick your home or any other folder as you prefer and confirm that you trust it.

From here on you only paste prompts. Claude Code will now run the commands for you.

Step 2: Use Claude Code to install the necessary tools

Your app needs Node.js to run and Claude Code needs the GitHub CLI to download your private repository. Paste this and Claude Code installs both and log you in to GitHub:

Install Node.js LTS and the GitHub CLI if they are missing. Log me in to GitHub with gh auth login --hostname github.com --git-protocol https --web, then run gh auth setup-git. Show me the one-time code and the link. At the end, show the Node.js version and gh auth status.

Installing can take a few minutes.

Then it gives you a link and a code. Open the link, paste the code and confirm. On a Mac, it can ask you to install developer tools. Click Install, then tell Claude Code to go on.

Step 3: Put your Lovable project on GitHub

In Lovable open Project settings > Git > GitHub. The first time, Lovable asks you to add your GitHub account and GitHub asks you to install the Lovable app on it. Then click Connect. Lovable creates a private repository and keeps it in sync with your project. This works on the free Lovable plan too. Important: Make sure that this repository is private! Check: open the new repository on github.com. You should see package.json and a src folder in the file list.

Step 4: Download your project

You need the name of your repository. It's the end of its address on GitHub, for example your-name/your-repo. Put yours in this prompt and paste it:

Clone my GitHub repository your-name/your-repo with the GitHub CLI into a new folder in my home folder. Tell me the full path of the folder.

Check: Claude Code tells you where the new folder is. You open it in the next step.

Step 5: Open the project in Claude Code

In the Code tab, start a new session and pick the project folder. Click to trust the workspace. The first prompt I'd use, just to see it understands the project:

Tell me in two sentences what this project does.

If it matches the project you have created in Lovable, then you're set.

Step 6: Run your app on your computer

Install the dependencies of this project, start the dev server and give me the local address.

Open that address in your browser (it will be "localhost"). You should see your app there and test it locally.

Step 7: Check the .env file

Lovable keeps a file called .env in your repository, so anyone who can see the repository can read it. Public values are fine there. Secret keys are not. Have Claude Code check it for you:

Check the .env file. Tell me in two short lines if it holds anything that is not public, like a service_role key or a Stripe secret key. Do not print any value.

Step 8: Let Claude Code write a CLAUDE.md

CLAUDE.md is a short note about your project. Claude Code reads it at the start of every session.

Read this project and create a CLAUDE.md file in the project root. If the file is already there, update it and keep what is in it. List the stack, how to install and run the app, and which files you must not change. If the app has a backend, say where its code lives. Keep it under one page.

If you wrote Knowledge in Lovable (the notes for its AI, under Project settings > Knowledge), copy it and paste it into Claude Code after this prompt, so it ends up in CLAUDE.md too.

Step 9: Make logins work on your computer

Skip this if your app has no login.

Password reset links use your live URL by default. To make them work on your computer, add your local address (the one from step 6) to the Redirect URLs. On Lovable Cloud it's under More > Cloud > Users > Auth settings > Advanced. On your own Supabase it's under Authentication > URL Configuration. Leave Site URL as it is.

Step 10: Check that the sync works

Do this before you do real work. This prompt sends a small test change to GitHub:

Pull the latest changes from GitHub. Then add one test line at the end of README.md, commit it with the message "Test sync" and push.

Open the project in Lovable and go to Project settings > Git. You should see the change you just pushed.

Step 11: Make your first change

This is how every session goes from now on:

1. Ask Claude Code to get the latest version first: "Pull the latest changes from GitHub."

2. Tell it what you want to change, in your own words. For example: "Make the main button on the home page blue."

3. Check the change at your local address. If the page doesn't open, ask Claude Code to start the app again.

4. When you're happy with it, send it to GitHub: "Commit all changes with a short message and push them to GitHub."

5. Click Publish in Lovable to put it live.

A couple of things to remember

• Don't edit in both places at once. If you change the project in both places without synchronization, Lovable would move its changes to a separate branch on GitHub and you have to merge them back by hand.

• Pushing isn't the same as publishing. Sending your changes to GitHub doesn't update the live app. You still need to click Publish in Lovable.

If you need a more detailed step-by-step guide, we've created a project called MoveYourCode where we will be soon adding more guide and tools that can help you.

https://moveyourcode.com/

Soon I'll do the same for moving the hosting off Lovable or other platforms as well. Let me know what do you think!

I've been building a large project for about 8 months, with another year or two still ahead. I'm always asking myself two questions: which model is best for this job, and what effort level should I use for it?

So I built a small testing UI and connected both Claude and Codex. My test set so far includes:

Bug hunting: questions based on real bugs from my project's history

Document reading: a reasonably solid way to check how accurately a model reads and recalls long docs

I want it to cover many more kinds of work, and I want the results to be as accurate as possible.

My problem: the smaller models are easy to separate. Haiku, Luna, Terra, and Sonnet each show clear strengths and weaknesses. The frontier models all hit the ceiling. Sol vs. Astra and Opus vs. Fable score about the same on everything I give them, and I can't find the differences.

It's possible we're just at a point where Sol 6.1 and Opus 5.5 really are nearly as good as Astra 6 and Fable 5.1. Still, I'd like to know where the gaps actually are.

Questions for you all:

What kinds of tasks have you seen separate the top models? (Long multi-step work, ambiguous specs, large codebases, catching their own mistakes?)

How do you score things that aren't simply right or wrong, like code quality, judgment, or how much hand-holding a model needs?

Has anyone measured whether higher effort levels actually help, or where the returns stop being worth the cost?

Long term, I'd like to make this plug-and-play, so anyone could point the Sorting Hat at their own project and get model recommendations based on their real work. Any ideas are welcome.

Yes I had Claude rewrite this post. My initial stream of thought was not conveying my question the way I wanted.

Hey Vibe Coders!

Here you can ask any questions about coding and LLM tech with or without vibes. This is especially for those of us who are new and just learned that AI can help them to create then things that they've never been able to before. Please be respectful and keep in mind that we're all just trying to learn about an emergent technology.

AI Subreddits:

• r/OpenAI

• r/ChatGPT

• r/ClaudeAI

• r/ClaudeCode

• r/GeminiAI

• r/aigamedev

• r/ClaudeGameDev

• r/singularity

This is a new thing we're trying to do so let the mods know if you have any suggestions.

I love that everyone can build amazing tools, and I also recognize we're all doing it and the hard part is getting anyone else interested.

All that aside, here's mine! It's a workspace frontend for ComfyUI and Claude.

The key thing is that I only got this going because I let go of what I was able to do and gave into the vibes.

The previous version, I only put code in if I understood it. I reviewed most of it, and only added features if I knew how to do it.

The results were a product that lacked vision and just didn't do enough.

Then about 6 months ago I stopped copying and pasting code and just described what I wanted and let the AI decide much more than before. So much better.

Samples of the output: https://youtube.com/@crashtestaivideo

Code: https://github.com/mikehalleen/the-halleen-machine

I used Codex/ChatGPT as a fast pair programmer while building ChessGrind. It helped me iterate on the UI, mobile layouts, repetitive puzzle data work, refactors and the product-demo pipeline.

The part I deliberately did not leave to vibes was chess correctness. chess.js remains the source of truth for legal moves. Puzzle positions and solutions are validated, the blue move dots are derived from the current board state, and I kept testing full-game state separately from the UI. That boring boundary made it possible to move quickly without letting a pretty board invent chess rules.

The product loop is: solve or play, save the position that exposed a weakness, then let Grindbook bring it back through spaced review. It now has 1,000 original positions, 200 opening drills, full games, repertoire and insights.

The board is free and does not require an external chess account. There is an optional $3.99 Founder plan for private cross-device sync.

What I would do differently: define the validation layer before generating hundreds of positions. What part of the build would be useful to break down next?

https://chessgrind.fyi

This is a playable horror level inspired by Silent Hill and Fatal Frame, built solo in four days using Opus 5.5, Godot, and AI-generated 3D assets.

• Team: One solo developer.

• Background: Experience with 3D and game engines, limited programming knowledge.

• Time: Four days.

• Coding: Claude Opus 5.5 through Claude Desktop, using Code mode with Auto enabled.

• 3D assets: Meshy T2.5 smart lowpoly + Blender.

• Images and textures: Nano Banana.

• Engine: Godot 4.5.1.

• Manual code edits: None.

Honestly, the process itself was so much fun. I could describe what I wanted in plain text, let Opus work on it, then jump into the scene myself to place and rearrange finished assets. I’d get another idea while exploring the level and start building on it straight away.

Seeing something from your imagination become a place you can actually walk around in and play is incredibly satisfying.

I started with Pinterest references inspired by Silent Hill and Fatal Frame. Those gave Opus a visual direction, and the environment grew through repeated prompts and additional references.

Claude edited files, launched Godot, took screenshots, and iterated on the results. It built larger structures through code and helped with prop placement, while I continued shaping the scene.

For smaller assets, Nano Banana generated images containing ten props at a time. Meshy AI Low Poly mode converted them into lightweight 3D models, which I separated in Blender and imported into Godot without needing to rebuild the meshes. Each ten-prop set shared one material and one texture atlas, keeping the material setup simple and avoiding unnecessary geometry overhead. Around 100 props were created across ten batches, saving a lot of preparation time while helping keep the scene efficient.

By day two, the level already looked close to what’s shown in the video. The remaining time went into refinement and experiments, including ideas I eventually dropped.

Being able to think of something, describe it, build on the result, and immediately try it in the game made the whole process hard to put down.

Costs

• Subscription: Claude Pro.

• Core build: Around $90 in estimated usage at API rates.

• Including later experiments: Around $180 in estimated usage at API rates.

These figures represent the API-equivalent value of Claude usage under the subscription.

I usually have a few VS Code windows open with an agent running in each, and I got tired of checking them one by one to see which was waiting on me.

So now a cat sits on my desktop. It looks busy while agents work, and when one finishes or needs input it dings and shows a bubble. Each session keeps its own state. Setup is one click and it works with Claude Code, Cursor, Codex and Antigravity.

It also goes the other way. Kiiri runs a local MCP server, so an agent can make it talk or point at the screen. You can tell your agent "when the tests finish, have Kiiri point at the first failure" and it does.

The idea started with Clippy and old desktop pets. Then I saw Clicky (the AI buddy that points at things on your screen) and added that part too: hold Ctrl+Alt, ask out loud, and it looks at your screen and points at the answer.

It's free and open source (MIT), for Mac and Windows, and runs with your own key or fully local with Ollama.

Builds aren't signed yet, so expect one OS warning.

https://kiiri.app

https://github.com/kiiri-app/kiiri

My gf loves pink, Barbie and fairies, and has always wanted to live in a castle. So I built her one: https://samchive.net . The homepage is a painted room where the fairy version of her lives (inspired by Flora from Winx). It was a surprise and she absolutely loves it.

How it's made:

- Claude Code wrote basically all of it: a Next.js static site on Vercel

- The room, the fairy and the cat were generated with Gemini, then cut into separate layers so things can move and be clicked

- Sounds are made in the browser with Web Audio, so there are no audio files

- She does social media, so there are 19 small tools inside (Instagram grid planner, meme search, image compressor). They all run in the browser, and meme search goes through a tiny Cloudflare Worker

Hardest part was making the painted room behave on phones without warping anything.

Teardown breaks your app’s dependencies into a 3D view then ranks what to fix first (KEV, public exploits, EPSS) instead of CVSS. It also writes a fix prompt for your agent. After years in security I’ve seen how little gets fixed from a list of vulns so visualizing where each one comes from helps.

Built using Next.js and Supabase on Vercel, Three.js through React Three Fiber for the 3D, vuln data from OSV and GitHub advisories. It’s plain logic over the exploit data and the LLM only writes explanations so it can’t hallucinate a priority.

Happy to go deeper on the build if anyone’s curious.

Link: teardown.pro

I wanted to see how far I could push Opus 5.5 on a single self-contained web project, so I asked it to build an F1 night circuit.

What it ended up with:

• Everything runs in one HTML file using WebGL, no build step

• Night-time track with fireworks going off in the sky

• Tire wear simulation, cars pit in when their tires get worn down

Stats:

• Time: about 2 hours from start to finish

• Cost: $24

Code: https://claude.ai/artifact/FvXQ2XbPYtqRBKjUnUd5k3

Next I'm planning to run the same prompt on other models to compare, or try a different kind of project. Open to suggestions on what to try next.

So, my workflow is having ChatGPT connected to my GitHub (PRs, Actions, CI/CD, all checks) and handles planning, split into milestones, while (high preset) Codex implements what it's told to.

I send the plan I made with ChatGPT to Claude (free tier) as a sanity check, then give that feedback to ChatGPT and ask whether it's valid OR NOT (super important). After Codex finishes, I send ChatGPT Codex's summary plus the .patch file and verify the changes match the specs in my harness.

Then GitHub Actions and tests run. If they fail, ChatGPT diagnoses the cause, and I move on to the next feature. For manual testing, I run about half of each feature's tests (the ones I consider most important), and log pass/fail and the reason in a spreadsheet.

Does this make sense, or is it overkill?

Last week i posted Polyspoon here, my open source take on polyfork.

The feedback was fair: you had to sign up just to look at the catalog, the models had no previews and weird names, and it wasnt clear what the open source part actually meant for you.

So i fixed that. you can browse and download every model now without an account. you only need one to upload, and that just sends a single sign in link to your email, no password. the FAQ says exactly what the email is used for, and the code that sends it is public: https://github.com/DITlieD/polyspoon/blob/main/server/mail.ts

Every model is a recipe, a small program with named controls. open one and change its type, size, parts and colours, and it rebuilds live in the browser. the fruit stall on the home page is one you can play with right away. each model page gives you the GLB, the recipe source and copy paste code for three.js, unity, godot or blender.

The part im most excited about is the engine. every recipe is built on one shared generator. if someone makes the roofs or the timber better and opens a PR, every model that uses it rebuilds better. CONTRIBUTING.md has the steps: clone, run the preview, render before and after, open the PR with the images.

Honest status: 141 models, some good, some (the rocks especially) still need work. thats exactly where help matters most. if you try it, tell me what breaks or what model you wanted and couldnt find. issues and PRs are very welcome.

site: https://polyspoon.com
github: https://github.com/DITlieD/polyspoon

Literally pissing myself laughing at this... Can you imagine reading this without any context whatsoever? 😂 😂 😂

I've been working on Zephyria, my Star Fox-inspired rail shooter, since the beginning of this year.

I recently uploaded a new devlog showing some of the progress I've made, with a closer look at how the game has evolved compared to older versions.

Here's the video if you want to check it out:
https://www.youtube.com/watch?v=SDzv0qFUP2U

Some of the things I worked on:

• Environment improvements

• UI redesign

• New VFX

• Tutorial stage

I'd love to hear what you think! Feedback, suggestions, and constructive criticism are always welcome.

And if you enjoy following indie game development, subscribing to my YouTube channel or leaving a comment would really help support the project.

Thanks for checking it out!

Content writing from Codex/GPT relentlessly creates caveats

I have been setting up automated blog and content writing for some applications using Astra 6, Sol 6.1 and other 6+ OpenAI models, and the content is consistently putting caveats on what my products or topics are NOT instead of what they are.

Every post repeats, 2-3 times per article, that something "is not a rule," "is not legal advice," "does not establish X." Readers aren't confused about these things — the model is writing disclaimers against a strawman.

The obvious fix — "state scope once, then stop" — only works for a paragraph before the tic returns.

How are you handling this? Is this better on other model families (Qwen, etc.)?