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

I built this app for my wife back in April, and decided to put up in the App Store sometime, I think, around June, if I remember right. I shared it on here several times, showing updates and stuff like that. I just wanna say, after a few months on the App Store, I’ve actually seen to start to see an investment where number 26 in finance now as well. I’ll get a few emails per week asking for enhancements and stuff like that. We’ve been working through those and adding them. This has been so much fun for learning how to actually do something that really started off with my wife. Simple Register! https://simpleregister.app

Hello there again :)

Since last week I added new major mechanics to the game as important as fishing is itself.

Previous weekly updates can be seen on my profile so I do not link 11 different updates here in the post itself.

FREE ALPHA DEMO - DOWNLOAD LINK

What was added since last week:

"Exploration" mechanics requires you to find an small "exploration" icon around certain place (often small islands, but can be something else), come close to it and press action button. After several seconds "Exploration" is done and you get certain item or note or quest progression.

I also added entire new 3D scene called "Cabinet" and it is your place where you are actually keeping different collections including another new items "Island Diorama" which is self explanatory and gives you a mini version of island that you've been to and "Ship in the bottle" which took bunch of work especially on the visual side of things to make it look in the style of the game yet interesting enough for people to collect. "Ship in the bottle" has also a story attached to the ship you collected be that a real historical ship or some mythical one or ship from the game itself.

I'm very happy with how bottle and ships inside them turned out.

I also added achievements which are similar to world of warcraft type of achievements, they give you nothing gameplay wise and I'm not sure if I will change that, those are just another type of "collection" in the game.

Workflow:

Workflow hasn't changed much, I still use Decisions.md file where I mark every decision made by either User or AI and those marked by User take priority over AI ones, help you keep track what is decided by who and user decisions take priority over AI ones in case that decision is still not implemented in the game itself.

I still use multiple sessions with each session being for separate system in the game set on different effort levels depending on how complex the task for that session is. Simple stuff gets simpler session effort, while more complex (like shader) get highest effort levels. Helps with compacting also. I use "manager" session to send messages to all those different sessions since it is easier that way.

I use: Opus 5.5 for everything basically. OpenAI API for image generation, ElevenLabs for SFX effects, TripoAI for more complex 3D models and Blender MCP for simpler models with Opus 5.5 creating them.

How I made ship in the bottle:

Ship in the bottle in the beginning is a special rarity ship in this game that will only be one, so I wanted it to be a bit more "cool" than other ships, I decided on it to shoot from cannon balls, but for that it required to make and rig cannons. I created ship using TripoAI and then changed some mesh to fix it a little bit. Added cannons made small simple boxes that close as cannon shoots and pulls back into the ship for reloading. Asked Opus to generate shooting particle effects with 5 key frames that it will try to use as goal. Then asked for bunch of other small details (cannon balls falling leaving bubbles as it falls in water etc...).

Sails were done separately with polls being made by Opus 5.5 and Sail textures being done by OpenAI image generation, then used those textures for sails and combined them with the rest of the ship.

Cost of the project so far:

Claude Max x3 = 600$
Codex x1 = 100$
StableAudio= 15$
ElevenLabs = 10$
TripoAI= 40$
OpenAI credits = 50$
Maybe some other stuff I forgot = 30-50$

Total around 850-900$

Any feedback is appreciated ☺️

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

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

github: https://github.com/jimmy-jose/scalelog

It's completely free, requires no login, and is open source. 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! ❤️

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.

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.

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.

nullplayer.fyi

r/nullPlayer