DEV Community: Jowi A

The G Factor: an AI music talent show running entirely in your browser 🗣️🗣️

Jowi A — Mon, 25 May 2026 06:58:44 +0000

This is a submission for the Gemma 4 Challenge: Write About Gemma 4

the-g-factor.vercel.app

In psychometrics there is a beautiful, slightly controversial idea called the g factor. The short version: across wildly different mental tasks (vocabulary, spatial puzzles, arithmetic, pattern matching) people who do well on one tend to do well on the others, and statisticians can squeeze that shared variance into a single number. One latent "general intelligence" that quietly predicts performance everywhere. 🧠

I built a browser app that makes a the new Gemma 4 2B model write music, and I named it The G Factor on purpose. Not as a cute pun (although it is one, three times over), but because the name is the whole argument I want to make: you do not need a giant model to look generally capable across a diverse range of tasks. You need a small model in the right harness.

The name is the thesis 🎵

The name has 3 meanings which map onto something the app actually does:

The G in Gemma, the model doing all the work, fully on your machine.
The g factor of psychometrics, one capacity stretched across many different tasks.
The "Factor" in X-Factor, because the app is literally a talent show where you judge contestants. 🎤

That middle meaning is the one I keep coming back to. Lay the psychometric idea next to the app and it lines up almost suspiciously well:

Psychometric g factor	The G Factor (the app)
One latent capacity that predicts performance across diverse tasks	One small Gemma model performing across diverse musical tasks
A battery of varied subtests	A bracket of 4 to 8 contestants
The individual subtests	8 musical axes (polyrhythmic, polyphonic, modulated, timbral, harmonic, tempo-shifted, sparse, dense)
The examiner scoring each response	You, judging two contestants head to head
Adapting the test to the test-taker	A session taste memory that learns what you like
"Is it generally capable?"	"A 2B model is enough when the runtime carries the structure"

The interesting question in intelligence research was never "how big is the brain." It was "where does general capability actually come from." That is exactly the question I find myself asking about small language models, so I built a music app to chase it.

So what is it? 🤔

The G Factor is a browser-native live-coding companion for Strudel. There is no server doing the thinking. Gemma 4 runs in your tab on WebGPU, generates Strudel patterns, and you play them out loud!

If you have not met Strudel before (neither have I before this 😅): it is a free, open-source environment for making music by writing code, and it runs entirely in the browser. You type small JavaScript-like snippets such as s("bd hh sd hh") and it loops them back as a beat, rewriting the sound the instant you change the code. It is a web port of the TidalCycles live-coding tradition, and it is a great target for this experiment precisely because the "language" is compact, composable, and instantly audible: you hear a wrong note the moment it plays.

There are two ways in. In the Rehearsal Room you chat with Gemma, a cartoon producer who rewrites the track turn by turn ("add a four-on-the-floor kick", "make the hats busier", "give it some reverb"). In the Talent Show you drop a seed and Gemma fields a bracket of contestants, each told to explore a different musical axis, and you judge them two at a time until one is left standing. Both surfaces feed the same taste memory.

That is the demo. The part worth writing about is why a 2B model can do this at all.

Teaching a model a language it never saw

Here is the catch that makes this a real problem and not a toy: Gemma 4 almost certainly never saw Strudel during training. It is a niche live-coding DSL. So how do you get reliable, playable code out of a small model for a language it does not know? That's the fun part!

You stop asking the model to know things, and you let the runtime carry the structure. Three layers do that, and this is the pattern I think transfers to any small-model-on-an-unfamiliar-domain problem.

Layer 1: static priors

A roughly 600-token system prompt that is the documentation the model never read: Strudel's mini-notation operators, the common method chains, and about 10 canonical idioms. This is not fine-tuning and it is not a vector database. It is a cheat sheet pinned to the front of every request. Cheap, deterministic, and it does most of the work. Pretty simple if you ask me 🤯!

Layer 2: session taste

Every time you like a pattern, the app writes {seed_code, variation_code, transformation_label} into IndexedDB. On the next generation it scores your past likes against the current seed with a character-bigram Jaccard similarity, takes the top 3, and injects them as a labelled "this user has previously liked..." block.

That is the "learns your taste" claim, and it is honest: no weights move, no GPU time, no API call. The model adapts to you the way the psychometric test adapts to the test-taker, by feeding it the right few-shot context at the right moment. Cold start works on priors alone, and the experience just gets warmer the more you use it. And when a contestant wins its bracket, that head-to-head-verified preference is exactly what gets written back into the taste memory.

Layer 3: the parser firewall

A small model will hallucinate broken syntax. So nothing it generates is trusted. Every output is parsed with acorn, validated against a zod schema, and walked for a deny-list of dangerous references before a single note plays. If it fails, the app retries up to 3 times with a hint that says exactly what was wrong ("previous attempt was invalid because: ..."). Invalid code never reaches the UI, and unsafe code (think fetch, eval, localStorage) never reaches the audio engine. 🔒

Priors tell the model the rules. Taste tells it your style. The firewall guarantees the output is real. None of those three layers is the model getting smarter. They are the runtime getting smarter, and that is the point.

