DEV Community: JUKUN MAN WITH SME POWER

[Boost]

JUKUN MAN WITH SME POWER — Mon, 05 Oct 2026 05:15:14 +0000

JUKUN MAN WITH SME POWER

Oct 5

TeachBack: You don't know it, until you can teach it back!

#devchallenge #weekendchallenge #hf26challenge

4 min read

TeachBack: You don't know it, until you can teach it back!

JUKUN MAN WITH SME POWER — Mon, 05 Oct 2026 05:14:51 +0000

Built for a friend learning Python after exhausting shifts at an electricity distribution company.

The Friend & The Friction

My buddy works a grueling 9 to 5 at a local electricity distribution company. He's been trying to break into Python, but he's trapped in the classic "tutorial hell": endless YouTube playlists, passive video watching, and synthetic projects like "build a calculator" that have zero relevance to his actual life.

We kept promising each other we'd jump on Discord for study sessions, but life kept getting in the way. By the time he finishes dealing with feeder voltages, blackout reports, and transformer glitches, he's drained and barely has the energy to look at a keyboard, let alone schedule a live call. Our working hours almost never aligned. I realized he needed something he could run entirely on his own schedule: a self paced learning tool that could act as a live study partner without needing me (or anyone else) on the other end of a call.

The Spark & The Idea

Around the same time, I applied to teach for Stanford's Code in Place. As part of the application, they had me teach a simulated classroom of three virtual students who watched my screen, listened, and asked sharp questions.

It clicked: the fastest way to figure out if you actually understand something isn't reading about it, it's explaining it to someone else.

Most platforms follow a rigid pipeline:
Theory
⬇️
Practice
⬇️
Workshop.
But passive comprehension is a trap; you think you get it until you try to say it out loud. I wanted to add the crucial missing fourth step: "Teach."

What I Built

TeachBack is a lightweight learning platform you use in the browser, run from a small local server on your own computer. It's tailored to my friend's reality:

8 tailored lessons using data from his world: meter readings, line loads, and outage priorities.

In-browser Python, so there's no Python installation to wrestle with after an 8-hour shift.
The "Teach" phase: instead of a quiz, he explains the code to three distinct AI students:
- Maya: the curious one who always asks why.
- Kofi: the edge-case guy who asks what breaks when inputs go sideways.
- Zee: the beginner who needs everything in plain, simple words.
An objective examiner: a second AI agent that reads what he says (as text) and checks whether he explained each core idea in his own words. If it can't point to words he actually said, the explanation is rejected.
The Capstone: his final project is to design his own certificate in Python. Once he builds it and teaches the code back, the app shows the certificate he made.

AliFikan94 / hacktober26

🎓 TeachBack

Honest status (hackathon submission). TeachBack's lessons, in-browser Python runner, capstone, certificate, model picker, privacy panel and the Teach logic (students, examiner, voice loop) are implemented and covered by automated tests and browser tests against simulated model servers. On the author's low-memory PC (about 2.5 GB free RAM) the Teach conversation was not verified end to end with a real local Gemma before the deadline, and its cause was not pinned down. The in-app Test the students and Test the microphone buttons (model menu, top right) and npm run doctor exist to diagnose exactly that. It has not been tested by the friend it was built for.

Theory → Practice → Workshop → Teach. A learn-and-teach platform built for a friend who works 9–5 at an electricity distribution company, wants to learn Python, and is too tired to type after work.

Each lesson has four phases: 📖 Theory…

View on GitHub

Repository: github.com/AliFikan94/hacktober26

How I Built It

Open-source AI and tools

Open-weight models through Ollama running locally. My target was Gemma 3 (I pulled gemma3:4b and gemma3:1b), reached through Ollama's OpenAI-compatible endpoint.
Mastra for the agents: four of them (Maya, Kofi, Zee and the examiner), each with its own instructions. A simple rule picks which student speaks, based on what the learner just said.
Pyodide (Python compiled to WebAssembly) so Python runs inside the page.
A small TypeScript/Node server streams each student's reply to the browser as soon as it's ready. The browser's built-in speech tools handle voice.

How the examiner stays honest: it must quote the learner's own words as evidence, and the server rejects any quote that isn't really in what they said. If a small model can't answer in the required format, a labelled keyword check takes over.

Built with AI assistance: I built this with an AI coding assistant (Claude Code), working under my direction.

The Honest Part: What Didn't Work

I'm submitting this with complete honesty about its rough edges:

Hardware constraints: A 4B Gemma model needs around 4 GB of free RAM, but my test PC only had about 2.5 GB. I built an automatic memory check that steps down to a smaller model, or to a cloud model (and says so), when hardware is tight.
Small model formatting: Tiny local models love to answer in paragraphs instead of structured JSON. Hence the fallback keyword check.
Voice fragility: Browser speech recognition behaves differently across platforms. I added microphone diagnostics with plain-English error messages.
End-to-end testing: The Teach system passes automated tests against simulated models, but I couldn't get the full local conversation working on my low-spec machine before the deadline. My friend also hasn't done a full run-through yet, so I don't have a quote from him... yet!

What I Learned

Building an AI tool for a real person with a real job and real hardware limits is humbling. The hard part wasn't writing prompts, it was making open-source AI light enough to run on an everyday laptop. Next: a lightweight hosted option for low-spec hardware, and getting my friend into a live session to test his outage-priority scripts.

Why Does Open Innovation Matter?

For a tired adult learner who is learning in the evenings, open models matter in three ways:

