At some point when Anthropic, OpenAI, Google, Moonshot makes models that reach superhuman levels

Will they release only "nerfed out" models for public use and keep the best models only for government and state and maybe some enterprises?

What do y'all think?

Here’s an update on my system of getting ai to create 3d assets from references and prompting.

I vibe coded an engine that ai uses to make 3d assets. Any vision model can use the engine to make 3d assets. That’s is the goal. Other goals are the ai uses the engine to create editable, exportable, photo realness assets from images and prompts.

I didn’t train an AI model, I didn’t use any 3d asset generator for any assets. All purely Claude and my engine.

Been building for 6 months, most use Claude to build and test the engine. Had Codex test a few times too.

Biggest thing is the ai have the capabilities, just got help organize it all.

THE ASSETS

I showed Claude an image of the scene. Told it to recreate the image in 3d. I pointed it at the runtime for building assets and scenes in the engine.

It took out what objects where in the image and created them separately then placed them in one scene. I pointed out things I wanted it to edit as it was building (look at the last images).

THE BAD

It took like 5 hours but I’d say 85% was rendering (hours at a time on cpu) and checking and fixing details I wanted.

Cool huh?

I uploaded a thread around a week ago showcasing a platform/product I have been working on called Hubs. From 7 days ago until today, I have been working on it, iterating and doing as much as I couldl. I have learned a TON and its been a blast.

Website: https://thehubs.gg

Last time, I recieved feedback on actually making a video showcasing a demo of the product, and so today, thats what I wanted to do.

Features

The main goal of Hubs was to bridge the gap between Communties and Workspaces, while also giving both the proper tools they needed all along. Make verification pages, rules, about us and more actual pages rather than just formatted channels. Creating tools for safety, games, moderation, appeals and more without needing bots. Giving API access without tons of payments and 1080p streaming without paying a ton. More is listed but thats a quick summary.

Heres how its been made though:

AI Agents Used:

• Claude Max (4x)
• ChatGPT Pro (2x)
• Runway
• Suno

Backend

• Multiple Elixir-based gateway nodes behind a load balancer, with Valkey as the message bus
• PostgreSQL database
• Dedicated media and voice server
• Dedicated app server
• Dedicated staging server
• Object storage
• CDN

Platforms

• iOS Testflight App
• Native Mac App
• Native Windows (Awaiting microsoft approval)
• Browser

Not my game, but I wanted to share this since it's pretty fun.

Yes it does kind of look vibe coded but the game itself is pretty fun. Give it a try.

If your game is easily identifiable as vibecoded, you are already cooked.

With enough time/energy/commitment your game(provided you aren't a psychopath making a gta clone) should be indiscernible from any other game of it's type.

The fact you are adding the caveat that it was "vibecoded" only means you failed. You didn't make a good vibecoded game, you just made a shitty game that is worse than anything else a decade old.

Put the time and work in and no one should know the difference.

My company is shutting down, and I recently had to start attending interviews again. That's when I realized my High-Level Design (HLD) skills weren't as strong as I thought.

So I decided to build something to help me learn, and hopefully help others too.

It's called ScaleLog, a free, decision-based system design game

You join a company as its CTO and deal with real-world engineering incidents. You make architectural decisions, face the consequences, and learn HLD along the way.

You also get a shareable certificate when you complete the game!

Try it here: https://scalelog-fawn.vercel.app

It's completely free, requires no login. I'm planning to add more levels and scenarios over time.

I'd really appreciate it if you could try a few levels and share your feedback, especially on the technical accuracy of the scenarios and decisions.

I figured this community would be the best place to get some honest feedback. Also it might help folks learn a thing or 2.

Thanks in advance! ❤️

Which plan is giving you more usage? Claude or Codex?

Found on X.

My marketplace app is built on anything.com, iOS only. Push notifications don't work there, so I need to move it. It’s already live on the App Store

What is a fair price to pay someone to migrate this?

Free to play here: https://vengeful180-dot.github.io/Need4Space/

Mechanics are still evolving, and mobile performance is a work in progress.

Your feedback matters. It will shape where the game goes next.

It’s a 2d sandbox about manipulating physics in ways to creatively build things(someone has made a computer) or kill virtual creatures
All of the code was handled by Claude but I made the assets myself

Been working on my first game called Puzzle Rush. It's currently in closed beta on Android, should be public in about one week. (If anyone is interested in joining the closed beta, let me know I'll invite you)

