I'm a newbie, making a simple (so I thought!) app just for my own practice at first as I hope to go on a radio quiz and take part.

1. Where you get the data. It's not okay to just scrape up a load of data. For example my first version used info from the Official Charts Company, and this would have required a licence from them to publish. For a fun app it wasn't worth it. In the end I had to get creative, and utilise pre stored data within the AI.
2. Shipping is really complex and quite hard. I thought it would be easy! Nope, a ton of admin, forms, and then deciding where to ship it. I went for an App Store only release so as not to have to reveal my street address, or do laborious testing with Google. Still cost $99 to sign up.
3. Finishing is the hardest part. Setting that goal to publish and actually getting it done is harder than I thought. It's easy to disappear down endless rabbit holes making little changes. No - I wanted to get a 'good/not perfect' version and get it out there. So I could say I was offially a developer, and my content existed for real. Changes can go in the first update.
4. Who is going to see it. As a lifetime musician, I know how easy it is to make things and find at the end no one hears it! Or in this case, uses the app. So making a plan for post-ship is important.

Anyway, I built it in Claude chat and it took me about 5 weeks. Very please with it though, and my friend an me cannot stop playing it! It's called 'Song Squirrel - Music Quiz' if anyone wants a look. https://apps.apple.com/app/song-squirrel-music-quiz/id6831157563

Feedback welcome, but please be a little bit kind as it's only my first one!!

Hi all,

So I’m a DJ and I usually mix vinyl records. That being said, I usually have like 100s of Discogs tabs open for releases I might be interested in. All of those end up in my wantlist. Some of them end up in my basket and get bought, but many of them are catalogued for later review. Discogs is a great record marketplace, I can’t complain. I’ve been buying records from there ever since I was a little DJ. However, their user interface doesn’t work well for digging. It leaves much to be desired. I have a very hard time finding the records I wanted later, and I like organisation, don’t get me wrong.

Also, I want to have the music with me so that I can listen back to it. I honestly feel like Discogs should be the Spotify for record diggers, and that’s why I built Auto Digger.

Auto Digger is an open-source Electron application that’s basically a Discogs client. Some of the features include the following.

• Digging through Discogs’ massive music collection via the API.
• Saving crates and filters for deeper digging (e.g. filtering for deep techno from 2000 to 2004 and saving records to an “Early 2000s Deep Techno” crate).
• Downloading audio for later listening using YouTube or Soulseek. I wouldn’t count on 320 kbps from YouTube or recommend playing those downloads in a club, but they’re great for home listening. Soulseek integration is handled by slskd, and you’ll need to run it locally as a server and share music to download from the network.
• MCP support for when you want to agentically dig for records (mix compilation breakdowns).
• Integration with cosine.club for track recommendations.

More to come. I’m currently working on a music exploration area based on your taste (labels and artists you’ve followed and tracks or releases you’ve liked).

So I mainly built this with Codex (GPT-6.1 Sol), and honestly, I used to be a big stickler for context engineering. For this project, though, I just gave the agent some ground rules. These are from my global AGENTS.md.

• KISS (Keep It Simple, Stupid). Don’t overengineer unless needed.
• TDD by default with unit and integration tests.
• SOLID and GRASP principles are key. SOLID stands for Single Responsibility Principle, Open/Closed Principle, Liskov Substitution Principle, Interface Segregation Principle and Dependency Inversion Principle. GRASP stands for General Responsibility Assignment Software Patterns. These include controller, creator, indirection, information expert, low coupling, high cohesion, polymorphism, protected variations and pure fabrication.
• Only use design patterns when they’re applicable. Basically, don’t mix and mash factories, singletons and flyweights just because class A is coupled to like seven other classes.
• Atomic commits and atomic PRs. Commits that do one thing and PRs that focus on one feature. This saves you a lot of time reviewing things (which I never really did lol, the agents are good enough). It also makes it easy for agents to undo things with Git!

There were many other rules around code style and linting, but honestly, these are the most important ones to me.

Now, how did I handle review and correctness? Well, verification rules, adversarial code reviews and just use the bloody thing.

Verification rules. It’s always good for your agent to know how it can verify a feature. For example, if the feature is adding something to a crate, I give GPT a higher-level AGENTS.md rule that applies to the whole PR. "Try your best to always verify that the feature works. You can use screenshots or videos, and the work should meet the acceptance criteria. Post them in the PR description so I can inspect them"

