Beyond the Prompt: What People Are Building With Claude—and Where Gaming Communities Fit In

From browser adventures and robot arms to marketing systems and compiler experiments, AI-assisted creation is expanding. The next challenge is turning impressive demonstrations into useful products—and finding people who can help make them better.

A game that records its own trailer. A sales representative coordinating a collection of agents. A lawyer building a physical interface for legal requests. A team of AI coding agents producing a C compiler.

These projects look unrelated at first. Together, they suggest a shift in how people move from intention to implementation. More creators can describe a problem, generate a working experiment, inspect the result, and refine it without personally writing every line of code.

That shift is especially interesting in gaming. Games combine programming, art, sound, storytelling, interaction, and community. They offer immediate feedback: something happens when you press a button, and you can feel whether the result is worth repeating.

But a working demonstration is only the beginning. A compelling game needs readable rules, meaningful decisions, technical reliability, and players who want to return. Communities can supply the outside perspective that an AI coding session often lacks.

20 Insane Things People Built With Claude in 2026

The change is bigger than faster code

Traditional software tools reward people who can translate an idea into the tool’s language. AI assistants make more of that translation conversational. A creator can explain a mechanic, show a screenshot, describe an error, and ask for a smaller or better version.

The value comes from the whole feedback loop: define, build, observe, correct, and repeat. If the creator cannot recognize the difference between an attractive demo and a useful experience, faster generation may simply produce more unfinished work.

Domain knowledge becomes particularly valuable. A coach knows what makes a tactical scenario realistic. A marketer knows which message reflects the actual offer. A hardware expert knows what needs measuring. A game designer knows when a new ability creates an interesting choice rather than more visual noise.

The prompt starts the project. Judgment determines what deserves another iteration.

That is the editorial principle behind this guide—not a quotation from the video.

Twenty builds worth understanding

The original countdown is useful as inspiration. The more durable question is what each project teaches about designing AI-assisted work.

1. A static-ad generator built around a repeatable workflow

The roundup credits Mike Futia with a tool that takes a product photo and brand information and generates many advertising concepts. The transcript distinguishes Claude’s role in building the surrounding application from a separate image model’s role in producing imagery.

The lesson: an AI product can be a workflow around several components. Generating more variations is useful when there is also a way to review accuracy, maintain brand consistency, and learn which ideas work. More ads alone do not establish better conversion.

2. A 3D survival-learning experience

Dilum Sanjaya’s Backcountry 101 is presented as a 3D educational app combining explorable scenes and instructional steps.

The lesson: interaction can make an explanation easier to follow. For consequential subjects such as outdoor survival, subject-matter review remains essential; a persuasive simulation does not validate its instructions. The broader format could suit lower-risk learning tasks such as equipment identification or navigation concepts.

3. A browser mission with automated play and recording

The roundup describes Prasenjit’s Miami-themed browser game, followed by a mission that Claude Code reportedly played and recorded.

The lesson: automated inputs can help reproduce a path through a game. They may support smoke tests and recordings, but completing one route does not prove the controls are enjoyable or that other routes work.

4. An advertising assistant with limits and human review

Tobi’s advertising workflow is described as reading results, recommending changes, and waiting for approval, with defined budget constraints.

The lesson: usefulness does not require unrestricted autonomy. A report with a clear recommendation can save time while leaving consequential spending decisions reviewable. The reported controls should be verified in the actual implementation before relying on them.

5. A low-cost robot leader-arm experiment

The supplied roundup links TaraT’s robot-arm demonstration, involving mechanical parts, encoders, and a corresponding on-screen model.

The lesson: AI-assisted creation can span software, mechanical design, and electronics. Physical prototypes still need calibration, appropriate power and motion limits, and testing by someone able to assess the hardware.

6. A browser tabletop adventure with an AI game master

Meng To’s tabletop-style adventure is presented as combining a visual world, dice, a party, and an AI storyteller.

The lesson: language models can contribute adaptive narration, while deterministic code maintains inventory, turn order, and rules. Keeping those responsibilities separate can prevent a storyteller from accidentally changing the game state. A live model also introduces latency and operating costs.

7. A lawyer’s unconventional interface

Anthropic’s legal-team case study describes Mark Pike building a vintage payphone interface that routes legal requests. The company also describes using Claude to develop workflows for recurring legal work.

The lesson: the creator did not need to become a professional programmer before exploring a useful interface. He did need to troubleshoot and understand the work. This is an organization’s account of its experience, not independent evidence that every legal workflow can be automated reliably.

8. Agent activity visualized as a chip factory