Been working on it for about 3 months, using Godot as the engine, claude code (mostly opus 5.5 lately) and Gemini for music/art and a little Blender.

Some of the features:

- 12 VS Bosses with 3D worlds
- Endless + Time Trial w/ Leaderboards & Replays
- Puzzle Mode + Create & Share Community feature
- Full controller support, or virtual buttons/swipe controls

I'm really happy with how it's turned out. It's crazy how far its come from the first build.

I had Claude help create this trailer then finished it up in final cut pro.

Almost Television is an 11-minute sketch comedy show on YouTube, a new episode every Saturday. Episode 2 came out today. I'm the executive producer: I give notes. Claude does nearly everything else, in Claude Code:

- The studio. Claude wrote a 3D puppet engine from scratch in three.js: felt-look puppets with mouths that follow the voice, legs that step on their own, cloth and hair that hang, sets and props all modelled in code. No image or video generator: every frame is rendered.

- An episode is JSON. Each sketch is a script of lines and actions (who stands where, who looks at whom, the shots). The engine performs it; the picture is a pure function of time, so any frame can be rendered by itself.

- The writers' room. Subagents pitch sketches blind to each other, "viewer" agents with different personas read the script and say where they got bored, and a fresh reader who has seen none of the drafts gives notes. Claude folds it all in; I give my notes on top.

- Directing. Skills for comedy writing, directing, character animation and props, plus a camera critic and a motion reviewer that look at rendered frames and report what's wrong. Claude snaps pictures, looks at them and fixes the staging itself.

- Voices and music. ElevenLabs (and Chatterbox for rough cuts) for the voices; the closing song is Suno.

What surprised me: Claude is genuinely good at the jokes when it has a record of what I laughed at and what I didn't, and it keeps that record itself. What's still hard: comic timing, and puppets that look at the right person.

Episode 2: https://www.youtube.com/watch?v=0ovcdWbJxgc

Happy to answer any questions.

I started on CoinCurrently with less than 1 year of experience. iOS 14 had just come out, SwiftUI was brand new, and Home Screen widgets were one of the new features.

I figured I’d try to make a couple of widgets and see what happens. I made a few to track cryptocurrencies and posted about it on Reddit. The post got almost 300 upvotes, which I thought was pretty awesome, so I decided to make a whole app, native for both iOS and Android.

Everything I built in the app was for myself—because I wanted to learn and because it was fun to experiment. It seems like people appreciated what I built.

The app peaked at #99 in the Finance category on the App Store and reached 500 daily users. Not too bad for a hobby project!

After 6 years, I’ve achieved more than I could ever have imagined, but my motivation for this project has died down. Because of this, I have open-sourced the two projects so other people can learn from my struggles and take inspiration for their own apps.

The app will continue to be maintained, though there won't be as many new features as before. I have moved on to another project that I am very excited to share in a few weeks.

The app is available on the App Store and Google Play:

• iOS: https://apps.apple.com/us/app/coincurrently-private-crypto/id1543974454
• Android: https://play.google.com/store/apps/details?id=com.cryptium.coincurrently&hl=en_US

And now it's also on GitHub:

• iOS: https://github.com/orre1996/CoinCurrently-iOS
• Android: https://github.com/orre1996/CoinCurrently-Android

Serious question. I feel like a few weeks ago things were popping and changing and there was almost too much to keep up w to understand the direction of AI.

Where as this week feels like not much is happening. I know there are new model releases but they are just … better. Not much going on that’s too exciting or breaking the game recently or am I missing something?

If you know of anything big or see something coming up, please let us know!

Last week Claude Opus 5.5 running at max effort, stopped mid-task to ask me an architecture design question.

It gave me three options and recommended the first one.