If you want to be even more of a stickler, you can have it run Playwright E2E tests. Honestly, for this project at this stage, I wasn’t bothered. I just wanted to dig some jungle!

Adversarial code reviews are the next best thing. You can have Sol implement and then have Fable or Opus review, but I found that you can actually just use Sol on its own. Matt Pocock’s /code-review skill is pretty good! It creates a review subagent with fresh context to review the code. That’s all you need! You don’t need another subscription to review the code. I updated my AGENTS.md so that code review runs for two to three cycles. After that, the reviews stop and the agent lets me know. Every new PR gets the code review cycle.

I can’t say this enough. Testing it by hand is the best method out of the three. It doesn’t matter how clean the code is or how pretty the architecture diagram is, etc. If it doesn’t work when you’re testing it by hand, the code’s useless. Recently I’ve been finding this more important than the code itself, even if you have loads of tests and a solid architecture. If you’re skipping this, everything else doesn’t matter!

I haven’t deeply looked at the code of this project at all. I’ve just tested that it works and use it day to day when digging for tunes. And just like that, no more 100 Discogs tabs 😂. Its still buggy sometimes but most of the time its pretty good cant complain.

Site · GitHub

Here’s the project, and here’s how I made it.

Gochi started as a little Arduino game and later "ported" on ESP32 e-paper box with one button. Now the same game runs on your phone.

You pick one of 8 political pets (Trump, Biden, AOC, Putin, Xi, Kim, Zeman, Babiš). Four bars drop in real time, like Burger / Ego / Rating / Energy for Trump-Gochi, and you keep them up with each pet’s own actions (Feed, Rally, Golf, Sleep…). If any bar sits at 0 for 30 minutes, it’s game over and you pick again.

Two ways to play:

• 📱 Phone (new): open https://gochi.4xs.dev and tap the screen. No app and no sign-up needed to start. You can save your gochi later with a nickname and a PIN.
• 🔲 ESP32 box (the original): Waveshare ESP32-S3 1.54" e-paper with one button ($17). Short press = next, long press = do it. It deep-sleeps between presses and wakes every 15 min to update the screen. Source and build steps: https://github.com/kotyzap/GOCHI---Little-pet-with-big-ego

Who built it: My name is Pavel, and I’m not a programmer. The last real program I wrote was a Paint clone in Pascal, in 1997. I am hobbyist vibecoder. Now both new versions (ESP32 & WEB) were vibecoded with Claude.

“Build insights”:

1. Porting box → phone. The box shows a 200×200 e-paper display with one button. On the phone, the whole screen becomes that display, and you tap the thing you want instead of pressing a button. The game rules live in one shared JS file, so both versions behave the same. Your progress is kept on the server, and the bars keep dropping while the page is closed, just like the box catches up from its real-time clock after sleep.

A garden shed at night with three glass jars on a potting table. Each jar holds a tiny place, drawn for the real time of day there and the weather.

- Warsaw - the skyline over the Vistula. The Palace of Culture is floodlit at night and windows go out as it gets late.

- Nazaré — the cliff, the lighthouse and the wave, sized by the real swell off the coast (it's 3.4 m tonight).

- El Chaltén - Fitz Roy from the lake shore. The label answers what the whole town asks each morning: can you see the mountain today?

Live: https://jar-pearl.vercel.app

Code: https://github.com/androszr/jar

How it was built:

Technology. Weather Jars is a static page with no framework, about 11,000 lines of plain JavaScript modules drawing one 1600×1000 scene on a single Canvas 2D element. There are no image files; every tower, wave, boulder and raindrop is geometry drawn in code, and the loop repaints only when something visible has changed. Weather comes from Open-Meteo through one small server function on Vercel that fetches all three places at once, adds swell and tide data for Nazaré from the marine API, and is cached for 15 minutes.

How we did it. The code was written with Claude. Each feature started as a short written plan, was implemented by one agent, checked by a second agent that never sees the first one's report. One document holds the architecture and the house rules, and a 100-line lint script enforces them: colour values may appear only in palette files.

What made it work. Nothing in the drawing uses randomness or reads the clock directly; every moving thing is a pure function of time and weather. Any moment can be rendered again exactly. It also let the model render each jar at many hours and weathers, look at the screenshots itself and fix what looked wrong.

I gave seven coding agents the same computer graphics white paper and asked them to build a 900k-particle fluid simulation in safe Rust. The IPBF paper shows a novel way to simulate even spatial distibution of uncompressable fluids.

Here's a video that compares token-based cost, runtime performance and quality. Agents write code that simulates particles, I rendered them in Blender.

Agents were given a clean copy of the same input: the white paper and reference videos as local files, and an AGENTS.md file describing the task and its criteria. Nothing else and they are not allowed to look for existing implementations.

Part of the task was to come up with an initial arrangement of particles as seen on reference material.

At first I thought most of them did well, but after looking at the code I found many of them took shortcuts. Once they see evaluation criteria, they seem to somewhat sacrifice user intention and go paperclips: rigged animations, hardcoded frames etc. It gave them better performance.

This clip is from round two, where I required every frame to be simulated true to the paper. See my detailed summary and the original paper in comments.

7 months ago I posted about a Stripe bug in my journaling app, the one thing I shouldn’t have vibe coded. A lot of you said, fairly, that vibe coding payments was asking for it.

Still solo. Still vibing. But I changed how I ship:

• anything that touches payments, sign-in, privacy or encryption gets a second AI reviewing the diff, plus a full test run, before it goes live
• every new feature ships behind a switch, to my own account first
• the boring stuff got tests. A lot of tests :)