The roundup describes An Xuan’s factory visualization, where coding sessions and tool calls become events in a 3D semiconductor-factory metaphor.

The lesson: game-like visualization can help people inspect complex systems. The metaphor is useful only if users can trace it back to actual events. A beautiful factory should not obscure what failed or which action caused it.

9. A replacement shelf hook designed through code

Wataru Takasato’s shelf-hook account, linked in the supplied material, describes measuring a part, generating an OpenSCAD model, printing, checking fit, and making adjustments.

The lesson: measurements and test pieces matter. The fact that the reported process required physical corrections makes it a more useful model of iteration than an effortless “one prompt” story. A rendered part is not the same as a validated load-bearing component.

10. A marketing production system

In Anthropic’s growth-marketing case study, Austin Lau describes using Claude Code for ad-copy workflows and a Figma plugin. The company reports a reduction in a particular ad-creation task from roughly 30 minutes to 30 seconds.

The lesson: repetitive constraints are good candidates for automation. Character limits and export formatting can be checked mechanically, leaving people to judge the message. The reported time saving is specific to that workflow and is not a promised improvement in campaign performance.

11. A mech-shooter prototype

The roundup credits Meticulai with a mech shooter built using Claude and additional tools for assets and sound.

The lesson: AI may help a small creator assemble a more ambitious prototype. A polished clip still leaves questions about session length, performance, content depth, controls, and support. Those questions determine whether the project is ready for players.

12. A CRM assembled through delegated tasks

Adonias’ CRM demonstration is described as using a lead agent, a foundation-building task, and additional work in parallel.

The lesson: shared structure needs to come before parallel expansion. In a real CRM, visual completeness is only one milestone; permissions, data integrity, imports, and operational behavior also need verification.

13. A television cleanup experiment

The supplied links include Ansub’s television demonstration and the CleanYourTV repository. Reported performance improvements and popularity figures are not independently verified here.

The lesson: a specific everyday irritation can inspire a focused utility. Device modifications are model-specific; readers should understand what is changed and how to recover before applying someone else’s cleanup instructions.

14. A sales representative’s agent routines

Shahboz Ibragimov’s Anthropic case study describes agents preparing lead-related work and bilingual email drafts for review. The current account discusses Claude Managed Agents rather than merely a collection of local prompts.

The lesson: distinct responsibilities, maintained instructions, and reviewable output can be more useful than a vague “run my business” instruction. Reported savings should be understood in the context of the author’s actual workflow.

15. A game with a frame-by-frame trailer workflow

Bayard’s Iron March demonstration reportedly used a controlled game clock and scripted inputs to render trailer frames.

The lesson: deterministic simulation can make capture repeatable and support debugging. A rendered trailer should represent the actual game clearly; generating frames is not the same as proving real-time performance on a player’s device.

16. A 3D-printed bridge comparison

Roberto Nickson’s bridge experiment is presented as comparing AI-generated designs under physical constraints. The roundup supplies estimated load results, which are not reproduced here as certified measurements.

The lesson: real-world testing exposes failures a text response cannot. A single demonstration does not establish a general engineering ranking or validate a structure for practical use.

17. Project Vend: an AI-run shop

Anthropic’s Project Vend phase-two report describes improvements in an experimental AI shopkeeper, alongside continuing weaknesses. The researchers changed models, instructions, and tools, and retained human involvement in purchases.

The lesson: operational success depends on the environment and controls around the agent. Better results in an office experiment do not establish that an autonomous business is robust in every situation. The report is useful precisely because it discusses failures as well as progress.

18. A multiplayer game attributed to 26 agents

Jacob’s multiplayer-heist demonstration is described in the roundup as an overnight build involving 26 agents.

The lesson: the number of agents is an input, not a quality measure. Multiplayer raises questions about state synchronization, reconnects, cheating, latency, and server costs. The relevant test is how the game behaves with real players, not how many workers generated it.

19. Sixteen agents building a C compiler

Nicholas Carlini’s documented Anthropic experiment reports 16 agents producing a Rust-based C compiler over nearly 2,000 Claude Code sessions, with approximately $20,000 in API costs. The report describes a substantial test harness and important limitations.

The lesson: long-running work needs objective feedback and coordination. This was a serious research experiment, not evidence that a beginner needs an agent fleet. Its most transferable idea is to make correctness measurable and failures discoverable.

20. Reverse-engineered multimeter firmware

The EEVblog 121GW firmware repository describes firmware reconstructed in plain C, with build tooling, emulation comparisons, and testing on the meter. The supplied roundup attributes the work to Claude-assisted development and emphasizes a short initial prompting process.