Why the smallest model was the right call

The judging rubric asks for intentional model selection, so let me be blunt about it: I picked the smallest model in the family on purpose, and I would defend that choice in a heartbeat.

The app uses Gemma 4 E2B (effective 2B parameters, q4f16 ONNX). It is around 1.5 GB on disk, loads in under two minutes on a mid-range laptop, runs comfortably on WebGPU, and falls back to WASM when WebGPU is missing. After the first download it needs zero network. The whole loop (generate, like, re-generate) runs offline.

Could I have reached for something bigger? Sure. But once the three layers carry the structure, the model's actual job shrinks to something tiny: take a seed plus 3 stylistic exemplars and emit one short JSON object. That is well within a 2B model's reach. Spending 30 billion parameters on a task this constrained would be paying for generality I already built into the harness.

I did wire in an optional cloud path too, Gemma 4 31B via OpenRouter's free tier, for visitors without WebGPU or who want a faster bracket. Same prompts, same firewall, same axis directives. Feel free to run it both ways and watch the small local model hold its own against its much larger sibling!

The bigger picture

I think we are still over-indexed on model size. The instinct, when a small model stumbles, is to reach for a bigger one. But a lot of "the model is not smart enough" is really "the runtime is not doing its share."

Google does a version of this trick at scale: pre-loading, pre-fetching, doing cheap predictive work before you ask so the expensive step feels instant. The same idea applies to small models. A retrieval step, a constrained output schema, a validation firewall, a handful of well-chosen few-shot examples: these are cheap pre-calls that make a 2B model behave like something far larger, and they run on a laptop with no data leaving the machine.

If you take one practical thing from this post, take this: before you upgrade the model, ask what structure you can move out of the weights and into the runtime. Pin the rules. Retrieve the context. Validate the output. A small local model wrapped like that is private, offline-capable, free to run, and genuinely good enough for a surprising amount of real work. Try it on your own niche domain or DSL and I think you will be surprised how far E2B gets you.

Demo

The whole thing is live and runs entirely client-side:

Live demo: https://the-g-factor.vercel.app/

Open it in any WebGPU-capable Chromium browser. The first load pulls the weights into the HTTP cache; after that you can go fully offline and the whole loop still works.

What's next

I had a lot of fun building this, and there were a few more things I wanted to work on: swapping the bigram similarity for small on-device embeddings so the taste memory gets sharper, and leaning harder into the "cheap pre-call" idea, doing predictive generation in the background so the next contestant is ready before you ask for it. The pre-loading vision is where I think small local models get genuinely exciting.

So finally, I did not teach Gemma to write Strudel. I let the runtime teach it, and I let you teach it your taste 😁

JowiAoun / The-G-Factor

This is a submission for the Gemma 4 Challenge: Write About Gemma 4

I built a browser app that makes a 2-billion-parameter model write music, and I named it The G Factor on purpose. Not as a cute pun (although it is one, three times over), but because the name is the whole argument I want to make: you do not need a giant model to look generally capable across a diverse range of tasks. You need a small model in the right harness.

The name is the

…

View on GitHub

From Deadlocks to Green Streaks: Building an AI Greenhouse with Gemini in 36 Hours 🧑‍🌾

Jowi A — Tue, 03 Mar 2026 06:30:30 +0000

This is a submission for the Built with Google Gemini: Writing Challenge

Plante | Devpost

We built Plante, a plant monitor, so you can touch grass inside

devpost.com

What I Built with Google Gemini

The Spark

As university students, my teammates and I noticed a common problem: lots of people want to grow their own fruits and vegetables but simply don't have the time to monitor a garden. We wanted to bridge that gap. We set out to create a system that could teach anyone how to automatically grow their own produce using a simple, accessible Raspberry Pi kit.

The Solution: Plante 🌱

Built over 36 hours at the MLH sponsored uOttaHack 8 with almost a thousand registered students, Plante (French for "plant") is a prize-winning mini automated greenhouse and gamified learning platform. We hooked up temperature, humidity and soil sensors to a Raspberry Pi and an Arduino, allowing the physical greenhouse to automatically open and close its hatch using servos to regulate its environment. We also added a camera to monitor the plant’s health.

To make learning fun, we built a sleek, gamified frontend (which actually won "Best Design" prize!). Users earn XP, maintain "green streaks", and unlock achievements in their personal museum for keeping their plants alive. Users also can visit their friends’ farms and museums, enhancing the social aspect to growing plants!

The Role of Google Gemini

As the software lead, my main focus was integrating AI to make Plante truly intelligent. I used the Google Gemini API to power two core features:

Context-Aware AI Chat: We didn't want a generic botany bot. We passed real-time sensor data from the user's specific farms directly into the prompt context. If a user asks, "Help, my Tomato Farm is critical 😭😭😭", Gemini knows exactly what the humidity and temperature levels are for that farm and provides targeted, actionable advice.
Weekly Pulse Insights: Gemini analyzes the plant's data over the week to generate custom reports and suggestions, helping users learn long-term farming habits. This goes with our goal of continuously teaching the user about their farm.