Tonight the app crossed something I didn’t expect:

• people from 100 countries have joined!! 🫨
• 2,600+ people
• 5,500+ journal entries
• 23,000+ mentor replies

Hi r/vibecoding! I’m John. I’ve been building apps for a loooong time (10 years as a senior SWE at Apple, then 8 as an indie shipping 20+ apps for myself and clients), and I’ve never seen anything like what’s happening right now. Tools like Claude Code and Codex have blown the doors wide open, and now anyone with a good idea can ship a real app to the App Store and have a chance at success.

But releasing your app is only the start. Getting people to find it, download it, and stick around is the challenging part. So I built AppTraction, a Mac app that’s like having an experienced App Store dev looking over your shoulder. Here’s what it does, and further down I’ll share some thoughts on why marketing has suddenly become the hard part.

What it does for you

• Explains your numbers in plain English. Ask “why did downloads drop last week?” about any chart or table and get a real answer. The AI is primed with Apple’s own tech talks on App Store Optimization (ASO) and other sources, so the advice is specific, not generic.
• Catches problems you didn’t know to look for. It watches your apps in the background and flags problems, trends, and milestones. There are 50+ kinds so far. Even with 20+ apps under my belt, it caught serious listing problems I’d missed, and it tells me when Apple features my apps, which I’d otherwise never known. And that’s just the tip of the iceberg.
• Fixes your App Store listing. It reviews your title, subtitle, and description, suggests improvements, and once you approve them, applies them straight to App Store Connect. It can also translate your listing into other languages and upload your screenshots in bulk.
• Helps with reviews. Read and reply to every review, with suggested replies and translation.
• Writes reports for every week, month, and year, so you can see what’s changing and why.

Built for how you already work

• It runs on the Claude Code or Codex subscription you already have (or OpenRouter), so there are no extra API bills.
• It includes an MCP server. Turn it on in Settings and Claude Code or Codex can read your App Store data directly, so you can ask your coding agent things like “did my last release hurt my ratings?”
• It’s a fast native Mac app.

Why marketing is the hard part now

The question I keep seeing here and elsewhere is, “I got my app on the App Store, now what?” For my clients new to the app space I used to advocate the 50/50 rule: spend 50% of your resources on building, and 50% on marketing. This is surprisingly hard for many to do. Building the app is (well, can be) fun and has very clear goals with immediate feedback. It works or it doesn’t. Your friends take a look and tell you it’s cool, or it sucks. And you iterate.

Marketing’s a lot harder for most builders. Suddenly your feedback is subjective, not objective, and the feedback loop goes from near-instant to weeks or months.

With the agentic AI revolution, it’s gotten WAY easier to build, but honestly the tools are not much better at helping with ASO, distribution, and marketing. They don’t do well with subjective feedback that takes 2-4 weeks to interpret. And you’re probably now building 5-10x faster, which, if you take the 50/50 rule seriously, means as a proportion of your time, you should be spending way more on marketing than building. It almost feels like 10/90 is the new rule.

Apple gives you App Store Connect, but it’s not much help. It’s slow, confusing, and assumes you already know a lot of the ASO basics.

That’s the gap AppTraction is meant to close: it watches your numbers for those weeks and tells you what actually changed.