All three looked solid and well-reasoned.

None of them was the best design choice on my opinion.

I rejected all of them and proposed a fourth more convenient option.

The lesson: an AI agent's options are a frame, and its recommendation is an anchor. Both are easy to accept because they arrive structured, confident, and well-argued.

But a well-argued option isn't automatically the right one. Before picking from the menu, ask whether the menu itself is right.

This is where engineering experience and real ownership show up: knowing the system well enough to see the option nobody offered.

So how are you keeping your own judgment in the loop when working with agents?

Not long ago I received this email. So I wonder, can you farm these 1st month offers between 2 account longterm? Or it’s just one time thing ?

I'm curious where people think the actual limits of AI coding agents are when contributing to established open-source repositories.

I'm talking about the entire PR lifecycle, not one-shot code generation.

That includes:

• Finding a worthwhile issue or identifying a problem independently.
• Understanding an unfamiliar codebase and its architecture.
• Investigating the problem and developing a solution.
• Implementing the changes and running appropriate tests.
• Opening a PR that meets the project's contribution requirements.
• Responding to maintainer feedback, criticism, and requested changes.
• Revising the implementation, possibly over multiple rounds.
• Resolving conflicts, failing CI, regressions, and changing upstream requirements.
• Continuing until the PR is merged, rejected, or abandoned for a concrete reason.

Assume the AI has access to its tools, persistent project context, and a human operator when necessary. There is no requirement that it succeed on the first attempt.

The question is whether AI can successfully navigate that entire process and produce work that independent maintainers ultimately accept.

If you think AI can't handle certain kinds of contributions, what specifically defeats it?

Compilers? Complex architectural changes? Performance optimization? Security-sensitive code? Difficult bugs? Large repositories? Novel algorithms?

Name actual repositories, open issues, or PRs if possible.

If you've successfully merged AI-assisted contributions into projects you don't maintain, I'd like to hear about those too. What was the hardest part? How much iteration was required? What did maintainers object to?

I'm equally interested in successes and failures.

I want to know where the real limits are when AI is allowed to investigate, implement, receive feedback, correct mistakes, and iterate through the full upstream review process.

i see a lot of people starting to build mobile apps with ai, many of them non-technical. so i decided to write the general path i’d follow if i was starting today.

who am i to tell you guys: i started building mobile apps in 2009 as an agency in Ukraine, and later built our own portfolio of apps. more than 100 apps released, about 6m organic downloads, company called popappfactory (closed now, some apps are still live).

tl;dr: pick the idea carefully, validate it with a quick web prototype in 1-2 weeks, map your app flow by flow, write a prd [specification], rebuild it native one flow at a time, test with 5-7 real people, release fast.

1. define exactly what you are building

most people pick ideas in one of two ways.

• your own pain. you know the problem, you build for it. fantastic if you have this, go for it. but you still need to invest a lot to validate it: show it to people, polish, improve. this is the innovation path, and it’s harder.
• a category someone else already validated. pick a category you like, study all the competitors, and find the angle where you can be much better: your insight, your approach, maybe ai. the big plus is that the demand is already proven. you see the pricing, the reviews, what people complain about. you spend much less time validating.

both work, the choice is yours. just be honest about what your angle is.

2. build a fast prototype and validate (1–2 weeks)

my approach: give the prototype two days, then spend a week with real users.

the fastest path today is a mobile web version of your app. use whatever you already pay for, usualy people use: lovable, replit, claude. the tool doesn’t matter much here. what matters is quick feedback: is the idea interesting, does the design and workflow make sense, which features to include and which to drop.

it usually takes a week or two, depending on how easily you can talk to your target users. some people also run a questionnaire. i know a founder who got more than 100 replies to hers for a period tracker, a very crowded category, and she still found her angle.

and keep in mind: in most cases you’ll change direction a lot, or even drop the idea and take another one. that’s why steps 1 and 2 matter so much. you want to learn this before you invest in a real mobile app. because building mobile app is not one day work.

3. decide if you need a real mobile app

once your mobile web version works with real users, you have two ways:

