What’s the laziest prompt that actually worked for you?

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

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.

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.

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?

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!

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.

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

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.

My interest spawned accidentally after I used the Earhart story as a class subject for some of my older students. After reading about the possibility she could have survived on the island I had a load of questions that couldn't be answered simply, all involved big tables of data and I'm useless at visualising data in my head. And when I could find a site that did what I wanted I decided to make it.

https://positionunknown.com/

The research phase was about 2 months once I opened the can of worms. I needed to find verified data on

* The actual island

* Reconstructed tide times

* Wind and surf

* The Lockheed Electra

* Any survey heights

* Radio 'reports' heard

The plan was to put everything in so you can see what **didn't** happen as opposed to trying to push a narrative.

The key part I discovered was finding a place she could land that would mean she was able to make any of those radio calls because she could not have kept transmitting for days without running an engine, and the propeller needs clearance above the water to do that

That was the main goal. To be able to place her anywhere on the reef and see if those calls could be possible. The other thing we need to explain is **why the plane is not there now**. So the plane would have to be somewhere the tide is **deep enough** at it's highest tide in that week to float her off the reef and into the depths below.

This tool can show you what's not possible, under a couple of different assumptions:

* The empty fuel tanks were sealed and the only source of buoyancy

* The plane was completely sealed and bouyant. If the plane can't float even when when it's perfectly sealed (unlikely) we can determine it most likely can't float in any other situation, amongst other theories.

What it does ( Claude wrote this bit)

* A 3D model of the island you can walk around on your phone. Nikumaroro's reef, lagoon and beach, built from 19 surveyed reef heights and published coordinates, with the 1937 tide running across it. Touch-first: drag, pinch, tap. No app, no login, nothing collected.

* The tide of July 1937, hour by hour. The water level comes from a fitted 1937 tide curve, checked against a published 2006 table and two independent sources. You can scrub through the whole week or press play and watch it rise and fall.

* Put her on the reef. Drop a Lockheed Electra on any spot and see how deep the water gets at her wheels through the week. The model answers in three ways only: could have, can't have, or not enough data. It never says "this is what happened."

* 139 reported radio signals, tested one at a time. Every post-loss radio report in the record, with its time window, gets checked against the water at the plane. If the water was over the limit when a signal was heard, the model says that signal can't have come from a plane parked there.

* A physics engine that rules things out, not in. Tail lift, when the propellers would touch the reef, whether a sealed airframe could float. All of it derived from the aircraft's licence weights and tank drawings, and it stops and says "unresolved" when the inputs run out.

* Fly the route yourself. A separate flight map: pick whose fuel estimate you trust, drag her track, and the radio log judges whether your route fits the record. A route that fits hands its landing time straight to the island.

* Betty's notebook, line by line. A 15-year-old in Florida wrote down a voice she thought was Earhart. Her fragments, both sides of the argument, and a button that tests her timing against the island's water.

* The expedition, now. A dated news card on the front page: a team is on the island as I write this, scanning the exact spot the model marks. The card says only what has been announced and nothing more.

* Every number can say where it came from. Three labels everywhere: verified, derived, illustrative. Guesses are drawn as dashed lines and chips, never as geology.

* Case for / case against on every contested point. Same size, same weight. Settled facts are not given fake doubt and open questions are not given fake answers.