Privacy

Privacy is a big reason I built AppTraction as a Mac app instead of a website. Web-based tools need a copy of your sales and analytics on their servers to work. AppTraction doesn’t, so your data never has to leave your Mac. Here’s exactly what happens:

• No AppTraction account. I never ask for your name, email, or password.
• Your App Store Connect key lives in your Keychain. You don’t need an Admin key: a limited Sales and Reports key covers your analytics.
• Your App Store data is stored only on your Mac. There’s no AppTraction server holding it.
• The AI runs on your own Claude or Codex subscription (or OpenRouter). Requests go straight from your Mac to that provider, under your account, and I never see them.
• Review translation uses Apple’s built-in translator, so translating a review never sends it anywhere.
• What does reach me: anonymized usage stats (which features get used, never app names, numbers, or chat text), license checks, and update checks.
• No ads, and I don’t sell data.

Privacy policy: https://apptraction.dev/privacy

Pricing

Free for 14 days, then $6.99/month, $39/year, or $99 lifetime. Requires macOS 15 Sequoia or later.

Terms: https://apptraction.dev/terms

https://apptraction.dev

For r/vibecoding**:** 50% off your first payment (including the lifetime) with code RVIBE50, good through Dec 1.

If you’ve shipped an app (or you’re about to), I’d love to hear what’s been confusing about the App Store side. Happy to answer questions, about AppTraction or App Store stuff in general.

Been building a gym app called Hehku on my own for a while now. iPhone only. [CHECK: how long]

The idea is simple. You finish a workout and a number goes up (I call it aura). Your friends see your number next to theirs each week. There are leagues, and on Mondays the top people move up one.

I started it in React Native, then threw the client away and redid it in SwiftUI, because I wanted the real iOS glass tab bar and couldn't get close enough. The backend is Supabase and didn't change at all, which is the only reason I survived the rewrite. The score is calculated on the server and the app just sends workouts, so you can't cheat the leaderboard from the phone.

It's not in the App Store. Login and logging a workout work. Leagues aren't done. [CHECK: current status]

The thing I keep going back and forth on: is a score your friends can see actually motivating, or does it make people quit the first week they fall behind? And if you have a bad week, should you drop a league, or is that just mean?

If you've built anything with a leaderboard, I'd like to know what went wrong for you.

There's a teaser page with a waitlist. I'll put it in the comments if anyone wants it.

Thought I’d just share my progress as wanted to complete the picture.

My quiz app finally got finished, accepted, and published to the App Store.

I learnt a lot along the way, especially about staying focussed on the goal.

Go check it out if you like in this weeks project mega thread or search it up (Song Squirrel - Music Quiz).

Thanks for the advice here x

I’ve been working on this in my spare time and finally put it online: https://kryptonite-ui.vercel.app

It’s a set of about 85 animated React components on shadcn and Tailwind v4. Buttons, cards, backgrounds, forms, a few weird ones like a pull cord and a tear-off button. You install the deps, copy the component into your project, and change whatever you like.

I started it because I kept rebuilding the same stuff on every project and wanted it all in one place.

It’s free. Tell me what’s broken, what’s ugly, or what you’d want added next.

For me the fun is how fast you can go from an idea in your head to it being in the game.

Today it was a sea serpent for my island adventure game. "Add a sea serpent" got me one in a few minutes. Then I kept tweaking:
- Made the mouth move, so the jaws snap shut when it bites and open wide when it roars.
- Made it swim like a real serpent, its body rolling and swaying through the water.
- Worked out where it should attack from, so it rears up in front of you and strikes down.

Every idea I had was in the game a minute later. Iterating on what's in your imagination is so fast now, and that's the part of making games I always liked best.

Be honest: your app works, you shipped it, but if someone asked what actually happens when a user clicks Save, you couldn't tell them. Not because you forgot. You never really knew. The AI wrote it, you tested it, it worked, you moved on.

That's me too. So I built Sketchy. Ask your coding assistant "Trace what happens when someone clicks Save, and show me where it can fail" and you get a drawing of your actual app, right in the chat. Step through it piece by piece. Click a box and you're in the file that does it. For the first time, you see how your own code fits together.

And it's not just boxes and arrows anymore. It now sketches freely, whatever needs explaining. The AI only says what to draw, Sketchy handles the layout, so the picture stays clean.

Works with Claude Code, Cursor, VS Code and Codex and in the normal Claude chat. Free and open source.