Demo

You can check out our full hardware and software demo in action right here:

Feel free to register in the Plante app directly, but beware that AI features have been disabled after the hackathon ended.

Here's a demo CodePen of the little farm game where you can see your farms, originally written in TypeScript from scratch 😀. Press G to express yourself!

What I Learned

Technical Skills

Hooking up physical hardware to a web application is NO JOKE 🥶. We had to create a dedicated sensor polling service on the Raspberry Pi which our app’s server talked with because our initial approach of requesting sensor data from the app’s backend would end up causing deadlocks. So more moving parts means exponentially more thought to put into the architecture of a system. We also learned how to wire servos and sensors to an Arduino, route that through a Raspberry Pi, and expose the hardware states to our app via a REST API.

With all the complexities in creating a fully featured software application with hardware and connecting them together, I would still highly recommend taking on a similar kind of challenge to anyone as it was a lot of fun. We took on this with almost no knowledge of hardware, you can do it even better! Nowadays it is extremely accessible to bridge knowledge gaps with multi-modal AI models like Gemini, allowing you to communicate with it without limits. If you would like to learn how to build apps with Google AI Studio, I would recommend following the "Build Apps with Google AI Studio" track. The curriculum follows a clever route to teach and make you get creative on your own.

Google AI Follow

Our goal is to equip developers with the most advanced models to build new applications, helpful tools to write better and faster code, and make it easy to integrate across platforms and devices.

Unexpected Lessons (The Hackathon Pivot)

Our original grand plan included a fully automated water pump. However, deep into the hackathon, we realized our hardware kit simply couldn't draw enough power to run the pump effectively 👎. With the clock ticking down, we had to triage. We completely scrapped the physical pump idea and quickly pivoted to a software solution: we wired the "Water Now" trigger to test sending mobile push notifications to the user instead. It taught us a massive lesson in MVP scoping and adapting on the fly when hardware refuses to cooperate!

What's Next

We want to take Plante even further by designing a better mechanical box to fit larger plants, adding more advanced actuators, and expanding the software features to support community leaderboards. It would be really cool to add a Raspberry Pi AI HAT+ 2 Kit to have the farm deployable on the edge with LLM/LVM capabilities.

Google Gemini Feedback

The Good

We utilized Gemini 2.5 Flash, and its speed and balance of performance were incredible for a fast-paced hackathon. The massive 1 million token context window meant we could pass context (temperature, humidity, light, farms, user info) directly into the prompt without worrying about cutting data. Additionally, our team had little to no experience with hardware. When we were stuck, we took pictures of our hardware and sent it to Google Gemini through the web interface, in text and image. It was of such big help, so much so that our team’s hardware lead went on to create Buildo in his next hackathon, an app that turns hardware ideas into reality by generating an image with Gemini and finding the components needed to turn the idea into reality. His team went on to win MLH’s best use of Gemini API, truly showing the powers of Gemini in hardware! I truly believe Gemini is untapped for hardware, help yourself and take advantage of this. Share in the comments any tracks you recommend 😁.

The Bad

While the context window is huge, we noticed that if we didn't explicitly rein the model in with our system instructions, it occasionally had a tendency to "overengineer" its advice, jumping the gun on complex solutions rather than just answering the user's specific plant question. It required some rigorous prompt engineering and testing to keep the AI strictly within its helpful "Plante Assistant" persona without hallucinating tasks.

The Ugly

Rate limits. The free tier limits for the Gemini API (which dropped recently to around 15 requests per minute for Flash) hit us hard during our rapid, late-night testing phases. We kept running into the dreaded 429 Too Many Requests error right when we were trying to debug the chat feature. We had to quickly pause our UI work to learn and implement exponential backoff logic to keep the app from crashing during our demo prep. This was fair nonetheless as we received our API key with just a few clicks and were able to use it right away 🫡.

JowiAoun / Plante

We built Plante, a plant monitor, so you can touch grass inside

🌱 Plante

🏆 Best Designed Award – uOttaHack 8 2026

A gamified, pixel-art smart plant monitoring system with AI chat, Raspberry Pi sensor integration, and real-time farm management.

Devpost | Demo Video

✨ Features

🎮 Pixel-Art UI – Retro-styled interface using PICO-8 color palette and NES.css
🤖 AI Chat Assistant – Gemini-powered chat with voice synthesis (ElevenLabs)
📊 Live Sensor Data – Real-time temperature, humidity, and soil moisture from Raspberry Pi
📸 Pi Camera Feed – Auto-capturing plant photos with pixel-art filters
🔔 Smart Notifications – In-app and SMS alerts via Twilio
📈 Weekly Pulse – AI-generated weekly insights about your plants
🏆 Gamification – XP, levels, achievements, and leaderboards
🔐 Google Auth – Secure authentication with NextAuth.js

🚀 Quick Start

# Install dependencies
npm install

# Set up environment variables
cp .env.example .env
# Edit .env with your API keys

# Start development server
npm run dev

Open http://localhost:3000

…

View on GitHub