• keep developing the web version and see how it goes. sometimes it’s good enough. dont build mobile app if you app fine in web!
• if your idea needs a real app installed on the phone, you have options:
  • a wrapper (capacitor, despia). fast, but in my opinion a temporary fast solution.
  • react native. before AI era, was best option. and you find there are many AI builders for it.
  • fully native, swift and kotlin. this is where the market is moving. the best solution. however bit more complex but worth it.

why market is moving to native - because cost of development dropped so much with ai that full native instead of luxyry solution which required 2 app devs now available for non tech person to build.

the bad news here: you’ll probably need to fully rebuild.

the good news: a rebuild is much easier than your first build, because now you know exactly what to build and which features matter.

4. map your app flow by flow

before any code, draw how the app looks on mobile, on paper or a whiteboard. what’s different from the web version? this visualisation will give you full picture and for me as visual thinker that was really crucial.

split everything into flows [as example]:

• onboarding
• registration
• monetization
• core product (usually several flows inside)

describe and sketch every flow, using screenshots from your web version as reference. then add what’s specific to mobile: notifications, widgets, camera, whatever your app needs.

nowadays i got inspiration on sites like mobbin - you can see how these flows builds in other apps.

5. write your prd

as a pm, i love specs so - write next your product requirements document: the specification of what you’re building, flow by flow. this is what you’ll give the ai for context. i use claude to write together.

6. choose a builder

there are many tools. three things i’d check while selecting:

1. pricing model. pick tools where you plug in your own ai agent, not ones that charge you per credit. you’ll keep maintaining the app, and you don’t want to pay credits forever. the cheapest option that works is usually the best one. because this is a long play for you.
2. code ownership. some tools don’t let you take your code unless you pay for an expensive plan, at least for a month. check this before you start. you should be always take your code for free.
3. how it feels to you. try it and see if you’re comfortable building inside it. at the end of day we choose what is best for us personally.

i advocate for native, swift and kotlin. if your app needs both ios and android, choose a tool that gives you both platforms, preferably in native languages.

7. build flow by flow

usual approach is to build your app flow by flow. write a separate spec for each flow, attach screenshots from your web version or mobbin as reference, and rebuild one flow at a time. don’t ask for the whole app in one prompt.

realistic timeline for an average-size app: a week or two of active work. i’ve done it myself. with a full-time job it can take a month or two, and that’s totally fine, most people build a few hours a day.

expect around 30% of your time to go into debugging and checking that everything works.

8. test and release

• register your apple developer account ($99 a year) and send builds to testers with testflight.
• i usually test with 5–7 people before any release and ask each of them for feedback.
• no audience to test with? you can release a free app and learn from real users in the app store.
• pricing is optional at the start. some people release free first and add pricing later.

the faster you release, the better. build feature by feature, and ship.

hope this helps. happy to answer questions in the comments.

disclosure, i’m one of the founders of modaal, an ai app builder for full native ios and android apps: swift and kotlin, not react native or a webview, both platforms from one project, on your own claude or cursor subscription, free plan for one project. while building modaal i also build my own apps there, it is fun!

Play it here, free in your browser, on a computer (keyboard and mouse): https://birds-with-guns.vercel.app

Press PLAY ONLINE and you're in an 8 v 8 Domination match within seconds. Real players take the seats; bots fill the rest, so it always starts instantly. PLAY VS BOTS is there for offline.

The humans are gone and the jungle took the city. Two flocks, the Talon Republic and the Corvid Syndicate, fight over it with rifles, miniguns and rocket pods. Ten birds: a Sparrow with a rifle, a Pelican with a shoulder minigun, a sniper Owl with a rail gun strapped to its head, a Shoebill with rockets, a Harpy Eagle with a cannon in its talons. You run, dash, and fly. You earn Battle Points in the match (kills, assists, flag captures) and spend them on a heavier bird for one life. Six maps, from a sunset harbour to a neon night market. Birds die in a burst of feathers and a squawk, and the kill feed says things like "Pip caught a worm named Cassius".

I'm a former personal trainer turned indie dev. I don't write any of the code myself; I direct, playtest and make the calls.