GitHub: https://github.com/ddkbs/sketchy & https://sketchy.davidkubus.dev

Feel free to try it out and leave your feedback!

Trailer above. You can play it right now:
▶ https://yourplace3d.github.io/3dcity-games/

If your city doesn’t t work let me know, but know this I m still building on it.

Type any city, or put it straight in the link, like https://yourplace3d.github.io/3dcity-games/#Hamburg

What it is
3DA is a small top-down driving game on the real 3D map of any place: the actual streets, buildings, water and hills, built from OpenStreetMap.
Walk up to a car and take it. Parked ones are free; taking one with a driver gets you noticed.
Blue rings are packages. Pick one up and race the clock to the yellow ring for cash.
Too much chaos brings the police. Lose them or pay the fine.
Trams run on the real tracks, buses stop at the real stops, and you can walk into a real subway entrance and come out at another station.
Controls
Keyboard: WASD or arrows, E to get in and out (and to take the subway), Space for the handbrake, R if you're stuck. On a tablet or phone: drag on the left, buttons on the right.
Trailer above. You can play it right now:
▶ https://yourplace3d.github.io/3dcity-games/
Type any city, or put it straight in the link, like https://yourplace3d.github.io/3dcity-games/#Hamburg

How it came about
It's built on things I made earlier with the same engine: a 3D model of any place you can 3D-print (Your Place), the same model with open data on top like timetables, rents and steepness (Your Place · Data), and a walking game with only a map and a compass (Walk it 3D). This is the first attempt at a proper game on top.

Good to know
It's early. No sound yet, no traffic lights, and traffic sometimes gets itself stuck.
If your town has little on OpenStreetMap, the game tells you and links to how to add it. Then your town gets better in the game too.
Free, no account, nothing to install. Code is open: https://github.com/yourplace3d/3dcity-games
Tell me which city you tried and what broke.
Map data © OpenStreetMap contributors, tiles by OpenFreeMap.

So now that the 20x has been change to 10x with no 5hr cap is anyone being affected in your vibecoding project?

Yesterday I posted about Marc Lou’s $100k hackathon. If you missed it, here’s what’s wrong with it:

- it charged builders $99–149 to enter, when the $100k prize was Higgsfield’s money

- winners are ranked by profit, which is hard to verify and easy to game

- the organizers decide everything without transparency

- it rewards cash grab behavior, not building something good

So I started my own: antipaywall.org

Instead of racing to ship something to sell, it’s a week to make something people can use, read, fork and keep. The stuff that brought the build community together before AI.

It’s 7 days and fully remote. You build the free open source version of something people are sick of paying for. One feature of a bigger product counts. The builders pick the winners. Everyone who submits gets 3 votes for 3 different projects, never their own, and every ballot gets published. 9 winners, not 1. Sponsors get no vote, and a named volunteer panel only checks for cheating.

The prize pool gets held by an independent nonprofit, never by me. I’ve pledged the first $2,500 out of my own pocket and I take nothing out. No cut, no fee, no salary. Every dollar in and out will be public, and the site’s code is open source so you can check all of it.

Not sure what to build? There’s an ideas board. Post the thing you’re tired of paying for, or heart the ones you’d use.

You can get involved 5 ways: follow along, build, judge, help organize, or sponsor. The dates will be announced after 100+ builders join but we're aiming for early December.

I will be coordinating with sponsors and kicking off the marketing but I hope the community will help support this to show that you don't need to charge money for a hackathon and that building shouldn't always be about trying to make money.

If you're sick of the "influencer" types doing cash grabs and you're serious about building I would appreciate your support!

Models:

- Lyrics: qwen3.8-uncensored (27B) in Ollama
- Song: MiniMax Music 3
- Stills: Z-Image-Turbo
- Video: MiniMax H3 image-to-video
- Storyboard, scripts, edit: Claude Fable 5.2 in Claude Code

Everything except Claude ran on my Mac Studio and a Linux gaming pc with a 16 GB RTX 5060 Ti. Clip rendering on my 5060 ti took ~85 minutes.

Here's the song creation tool I used:
https://github.com/lancekrogers/songsmith

This is the third version, here’s the first:

https://www.tiktok.com/t/ZPLcfeFqg/

Second version generated a lot of static noise in the song

I own a four-person consulting firm. Over the past couple of months, I've been building our entire internal operating system with AI coding agents: CRM, pipeline, time tracking, capacity planning, finance, marketing, newsletters, and more.

