How I AI: Vibe-Coding a Kid-Friendly AI Fortune Teller App for Halloween with GitHub Spark

Kids at Marco Casalaina’s Halloween block party do not care whether an AI fortune teller has elegant prompting or a clean architecture. They care whether the fortune is funny, weird, and simple enough to repeat back to their parents all night. In this episode of How I AI, Microsoft Core AI VP of Products Marco Casalaina uses GitHub Spark to build a mobile fortune-teller app for the children at his neighborhood Halloween block party.

In previous years, Marco generated fortunes ahead of time with GPT and kept them in a note on his phone under the table next to the glowing crystal ball. This year’s version replaced the static list with a tiny mobile app that generates a new fortune every time a child taps the button.

The interesting part was not the app build itself. GitHub Spark produced a usable interface almost immediately. The harder work was tightening the writing with Marco through short prompts about age range, vocabulary, humor, and concreteness until the fortunes sounded like something a six-year-old would remember.

Turning a Halloween fortune booth into a live AI app

Marco picked GitHub Spark because he had already used it successfully for a simple mobile flash-card app he built for his daughter’s chemistry class. That earlier project convinced him Spark was good at generating lightweight mobile interfaces quickly. The Halloween version was even simpler: one button, one generated fortune, and a design that felt mystical enough to fit a neighborhood fortune teller table covered in props and glowing lights.

Start with the smallest possible interaction

Instead of writing a long product specification, Marco started with a plain description of the core interaction and trusted the tool to fill in the rest:

make a mobile app, which when I click a button generates a new fortune. In the context of a fortune teller.

Spark immediately began drafting a PRD, then generated the HTML and CSS for the interface in public view as I watched the build happen live. That visible generation process mattered because it let Marco inspect each layer as it appeared instead of waiting for a fully packaged result. Within minutes, Spark had assembled a polished mobile screen with a dark mystical theme and a fortune-generation flow that already worked end to end.

Test the writing against the actual audience

The first version looked surprisingly good. It had atmospheric styling, a crystal-ball aesthetic, and a clear "Tap to reveal your fortune" control. But the visual polish was not the real test. Marco’s audience is a stream of neighborhood kids, including toddlers who can barely read and older kids who mostly want something silly enough to laugh about with friends.

The first generated fortune sounded impressive in the way AI-generated mystical prose often does:

"In the tapestry of the cosmos, the stars weave a path illuminated by your dreams, trust in their guiding light."

I immediately called out the problem. The sentence fit the cosmic theme, but it was vague, abstract, and overloaded with language a young child would never use. Marco explained that many of the kids who come to his table are only two or three years old. For them, a successful fortune needs to be short, concrete, and easy to picture instantly.

Refine the tone without touching the code

Marco never opened the generated code during refinement. He treated the app like an editorial exercise and adjusted the outputs directly through chat prompts. The software already functioned; the real iteration loop was about judgment and audience fit.

make each fortune only one sentence and make it kid friendly

The next round improved the tone immediately:

"when you sprinkle kindness like fairy dust, the whole world transforms into a playground of magical adventures and shimmering smiles."

The updated version was warmer and more playful, but it still drifted into abstract language and oversized vocabulary. I pushed for funny objects, animals, snacks, playground energy, and small surprises. Marco added constraints incrementally instead of rewriting the whole instruction set. The kid-friendly fortune-teller workflow preserves that narrowing sequence from first draft to memorable output.

Make the fortunes a little more concrete. And maybe a little more humorous. Try not to use such big words.

Keep iterating until the fortunes feel memorable

The final versions landed because they replaced cosmic language with specific visual images a child could actually imagine:

"This week you will find a shiny rock that looks like a slice of pizza and makes everyone giggle"

Another result leaned into the same strategy of concrete absurdity:

"Today a fluffy squirrel will steal your snack, but then share a secret about the best hiding spots in the park."

By the end of the live build, the app was doing exactly what Marco needed for the party. The fortunes were strange enough to feel magical, simple enough for kids to understand, and specific enough that children might spend the rest of the night looking for pizza-shaped rocks or suspicious squirrels in the park. Marco even mentioned that parents sometimes report back later that their kids kept talking about a fortune for days afterward. The coding portion took only a few prompts. The meaningful work was editorial: noticing when the model sounded technically correct but emotionally wrong for the moment.

Use Spec Kit when the project stops being lightweight

Marco drew a sharp distinction between the Halloween app and the kind of systems he builds in his day job. A low-risk toy with one interaction can succeed with lightweight prompting and rapid iteration. For serious product work, he switches to Spec Kit and develops a much fuller specification before implementation.

During the conversation, Marco showed an example involving a user-feedback feature for an AI agent workflow. Instead of jumping directly into implementation, Spec Kit interrogated the requirements and surfaced unanswered product questions that still needed human decisions.

• "How long should the feedback be?"
• "What should happen when the user submits a large amount of feedback?"

Those requirement questions exposed edge cases before code locked in assumptions. Marco demonstrated the process with GitHub Copilot and noted that it also works with Cursor and Claude Code. The Spec Kit workflow shows when to replace lightweight iteration with a fuller requirements pass.

What the live build actually proved

GitHub Spark looked especially effective for tiny apps with immediate human feedback loops. Marco described the interaction in one sentence, received a polished mobile interface quickly, and then spent most of his time refining outputs instead of wrestling with implementation details. Each prompt targeted a visible flaw: too abstract, too wordy, not funny enough, too repetitive.

The same workflow would not hold up for features involving permissions, persistent data, complex business logic, or important edge cases. Marco’s Spec Kit detour showed the opposite discipline: before implementation, force the model to interrogate assumptions and expose unresolved product decisions. The AI can accelerate both phases, but the prompting style changes dramatically depending on the risk level of the project.

What is worth copying here is the tight feedback loop and the willingness to treat AI outputs like draft copy instead of finished work. Spark handled the interface generation easily. The human value came from recognizing that mystical prose was the wrong emotional fit for toddlers at a Halloween table and steering the model toward concrete, memorable images instead. That approach works extremely well for lightweight experiences, games, and party tools where you can test outputs instantly. Human judgment still matters most when the audience is specific, the tone has to land, or the consequences of getting it wrong extend beyond a kid laughing about a squirrel stealing snacks.