* Built for English learners (B1 to C1) and anyone curious. Plain sentences, the grammar of evidence (must have, might have, can't have), and a tap-to-find-out layer that is still being written.

* One self-contained HTML file per page. The island is a single 2.5 MB file with the fonts and data embedded. The only outside request is three.js from a CDN. Works offline once loaded.

What I found interesting was looking for spots where both radio signals that sounded most credible to me, and bouyancy water depth could happen simultaneously. There are a load of radio signals reported, and a couple of them seem rather plausible. Being able to look for that sweet spot was the main purpose.

THE TOOLS

I used Claude: Opus 5.5 medium, Fable 5.1 for orchestrating.

Coding I used Opus 5, 5.5 medium, high, ultracode, Fable 5.1 and GPT astra

The biggest error I made was getting Opus 5.5 on ultra code to build a replica of the plane. The most important part that the entire model had to be correct around was the distance between the propeller tip and the reef so we could work out when it would be impossible to transmit. Researching was a pain and then ultra code took about 4 days to knock it out. Dimensionally it's got exactly what it needs but could do with some cosmetics, but using that extra thinking wasn't necessary. I had been using a basic island in testing and tried Astra to remodel it on medium which it knocked out in about 27 mins and I realised I could have saved a shit load of time if I'd got it to do the plane as well, and it may have looked a bit better as well. I did that on the plus plan but I was lucky and had 3 resets saved up (since I had such a positive experience with Astra but it's a bit more expense, I upgraded to the 100 plan on GPT and there's no 5 HR limit which is brilliant, and I may get it to redo a couple of things aesthetically).

The big problem now is as there's so much bloody data, it means there's lots of things you need to look at and putting them on both mobile and desktop was tricky and may not even be the best just yet.

I absolutely love puzzles when you have lots of data but it's all over the place and hard to visualise mentally if even with just images, needing to see it interact really helps me. I love that we can now do all this. It's awesome.

I would love to have a hobby project where loads of different mysteries could be presented, with the data like this one and you make up your own mind, play around, test your own hypotheses. It would be cool to do an open source thing, something I'll look at.

Actually that's another whole point. Why are we all going about doing our own thing? Does anyone realise what absolutely awesome massive shit we could build if we got together? Does anyone know of any things going on, and I don't mean hackathons. Like some sort of place where people can bounce proper ideas and even utilise our outside skills, the ones we already have that are being amplified with AI? We could build absolute bohemoths. Humans ALWAYS work far better when we get together. We could build our own flying cars in half the time it took them, I bet. Lmao. Ok maybe not.

But you get my drift. Anyway, thanks for reading, if you did.

It actually built a pretty interesting song analysis, Python script to determine all of the song elements and key moments. If anyone’s interested, I can throw it up on GitHub.

8 days ago I posted in this sub about what I learned vibe coding an iOS app over 10 months. You guys pushed it to 424k views and I said I would share the real numbers when the trials converted.

Here they are.

The post brought 200+ downloads in 4 days. 30 people started free trials. $500 unlocked during the trial period. $325 converted to real paid subscriptions when the trials ended. That is a 65% trial to paid rate which honestly surprised me.

For context the app had made $235 in the entire 10 months before that one post. One week made me more than the entire year combined.

A few things that surprised me. App Store visits from people just browsing went from 3 a day to over 100 on their own. I think the spike pushed it up in the rankings. Half the downloads came from outside the US, 21 countries on day one. And the people who actually swiped through thousands of photos converted. The ones who barely opened it cancelled or did not pay.

Thanks for making that post what it was. This sub genuinely changed the trajectory of this project.

If anyone is curious in the app:

https://apps.apple.com/app/apple-store/id6756098079?pt=128302433&ct=Reddit&mt=8

Adobe recently released the relight feature, tbh it looks cool, the problem is - it's consuming AI credits. As someone who owns a GPU - it seemed ridiculous, so I added this feature to Photon, My free photoshop alternative.

Good Morning r/vibecoding!

I'm Joey, the developer of Miniskyline! The site lets anybody select an area on a selection of planets/bodies and produce a clean, multicolor 3D printable output.

It was coded ENTIRELY with AI, the vast majority of that being on Claude Code.

How did I launch? I launched expecting it to stay small and a hobby project, but here I am four months later. Snapmaker has provided me with money due to winning in the Innovation Fund, and I have over 2000 daily unique users with over 300,000 generations since launching! I expect a few hundred a YEAR, not an hour, but here we are. It started as me rendering users requested tiles and the file being sent. Now users are treated as thick clients and they render the tiles themselves!

How did I get users? Posts on reddit as well as a lucky break when the main long standing site in this niche was taken down. They re-directed to me as their top option and it has picked up ever since. A youtuber, Uncle Jessy, worked with me and made a video that did excellent in the 3D printing space and brought over 20,000 people in just 2 days to the site.

How do I pay for it? The site is hosted via static pages on Cloudflare. I typically have less than $50/month in fees. MY largest cost is AI, which I use 3 20x plans. The donations I receive have largely paid for my development, andthe Snapmaker fund will continue covering expenses for a few more months while I get income to be steadier.

How much time did it take? All of it. Every moment I wasnt at my job, I was working on the site. AI cant just spit out something this complex in one shot. Hundreds of issue reports, hundreds of feature requests and ideas all get handled within a few hours of receipt. It is time consuming, but getting to work with the people using the site has been my favorite part.

What can you do on the site?

- Print anywhere on Earth, the moon, mars, mercury, vesta, ceres and venus!

- Changes literally hundreds of settings to tweak it to your liking

- Full 3D modelling toolkit built in so you dont have to mess around in slicer to change how something looks.

- Full multicolor support for AMS style and toolchanger style printers

- Print to puzzle, keychain and or multi tile splits!

- Over 3500 landmarks have been modelled and added to the site.

- Rigorous testing to ensure there is little to no non manifold geometry in your exports

- Extremely attention to maintaining small file sizes to allow slicers to work with your tiles more easily.

- Commercial rights ship with each bundle. You dont need a commercial license.

- Print a frame with text either as part of the model, or print the frame separate and use mechanical connections to tie it all together!

- A lot, lot more. Over 78 updates since launch. Nearly 60 hours a week working on the site outside of my career, there is a lot to do!

I hope you all enjoy! Let me know if you have any questions on development processes.

nullplayer.fyi

r/nullPlayer

It seems vibecoding's most profitable use case is creating custom workplace tools. Has anyone vibecoded a tool that saves their company massive time or money? If so can you share?

I wanted to know if anyone is doing mobile apps with ai assisted coding.

Web apps - yes lot of vibe code apps are getting deployed with proper testing and debugging.

Would be interesting to see how many of you are actually vibe coding mobile apps - android/ios

And if you’re doing mobile apps, what tools are you using to debug and testing? I recently came across an open source tool “Measure.sh” that seems good for ai assisted debugging but I wanted to understand what others are using.