The lesson: reproducing behavior is more meaningful than generating plausible-looking code. Testing reported for one device does not imply validation for every measurement range, calibration condition, or safety requirement. Specialized expertise remains central to interpreting the result.

What these examples have in common

Across games, marketing, hardware, and business systems, the strongest pattern is an observable loop. A creator supplies a concrete problem. The tool produces something inspectable. The creator or a test system finds a mismatch. The next iteration addresses it.

“One prompt” can describe the initial instruction while hiding extensive automated steps, preconfigured tools, dependencies, revisions, and human review. That does not make a demonstration worthless. It makes context essential.

Similarly, “built with Claude” can include third-party models, engines, APIs, asset tools, and human-created components. Understanding those dependencies helps a new builder estimate cost and effort more accurately.

Why gaming is a particularly useful proving ground

Games make cause and effect visible. Input produces movement. A rule creates a consequence. A reward changes behavior. A confusing interface becomes obvious when someone cannot start.

That visibility makes games useful for learning AI-assisted creation. Start with a small loop, such as choosing a response, collecting an item, or solving a short puzzle. Keep the state understandable. Test the interaction before buying assets or building an account system.

For AI-driven narration, distinguish the storyteller from the rules engine. Let software track health and inventory. Give the model a bounded narrative task. If runtime AI is unnecessary, use it during development and ship a game that runs without paid model calls.

Automated play can reveal crashes and broken paths. Human playtests reveal whether someone understands the goal and wants another round. Both forms of feedback matter.

The most interesting gaming communities to explore

The following is an editorial shortlist, selected for distinctive creative cultures and practical relevance rather than membership size. It includes places for players, developers, and tabletop designers. Public pages were checked during this research; that does not establish the activity or quality of every private Discord channel.

itch.io jams: the strongest first stop for finishing something

itch.io hosts jams with themes, deadlines, community areas, and playable submissions. Its live directory includes many different formats, so you can choose a scope that matches your experience rather than attempting a large release.

Why it is interesting: the shared constraint gives strangers a reason to engage with one another’s work. You can learn from how several people interpret the same theme.

For your projects: a one-screen Jobadu scenario game or a PressPlay puzzle fits the scale of a small experiment. Check each event’s eligibility and AI rules before entering; a platform hosting AI-assisted work does not mean every jam accepts it.

Godot: useful when you want an engine and a learning community

Godot’s official community page links both Foundation-maintained spaces and community-run efforts. That distinction is helpful when choosing where to ask questions or find collaborators.

Why it is interesting: engine learning and open-source participation can reinforce each other. A small contribution, reproducible bug report, or well-explained project question can lead to more useful feedback than a generic request to build an entire game.

Best fit: a creator ready to move beyond a browser prototype into a dedicated engine. Ask about one concrete implementation problem and identify your version and what you already tried.

Lexaloffle: a reminder that constraints produce originality

The Lexaloffle BBS includes PICO-8 and Picotron discussions, game cartridges, technical questions, and work in progress. Public pages showed recent projects and discussions during this review.

Why it is interesting: small games make mechanics easy to study. You can see how creators produce personality without large worlds or photorealistic assets.

Important distinction: its 2026 Advent Calendar event explicitly prohibits AI-generated content and had closed enrollment when checked. That is an event-specific rule, not a finding that every Lexaloffle activity has the same policy. Explore the community for learning, and follow the relevant rules before submitting work.

Interactive fiction: perhaps the closest match for Normie

The Interactive Fiction Community Forum brings together authors and players, with sections for authoring, competitions, and discussion of games.

Why it is interesting: choices, consequences, narrative clarity, and reader expectations receive focused attention. Those concerns are directly relevant to a decision-based experience.

For Normie: explore how a short dilemma can open a meaningful branch rather than simply awarding points. For Jobadu, a fictional interview conversation could make consequences visible. The forum’s guidelines permit assistance with writing but ask people not to generate entire forum messages with AI; event rules may impose additional conditions.

Roguelike development: useful for learning systems

r/roguelikedev features recurring progress-sharing and tutorial activity. It is relevant when your questions involve procedural maps, turn systems, enemies, resources, or replayability.

Why it is interesting: development logs expose decisions and tradeoffs. They are a useful counterweight to clips that show only a finished-looking result.

Best use: study how people describe a narrow problem, such as making generated maps navigable or giving enemies readable behavior. Do not assume all games called “roguelikes” share the same design goals.

Incremental games: study progression carefully

r/incremental_games includes game recommendations and a Feedback Friday thread. Its visible announcement requires generative-AI disclosure for game posts.