Privacy: his half-baked logic and "dumb questions" can stay on his own machine. (Browser voice recognition in Chrome and Edge sends audio to external servers, so the app tells you plainly that typing is the fully private option.)
Cost: a local model costs nothing to run every evening.
Control: I can tune the students' personalities and the examiner's rules by editing prompts, which gives me far more control than a closed, rigid chatbot. I could also swap the model with one setting, which is exactly what let me adapt when my PC couldn't run the first one.

Prize Categories

Best Use of Mastra: four Mastra agents drive the students and the examiner.

(Gemma was my target model, but I couldn't show it running end to end, so I'm not entering that category.)

GM GM devs

JUKUN MAN WITH SME POWER — Thu, 30 Jul 2026 10:43:05 +0000

GM GM guys, what are you buidling???

JUKUN MAN WITH SME POWER — Tue, 14 Jul 2026 18:56:48 +0000

https://dev.to/thisisfeekey/tyson-knockout-audio-for-solo-creators-without-the-300-hardware-weekend-challenge-5dj8

JUKUN MAN WITH SME POWER — Mon, 13 Jul 2026 05:49:28 +0000

JUKUN MAN WITH SME POWER

Jul 13

🥊 Tyson: Knockout Audio for Solo Creators (Without the $300 Hardware) | Weekend Challenge

3 min read

My Debut #weekendchallenge

JUKUN MAN WITH SME POWER — Mon, 13 Jul 2026 05:48:06 +0000

JUKUN MAN WITH SME POWER

Jul 13

🥊 Tyson: Knockout Audio for Solo Creators (Without the $300 Hardware) | Weekend Challenge

3 min read

🥊 Tyson: Knockout Audio for Solo Creators (Without the $300 Hardware) | Weekend Challenge

JUKUN MAN WITH SME POWER — Mon, 13 Jul 2026 05:38:01 +0000

🥊 Tyson - The Wireless Phone Mic App That Packs a Punch

This is a submission for the Weekend Challenge!

🎙️ What I Built
Let’s be honest: solo content creators are tired of holding their secondary phones awkwardly like makeshift reporter mics or spending $300+ on bulky wireless lavalier setups that require dongles, cases, and endless charging cables.

Enter Tyson (a.k.a. Tai Sun). It's a cross-platform Flutter app designed to turn the smartphone you already own into a dedicated, heavy-hitting wireless microphone system.

By separating the workflow into a dual-device ecosystem, Tyson lets you use one phone as the sharp Camera/Director angle and a second phone as the high-fidelity Mic, delivering studio-quality sound directly from your pocket.

⚡ Key Features (The Heavy Hitters)
Dual-Device Ecosystem: Dedicated Mic Mode (with absolute UI lock to prevent accidental palm-touches) and Camera Mode layout.

Smart Environmental Presets: Instant switching between Indoor and Outdoor profiles. Outdoor mode activates automatic noise gating and suppression to fight ambient chaos (like traffic or wind noise).

Custom Voice Profiles: Tailor your sound signature on the fly with Clean, Voice, Podcast, and Warm DSP configurations.

Seamless QR & Room Code Pairing: Zero-friction device discovery, laying the groundwork for automatic local Hotspot/WebSocket connectivity.

Simulated "Stop & Mux" Flow: Hits the absolute biggest pain point in filmmaking. Once you hit stop, the mic phone automatically simulates background file transfer to the camera phone for instant track alignment.

💡 Inspiration
I was watching creators shoot content and noticed a painful pattern: people either sounded like they were recording inside a tin can, or they looked ridiculous shouting into a phone held two inches from their mouth. Flagsip phones have insane microphone hardware built right into them, yet no one was utilizing it as a standalone, smart wireless receiver.

I decided to build an underdog app that bites the noise right out of your audio—hence the name Tyson.

The Climax: Hitting Stop 🛑 and watching the app automatically package and transfer the audio file to the Director phone.

Live Demo: Want to take it for a spin? The Android APK is built and ready in the repository releases.

🛠️ How I Built It
Tyson was built entirely from scratch over the weekend using a nimble, high-performance stack:

Framework: Flutter (Dart) – Compiled down to native ARM code to keep audio buffer latency tight and UI fluid across iOS and Android.

Audio Capture: The record package, heavily modified with custom system presets for noise suppression and hardware gain control.

Playback Engine: audioplayers for crisp local audio verification.

Pairing UI: qr_flutter for instant cross-device handshake generation.

🏗️ Core Architecture
MIC Transmitter Mode: Background-priority capture state optimized to save battery and reduce thermal throttling while processing real-time audio.

CAMERA Receiver Mode: A dedicated placeholder interface designed to display received audio metadata and eventual video preview syncing.

🥊 Challenges & Knockouts
The Camera Plugin Brawl: The native Flutter camera plugin decided to throw a temper tantrum on my environment configuration during the crunch window. Instead of getting stuck in dependency hell, I pivoted like a pro—focusing 100% of my energy on perfecting the core audio processing, DSP presets, and wireless transfer UX.

Taming the Noise: Getting standard mobile audio APIs to reliably separate background hiss from real human voice without heavy delay took some intense fine-tuning.

🧠 What I Learned
How to handle low-level device audio streams and apply real-time operating system filters without killing the device's battery.

Designing state architecture that cleanly handles simulated network data flows so the code is structurally ready for live WebSockets/UDP streaming next.

Huge thanks to the organizers for putting together this weekend challenge! Time to go refresh the GitHub repo and get back to building. 🥊

GitHub Repository: github.com/AliFikan94/Tyson

weekendchallenge #devchallenge #flutter #mobile #audio