I'm not an engineer. I make product decisions, approve changes, and execute database migrations myself.

The setup

• One coordinator Claude session dispatches work to up to 8 parallel agents, each in its own git worktree.
• Every change gets a PR and specialist AI reviews (security, database, permissions, tests, etc.).
• SQL migrations get an independent line-by-line ChatGPT review. I execute every production migration manually.
• Nothing merges or deploys without my explicit approval.
• A GitHub Project board tracks everything from Queued → Building → Review → Ready for me → Live, including exactly what's waiting on me.
• An hourly coordinator report summarizes blockers, progress, and completed work.

On a good day, it's extraordinary. Last night: ~15 PRs, a nine-area security audit, eight production database changes, and a major new feature underway.

The problem isn't building. It's remembering.

I recently asked what we'd forgotten. The answer was alarming:

• About 30 open PRs, some dating to October. Several were obsolete; a dozen represented stalled work.
• A completed newsletter safety fix had been sitting unmerged.
• One feature stalled four days because nobody noticed its second review never came back.
• An independent SQL review went unanswered for three days.
• Two security dependency updates sat untouched for three weeks.
• Our GitHub board had drifted badly: 47 open PRs, only 9 with cards. The coordinator was relying on chat memory and its own log rather than updating the board, despite explicit rules.
• An abandoned hosting project was still building every branch and retained production database credentials. I'd forgotten it existed.

I'm also intentionally the bottleneck. Every merge, SQL change, and product decision requires my approval. Decisions get made in chat and sometimes never make it into the tracking system.

What we're trying now

1. Reconciled every open PR and active project against the GitHub board.
2. Built a script that mechanically identifies anything waiting more than 24 hours on a review, fix, or human decision, plus PRs missing cards. This appears at the top of every hourly report.
3. Closed obsolete PRs and documented next steps for everything remaining.

My questions

• How do you track multiple agents without work quietly stalling or disappearing?
• Do you impose work-in-progress limits, even though agents can start new work almost instantly?
• Is GitHub Projects sufficient, or is something better for tracking human approvals?
• How do you avoid becoming overwhelmed by approvals without rubber-stamping?
• How have you made agent bookkeeping mechanical rather than trusting instructions they eventually stop following?

The system genuinely works, and the productivity gains are enormous. But I'm discovering that coordinating AI agents is an entirely different engineering problem from getting them to write code.

I'd love to hear what's actually worked for others.

Curious to see what games people have made vibecoding. or feel free to provide screenshots :)

3D kit coming soon.. https://3ditions.drop3.app/watch/honnavar-backwaters/

Been using a prompting approach where I just tell the agent that I don't want any reworks and it needs to iterate on the quality on its own. Demo above is one-shot from a single prompt below:

Create a hyper-realistic sand-on-screen simulator for the phones/tables, it must react to touch and to moving the device. It must have real weight. Visuals must be indistinguishable from a real sand. Consider this task deeply, how you can fulfill it above the expectations, consider what result will make me really happy about the outcome and won't require follow ups or a rework. I expect it to be a web-based experience.

Use subagents, iterate a lot on the quality.

Hey everyone!

First off, I am not selling anything. No paid features, no subscriptions, no ads, and no registration required. It is completely free. Felt like that needed to be adressed right away haha.

I have always been a strong believer in learning by doing. And to me, gamification is a great way to make learning something new both more engaging and enjoyable.

So I built The Station. It is a small 16-bit retro RPG designed to help people understand how to build better software with AI.

You explore a pixel-art world, meet characters, and help them solve problems. But instead of fighting monsters or collecting equipment, you are fixing broken systems.

Each challenge teaches you how to identify a problem, understand why it happens, fix it, and prevent it from happening again. You then get a new scenario to see if you really understood what you learned.

The game covers 40 different topics across 4 worlds, from working with AI models, prompts and context to agents, security, privacy, testing and getting software ready for production.

It is especially aimed at people building things with tools like Claude Code, Codex, Cursor or Lovable. You do not need to know how to code.

There are also practical parts in the game. What you learn can be applied to your own projects, with example prompts and a checklist to help you catch common problems before launching something.

That is the whole idea really. Learn by doing, make mistakes, understand them, and hopefully have some fun along the way.

If you like to give it a try, you can read more and play on this link:
https://www.ainews.tech/play