Why it is interesting: incremental games make the pacing of rewards and upgrades unusually visible. They can teach you how numerical growth relates to player decisions.

For PressPlay or a learning project: study progression without assuming that constant rewards improve the experience. A good learning game should reward understanding rather than pressure people into maintaining a streak.

Speedrunning: learn from players who examine every edge

Speedrun.com’s forums include introductions, general discussion, recording questions, and races. Game-specific communities have their own categories and requirements.

Why it is interesting: speedrunners reveal hidden depth in movement, timing, routes, and rules. They show how players can develop goals far beyond a designer’s initial intention.

For a future tennis or arcade game: consider short, repeatable challenges with clearly defined starts and finishes. A speedrunning community will not form automatically; first create controls and rules that make mastery satisfying.

Mod DB: community as an extension of the game

Mod DB organizes games, mods, files, tutorials, and updates. It is useful for seeing how players and creators sustain interest through additions and transformations.

Why it is interesting: a game can become a platform for other people’s creativity. The product evolves through tools, documentation, and shared knowledge as well as new official content.

Best use: follow one project over time and study how its creators communicate updates and compatibility. Respect the relevant game’s permissions and asset licenses.

BoardGameGeek: test rules before rendering worlds

BoardGameGeek’s creation forums include design discussion, contests, works in progress, and playtester requests.

Why it is interesting: a tabletop prototype can reveal whether a rule creates a worthwhile decision before anyone builds a digital interface.

For Normie: test a small set of dilemmas and a discussion format on paper. For a career game, try scenario cards. If the interaction is unclear without animation, more graphics may not solve the underlying problem.

GameDevNetwork: useful for cross-disciplinary exchange

GameDevNetwork’s public site describes a nonprofit, Discord-based community for learning, sharing work, collaboration, and game jams.

Why it is interesting: a game needs more than code. Exposure to artists, designers, sound specialists, and other developers helps a creator recognize what is missing from an AI-generated prototype.

Best use: bring a small playable build and one focused question. The public description is not a verification of every private channel’s activity or AI policy; review those after joining.

Communities are relationships, not traffic sources

The easiest mistake is to treat a community as a place to deposit a promotional link. A better starting point is to play other people’s work, give concrete feedback, and learn the local expectations.

Before posting, check the rules for promotion, AI-generated material, recruitment, and feedback requests. State how AI was used when required. Do not conceal it to bypass a restriction.

A useful feedback request includes the intended audience, a playable link where permitted, controls, estimated play time, known limitations, and one question. “Did you understand why you lost?” is much easier to answer than “What do you think?”

Write the final community message in your own voice. Personal participation is part of what members are offering one another.

A practical path from inspiration to a community-ready prototype

1. Choose one audience. A casual news reader, a club tennis player, and a game developer need different experiences.
2. Define one loop. State what the player does, what changes, and why they might repeat it.
3. Build the smallest working version. Use placeholders and avoid unnecessary accounts or live AI calls.
4. Test the basics. Start, finish, lose, restart, change screen size, and repeat.
5. Observe a new player. Do not explain the answer before they have a chance to struggle.
6. Fix the largest friction. Change one important thing and compare.
7. Choose a fitting community. Match the mechanic and format to the space’s interests and rules.
8. Ask for specific feedback. Make it quick to play and easy to respond.
9. Report what changed. Close the loop with the people who helped.

What to watch and read next

• The supplied 20-build video roundup: use it for inspiration, then inspect the individual project sources.
• Tabletop adventure segment, around 3:00: relevant to narrative games and AI-assisted storytelling.
• Trailer-generation segment, around 7:37: relevant to reproducible capture and simulation.
• Compiler segment, around 9:31: pair it with the original research report for context.
• Kevin Stratvert’s Claude Artifacts tutorial: a related interface walkthrough for creating and refining interactive work.
• Anthropic’s compiler experiment: useful for understanding tests, coordination, and limitations.
• Project Vend phase two: useful for studying operational failures alongside progress.
• Claude Artifacts guide and Claude Code desktop quickstart: current starting points for the tools.

Build for the moment someone else plays

The projects in this roundup show how many directions AI-assisted creation can take. Their most useful lesson is that a creator can now test more ideas—not that every demonstration is ready to become a business.

The work becomes more valuable when it meets reality: a device behaves as expected, a workflow saves time without introducing unacceptable errors, or a player understands the game and chooses another round.

For a first gaming project, build something focused enough to finish. Find a community whose interests match it. Contribute before asking for attention. Then let actual use guide the next version.

AI can help you generate the experiment. Other people help you discover what the experiment means.