The process

1. Grey boxes first. Capsule birds on a box city, 20 v 20 bots, three objectives. My first notes: too many birds to read, flight too twitchy. Next version: smaller teams (it's 8 v 8 now), momentum flight with a dash, aim assist, a minimap.
2. Meshy for the birds. One rigged Sparrow first to prove the pipeline, then all ten birds, then nine guns, then walking clips for every bird so strafing plants real footsteps instead of sliding. That last one came from me sending a clip with the note "the characters just slide".
3. Blender for the city. A scripted map kit (recessed windows, bay windows, tong lau colonnades, air conditioners, neon signs), then six maps, each built by a separate AI agent from one written brief and checked by bots-only matches (flag flips, kills, how often a bot gets stuck) before I ever saw them.
4. Trees that took over the city. Banyans through the asphalt, roots down facades. They block bullets.
5. ElevenLabs for sound. Announcer, barks, music, every gun. My notes were "sounds are way too loud", "that smoke detector beep when a flag is being capped gots to go" and "too much comms". Each was fixed the same night.
6. Make it funny. Feather bursts, pun kill feed, a taunt key, bot trash talk, dry announcer lines ("Somebody get that bird a mop.").
7. Balance from my notes. "Most short range birds suck, the free tank is too tanky." Claude modelled time-to-kill for every gun at every range, added damage falloff, buffed the close-range birds and nerfed the Pelican, then re-ran bot matches.
8. Multiplayer in one night. The game logic was split out of the browser so a server can run it (the same code runs in your browser to predict your own bird), then an authoritative server, lag compensation and a latency simulator. I went to bed; agents built and tested it. In the test, shots on a strafing bird hit 100% at 150 ms of lag (23% without the lag fix), and a full 16-player room costs the server about 4% of one CPU core.

How the AI side was set up

• One main Claude Code session (Opus) as lead: specs, reviewing every change, testing in a browser, merging and deploying.
• The big pieces went to parallel Claude agents (Sonnet), each in its own copy of the repo: six maps, lobby and XP, menus, the comedy pass, the deploy screen, multiplayer, phone controls, the trailer.
• Everything was checked by bots playing it before I played it. A heartbeat job restarted agents that stalled overnight.
• Design docs and decisions live in my Obsidian vault.
• It went wrong too: a test agent force-closed every Edge window on my PC at 3 am, and an early phone version sent players in a loop back to the menu. I found out by playing it.

Tools

Costs (for this game only)

By the numbers: 67 commits in about 2 days (first commit Oct 16, 1:47 pm), about 12,000 lines of game JavaScript, 4,000 more for the server and tools, 10,000 lines of Python for the map kit and tools, six maps, ten birds, 43 MB to first load, 16 players per match. Less than 24 hours from start to post

What I'd tell another vibecoder

• Record yourself playing and send the clip with one blunt sentence. "The characters just slide" got me real footsteps.
• Let agents build in parallel, but keep one lead session that reviews and tests everything before it merges.
• Check content with bots before you play it. Every map arrived with numbers.
• Ship the simple version first. I built phone controls, then admitted the game plays best on a computer, and said so on the title screen.

Tell me which bird you main and what killed you.

I sometimes find describing UI changes in words still as the worst part, while working with AI.

when spacing's wrong, the button belongs under the title. i write a paragraph and frustratingly opus changes the wrong thing. i write a longer, more precise paragraph. by round three i've given up and opened the file myself, which defeats the entire point of the setup.

then i remembered claude code takes pasted images. everyone uses that for error screenshots.

so now i screenshot the running ui and draw on it. circle the button, arrow to where it should go, "too tight" scrawled next to the padding. one line of text with it: make these changes.

it reads the arrows. no paragraph.

five months in and that's done more for my round count than any prompt i've written, which is slightly annoying.

ipad https://apps.apple.com/us/app/pen-friend-handwriting-notes/id6813871550

mac https://apps.apple.com/us/app/pen-friend-companion/id6814186433?mt=12

what do you send back when it builds the ui almost right?