Building an AI Teleprompter That Listens Instead of Scrolls Using TypeSafe Jev

     Anyone who has ever tried recording a technical presentation or demo video knows the classic teleprompter trap. If you type out a full script and read it off a scrolling screen, your eyes glaze over and you immediately sound like you are reading terms and conditions under duress; if you ditch the script and talk from a few sticky notes on your monitor, you inevitably forget your best technical point until ten minutes after you stop recording. Right as I was thinking about how to fix that for my own recordings, I watched NetworkChuck's video on TypeSafe Jev and checked out the TypeSafe Intelliprompter cookbook. Seeing how fast Jev evaluates natural language clicked immediately: instead of a teleprompter that forces a human to keep up with a scrolling wall of text, you can build a teleprompter that listens to you speak naturally and checks off your outline in real time.

     The core idea behind Intelliprompter is refreshingly simple. You write your presentation as a clean outline of sequential topics, with a handful of bulleted talking points underneath each topic. When you hit start and begin talking in your own words, browser speech recognition captures your live transcript and sends batches of words to TypeSafe Jev (`jev-1.13.0` / `jev-latest`) after every twenty words or a brief three-second pause. Instead of looking for exact keyword matches, Jev scores how thoroughly you covered each remaining talking point in the active topic on a sc
ale from one to five. The moment a point crosses your coverage threshold (defaulting to `2.5`), Intelliprompter lights it up green, locks that point so it never needs to be scored again, and automatically flips the screen to the next topic as soon as you finish the last bullet on the card.

     Turning that concept into a self-hosted app I could run on my homelab and pull up on my phone was a blast. I teamed up with OpenAI Codex across two focused build sessions (the first session for the core FastAPI and Jev scoring engine and a second session for multi-user accounts and container security) to take the prototype all the way to a production Docker container. Working with Codex made it easy to knock out all the little quality-of-life details you only notice when you actually stand in front of a microphone: holding a browser Screen Wake Lock so your phone display never dims mid-sentence, deduplicating unchanged transcripts so pausing to take a sip of coffee never triggers a wasted API call, and packaging the interface as an installable Progressive Web App for Android and desktop Chrome.

     Because I wanted friends and co-presenters to be able to log into my self-hosted instance, share speech outlines, and rehearse with their own API keys, I also built a multi-user account system with strict key isolation. While my admin account can score talks using the server's environment key, every regular user stores their personal TypeSafe Jev token inside SQLite sealed with `AES-256-GCM` using a key wrapped by `PBKDF2-SHA256` derived from their login password (which means even as the server administrator, I cannot decrypt someone else's Jev token at rest). I also had Codex wire up a ninety-percent test coverage gate across both the Python backend and the frontend state machine so changes stay rock solid. If you want to spin up your own instance in Docker, I put together a step-by-step walkthrough on By Design Won't Fix covering how to deploy Intelliprompter with TypeSafe Jev in Docker Compose.

     There is something genuinely magical about propping your phone under a camera, talking through a complex architecture diagram the way you would explain it to a friend over coffee, and watching the green progress bars tick off out of the corner of your eye (without ever losing your place or sounding like a robot). Pairing a small, blazing-fast evaluation model like TypeSafe Jev with an afternoon of focused building in OpenAI Codex turned a frustrating presentation chore into one of my favorite self-hosted tools on the rack; and it makes hitting the record button a whole lot more fun.

Later,
     SteveO

When Your AI Pair Programmer Deletes Its Own Homework

     If you ever want a masterclass in the realities of autonomous coding, give an AI model write access to your repositories and watch what happens when it tries to clean up after itself. Across my homelab, dozens of agents running locally to audit code and triage suggestions across three personal repositories. On paper, it sounds like an engineering paradise where software writes itself. But having automated bots running around the clock does not eliminate friction; it just trades compiler errors for committee management. The illusion of effortless autonomy evaporates the moment your cloud AI pair programmer refactors a critical component, speeds it up, and then casually feeds twelve unit tests into the paper shredder a few hours later.

     That exact sequence played out in my budgeting application. Google Jules took on an automated performance remediation in our pipeline guard, replacing an old check with an impressive three-fold speedup on synthetic benchmarks. My local review agents - Gollum and Mandos audited the logic and wrote four dedicated regression tests to lock in the behavior. Everything passed cleanly. Then Jules initiated an automated re-push on the branch. In a single careless stroke, the cloud bot clobbered the entire optimization and silently deleted twelve unit tests along with it.

     My local review committee - Gollum, Mandos, Frodo, Aragorn, and Peregrin - caught the disaster before it hit production. Instead of building features, I had to spend the afternoon playing referee: manually restoring the lost commit head, force-pushing with lease across GitHub and my self-hosted GitLab mirror, running a third multi-model audit to secure an approval verdict, and tagging a release to make the repository whole again. The cloud bot had essentially solved a difficult calculus problem on the board, set fire to the notebook, and walked out while my local squad taped the ashes back together.

     The rest of the homelab fleet was dealing with its own digital turbulence. Between security scans and maintenance passes, Jules tossed suggestions over the fence at a dizzying pace: patching an SQL injection vulnerability in an Android database query, extracting hardcoded UI strings, and removing dead imports before we cut a fresh mobile release. But coordinating a dozen active bots introduces bottlenecks you never see in a tech keynote. Local agents started colliding over task checkout locks when multiple workers tried updating the same task thread simultaneously. Instead of writing software, I was diagnosing lock contention, adjusting concurrency rules, and leasing review tasks to local models just to stop agents from stepping on each other.

     I don't know, maybe that is what software developers do. I remember the "Build Toilet" trophy that got passed around when I was on Zune. If you broke the build, they put a Toilet Trophy on top of the cabinet in your Cubicle, but when your cloud bot optimizes an algorithm only to delete its own homework hours later, and your local fleet spends the afternoon squabbling over file locks, you have to wonder if people actually do things that dumb. Babysitting automated committees might be the future of programming, but some days it feels an awful lot like running a day care.

Later,
     SteveO

Fifty-Eight Blocked AI Tasks and a Living Room That Refuses to Go Dark

     If you want an honest glimpse into modern automated software engineering, look at what happens on a Saturday morning when your bot fleet hits an invisible tollgate. I logged into my dashboard to check on my AI minions, only to find fifty-eight blocked tasks staring back at me on the kanban board. Everything had ground to a dead stop. A cloud coding assistant had spent the night churning through pull requests; however, the moment my primary reviewer bot tried to audit the diffs, it ran straight into a provider quota wall. Fifty-eight automated code reviews, PR approvals, and dependency checks were frozen in place because one model had burned through its hourly token allowance.

     The culprit was Mandos, my local review bot. He sits in the pipeline reviewing code changes alongside Frodo, Gollum, and Aragorn; but when a cloud model starts spitting out dozens of minor refactors, a high-end review model eats rate limits for breakfast. To free up the pipeline, I stepped in with a quota governor script - leasing Mandos to a medium local model under a twenty-four hour lease. I fired off an immediate wake-up heartbeat, watched the fifty-eight pending tasks start draining cleanly across the board, and made a mental note to throttle concurrency later that night so the committee would stop slamming into provider walls. The future of autonomous coding, it turns out, involves a lot of waiting around in digital traffic.

     You would think stepping away from the keyboard to relax on the couch would offer an escape from rogue automations, but my living room had other plans. I sat down to watch a movie on Netflix, hoping for some quiet downtime; however, my smart home decided our living room needed the lighting scheme of a police interrogation. Every time someone shifted on the sofa or reached across the table for a handful of popcorn, the motion sensors tripped. Instantly, the lights blasted to full brightness, completely ignoring the television playback state. There is nothing quite like having a dramatic movie climax interrupted by stadium spotlights because you reached for a snack.

     It is kind of my fault; let me explain. The cool part, is that as I was on my way out the door, I pulled out my phone and spoke a prompt into the Antigravity remote webapp/page. It described what I wanted, and it knew how to use my Obsidian notebook to find the "production" home assistant instance, find all the automations, and do the stuff. It was just as easy as telling a voice assistant to turn off all the lights. Anyway, all the lights in the house turned off, the driveway light didn't turn on when I walked through the garage door, so I knew the automations were disabled, so I closed the garage door from my watch and rode my bike to find the kids (they were with their mom).

     You see, it was Halloween, so I hastily had AI create a "Dark Mode" switch to turn off all the light-based automations and turn the lights off. We normally do this because nobody comes to our house for Halloween, but we also leave a bowl of candy out near the end of the driveway just in case a straggler comes down our street. In my haste, I decided to trust in AI to get the job done without testing the outcome first (I was running behind, the kids were already trick or treating without me.) It worked to shut down the house before I went out; however, not quite everything came back online when I turned Dark Mode off. The final silver lining, is one more prompt to AI and it seems to have fixed things well enough; I have reviewed the tagged resources (always have an audit trail with AI does stuff) and the house lighting systems all seem to be functioning normally (I.E. I never touch a light switch to control a light.)

     One more lesson for the books; AI always seems impressive on the surface, but autonomous agent swarms that update your smart home while you are running out the door is beyond what actually works today. In practice, modern engineering feels like an endless cycle of building kill switches and babysitting chaperones. If you are not creating solutions to prevent an AI bot army from burning your GitHub actions quota in a few days, you are searching through your audit trail to try and figure out where things went wrong. We have more automated horsepower than ever, but half the job is just keeping the machines from stepping on their own feet.

Later,
     SteveO

Teaching Cloud Agents to Mirror GitLab (When They Only Speak GitHub)

     If you want a humbling lesson in the limits of cloud AI, try convincing an autonomous agent to acknowledge any version control system that isn't blessed by its creator. Over the past couple of days, thirty new suggestions rolled in from Google Jules across my personal repositories. Having an AI throw thirty suggestions at you before you even pour your morning coffee is a strange experience; it feels less like having an elite pair programmer and more like managing an over-eager intern who drank three Red Bulls and started refactoring everything in sight.

     I've actually refined this process a little. See, I just click start on all of them, then rely on my local triage squad of agents to work through the pile. Out of thirty suggestions, they threw thirteen in the trash. Most of those rejected items were classic AI churn; cosmetic whitespace changes, duplicate lint passes, and redundant null checks that did not actually fix anything. But a handful of them genuinely mattered. They caught and patched real path traversal security vulnerabilities, some minor bug fixes, and cut two clean releases before dinner.

     That seems great, until you see the exponential rise in Github Actions usage. So, the small taste of productivity put me into a strange situation; I eat through my entire free quota of Github actions in less than a week. The only real choice that gives me is to pay money or self host the pipeline. I spent the afternoon setting up a self-hosted GitLab pipeline on my homelab for Gas-Logger, complete with automated Gradle test runs, APK builds, and deployment hooks. Since Jules was already churning out code suggestions, I figured: why not point the agent directly at my self-hosted GitLab instance instead of keeping everything chained to GitHub? It took about five minutes of digging through the Jules documentation to realize that was never going to happen; the underlying bot source is fundamentally hardcoded to GitHub OAuth and repository IDs. The cloud agent literally refuses to leave GitHub.

     Because the AI clings to GitHub like a security blanket, I had to build a chaperone. I wrote a Python daemon to run on my homelab server, polling GitHub for merged changes, release tags, and open branches, and mirroring them over to GitLab. Distributed systems immediately reminded me who is boss; the sync script developed an annoying race condition (because of course it did) where tasks marked themselves done before git had actually finished pushing the branch. I had to hunt down the timing bug and rebuild the sync routines across all three repositories so my local CI runners did not try to build phantom commits.

     Everyone online keeps hyping the fantasy of AI agents writing entire applications from scratch while we sip drinks on a beach, but that has not been my reality at all. In practice, you spend half your day babysitting their vendor lock-in, hunting down stupid race conditions in custom mirror daemons, and filtering out forty percent of their output because it is pure noise. Having AI catch a real storage vulnerability is neat, but when tons of automated motion amounts to so much maintenance plumbing, you have to wonder where the busywork ends and the actual value begins. I suppose fixing the plumbing is still my job.

Later,
     SteveO

28 Pull Requests Before Midnight (And Why My Cloud Agents Need a Chaperone)

     There is a specific panic that hits at twenty minutes to midnight, when you casually click a few repository suggestions in Google Jules and realize a cloud agent has opened twenty-eight pull requests against your main branch. Having an AI hunt down security bugs while getting ready for bed sounds great; in reality, every single pull request instantly spun up a production GitHub Actions runner (which will chew through monthly CI minutes faster than anything else I know).

     The fixes themselves were actually solid. Jules tore through three of my personal projects (NL-Nutrition, SuperBudget, and Gas-Logger) like there was no tomorrow. It patched path traversal holes in Gas-Logger across PRs; it closed an SQL injection risk (I think... who knows really) in NL-Nutrition; it locked down CORS origin rules in SuperBudget; and it migrated brittle date parsing to thread-safe DateTimeFormatter calls before expanding unit tests. Part of me was thrilled to see tedious cleanup handled in twenty minutes - the code was cleaner, test suites were fatter, and I only clicked a button and had paperclip agents push the code through a multi-agent (Antigravity, Claude, and Codex) until it was merged to... main?

     The problem is that cloud agents do not pay your cloud bills. When Jules finishes a batch, its instinct is to aim straight for main; meaning my repositories started kicking off full integration suites and Docker builds all at once. Luckily, I built a local chaperone. My homelab server runs a daemon called jules-governor that wakes up every ten minutes, scans GitHub, and quietly re-targets open Jules PRs from main over to develop. That simple switch diverts the flood into lightweight test runs so GitHub Actions does not eat my lunch before breakfast; truly a lifesaver when letting autonomous bots roam free in your repositories.

     This late-night circus capped off an already wild day of agent operations. Earlier that morning, my local homelab fleet was running its own patrol rounds. Across a three-node Proxmox cluster with twenty-one network hosts and ten active virtual machines, local agents like Aragorn, Frodo, and Gollum (yea, LoTR themed agent names :) audited backups and verified services. Meanwhile, my Home Assistant edge setup (which reports device telemetry to an analytics cloud platform for senior care) ran 1,799 unit and integration tests, alongside 73 UI test suites, against a local Home Assistant Green hub and simulated apartment. So, on paper, I have over 90% of the code tested end to end, but does that really mean any of this crap works?

     Even with twenty-one healthy local agents and hundreds of completed Paperclip tasks under my belt, reality still taps you on the shoulder. By afternoon, two code-review tickets (where Mandos audits a worker teardown fix) sat frozen in blocked status; all because I had burned through my weekly Claude quota and had to wait for the counter to reset. I mean, what is the point of having an AI company if it grinds to a halt because of a quota? Building software with autonomous agents feels like magic when dozens of security fixes land in your lap before midnight; however, the uncomfortable truth is that half the engineering job now is building governors, branch routers, and rate-limit safety nets to keep your digital helpers from lighting your compute budget on fire.

     Anyway, this rant doesn't have a real point. Just marveling at the way tons of work amounts to nothing in particular. Its almost like AI never crossed that bridge from busy work to delivering value. I guess that's my job?

Later,
     SteveO

I Vibe Coded a Thing... It Was Fun

     If you read Part 2 of my agentic development series, you already met Sleepy Tom, Baking Martha, and the rest of the Virtual Villa residents (none of whom exist, which makes them very easy neighbors). This one is a quick side trip into how the thing actually got built.

     There is a real adrenaline rush in telling an AI to do something, watching it go do it, and then fiddling around in the UI instead of solving the programming problem myself. Solving those problems is a different kind of challenge, and one I would miss if I couldn't do it regularly; however, for a couple of weeks it was a blast to just let the AI take the reins.

     A lot of this I did by talking to Google Antigravity on my phone. I tried to keep my hands off the keyboard, and I didn't always manage it. I would describe what I was seeing (residents stuck, lights not turning on, the apartment count resetting) and Antigravity would find the cause, fix it, run its tests, commit, and push. Every time it wrote a file, its own tooling reminded it "Don't ask for permission" - and it mostly didn't. It even built the disposable Home Assistant VM on my Proxmox server with Terraform, and later logged into the host itself to snapshot and upgrade it whenever I asked. Near the end, going from my request to a pushed commit usually took 8 to 18 minutes.

     Everything runs on local IP addresses with no domain name, and the test VM rolls back to a snapshot, so breaking things was kind of the point. I think a sandbox like that is essential when you hand an AI the keys. That said, my idea of "isolated" was a little optimistic... the supposedly empty test hub went and found my real TV and Sonos speakers, and a "Mickey Mouse Speaker" from my home setup kept coming back from the dead.

     Every room in Virtual Villa has a fake Inovelli Red Series dimmer with presence sensing. At first they showed up in Home Assistant as generic MQTT devices, even after Antigravity copied my real switch's model and firmware details (straight out of my production Home Assistant, no less). So one morning I just asked whether they could be actual Z-Wave devices. Antigravity explained that Home Assistant labels a device by the integration that created it, and when I said yes, it wrote a mock Z-Wave server. It committed at 10:54, and by 11:11 Home Assistant believed it had 145 Z-Wave devices (144 dimmers across 24 apartments, plus the controller).

     My job was playing product owner, and that started well before the Z-Wave work. I wrote the first three residents myself: Sleepy Tom, Antisocial Jim, and Active Jane (I called him Jack in Part 2; he hasn't complained, because he doesn't talk to anyone). Antigravity filled out the rest of the building with folks like Night Owl Arthur and Wellness Clara. I described their days in plain English: meals take 30 to 60 minutes, bathroom trips 1 to 10, and a trip out anywhere from 10 minutes to 8 hours. Motion turns the lights on just like the real switch, except in the bedroom; nobody wants the light coming on every time Sleepy Tom rolls over.

     I also had it read the sun position from Home Assistant so the light sensors would feel real. In my head the bedroom and living room had big windows, the kitchen borrowed light from the living room, and the bathroom was a cave. Antigravity picked its own numbers (living room 100%, kitchen 70%, bedroom 60%, bathroom 8%)... not quite the apartment I pictured, but close enough for a test harness. Honestly, that was the fun of it: I spent my time picturing apartments instead of writing code, which is a nice break from the nitty gritty backend work I usually live in.

     The whole point was verification. Another project I work on, a Home Assistant app that reports device changes to an analytics cloud platform for senior care, needed proof that when a simulated light turns on, Home Assistant sees it and the cloud hears about it. During development the tests could hit Home Assistant's local API all day long; the cloud is a different story. A QA tool is more of a cost center than a value add, so I budgeted one check per device per minute, and later cut that back to device adds, hub changes, an hourly sweep, and the Re-verify button.

     That 144-device stress test found a real limit, too. When devices went missing in the cloud, Antigravity blamed a container restart until I pushed back. Then it found a hard per-location device cap, so a few days later I cut the building to 16 apartments and 96 devices.

     I really do think this is where software development is headed. With a team of agents, I can do the work of five or six people. I do have to admit something, though... on this one, Antigravity was grading its own homework. It ran its own tests, pushed straight to main, and no second model reviewed anything, which is not quite the picture I painted in Part 2. I did set up a Claude reviewer in Paperclip partway through, but I never pointed Virtual Villa at it; in hindsight, that is exactly what this project was missing.

     The part that worries me is what this does to people early in their careers, which is what Part 3 was all about. If AI becomes a crutch, plenty of developers will ship code like this without knowing if it's any good. I haven't done a deep dive yet, but every task I gave it was focused on one small goal, so I fully expect duplicate logic everywhere (plenty of developers would call it AI garbage, and they might be right). It's fine for a throwaway QA tool - I am nearly positive it is not code I would want running in production.

     Anyway, that's all for now. In a future post I want to dig into the performance and the code to see where the AI cut corners; until then, I'm going to keep tinkering.

Later,
     SteveO

How I created my weekly feed digest

So, if you read the frizzlefry blog, then you probably noticed I had an issue today that was all about my weekly shared Items in Google Reader.  I have been thinking about reorganizing all of my shared feeds into a series of digests.  The nice part, is that other people did all the work for me, so all I need to do is put their work together into a script I can run.

So, where to start?  ok, first I want to parse out an Atom feed, so I chose the Universal Feed Parser which is a nice little utility to parse out RSS/Atom feeds among other stuff I'm not currently interested in.  So, because the library I wanted to use is in Python, I decided that I was going to write a little python script to get the work done... I guess the language of a library is as good a reason as any to choose your language.  '

Anyway, ok, so how does this thing work?  really simple as it turns out...
To start off, I import the feedparser library, and create a feed object:

import feedparser

d = feedparser.parse('http://www.google.com/reader/public/atom/user%2F11424318483849164397%2Fstate%2Fcom.google%2Fbroadcast')


So, that creates a variable d, which is a feed object.  All I want from the feed is the title and description, so I can access those simply by using:


import feedparser

d = feedparser.parse('http://www.google.com/reader/public/atom/user%2F11424318483849164397%2Fstate%2Fcom.google%2Fbroadcast')

d.entries[itemnumber].title
d.entries[itemnumber].description


However, I want to print out those values, which can be done with the print like this:


import feedparser

d = feedparser.parse('http://www.google.com/reader/public/atom/user%2F11424318483849164397%2Fstate%2Fcom.google%2Fbroadcast')

print d.entries[itemnumber].title
print d.entries[itemnumber].description


Next, I want itemnumber to mean something, so I'll put the whole thing together in a for loop that prints all entries like this:


import feedparser

d = feedparser.parse('http://www.google.com/reader/public/atom/user%2F11424318483849164397%2Fstate%2Fcom.google%2Fbroadcast')

for itemnumber in range(0, len(d.entries)):
   print d.entries[itemnumber].title
   print d.entries[itemnumber].description


Now, I wanted to make sure that I limit the list to only include items after a given start date that I could specify as a command line argument, so I added a couple more lines:


import feedparser

startdate = datetime.strptime(sys.argv[1],'%Y-%m-%d').date()
d = feedparser.parse('http://www.google.com/reader/public/atom/user%2F11424318483849164397%2Fstate%2Fcom.google%2Fbroadcast')

for itemnumber in range(0, len(d.entries)):
   print d.entries[itemnumber].title
   print d.entries[itemnumber].description
   if datetime.strptime(d.entries[itemnumber+1].published,'%Y-%m-%dT%H:%M:%SZ').date() < startdate: break

So, I created the startdate variable, which is a date provided by the command line in the format
--, then it breaks the loop if date published is before (less than) startdate. 

Finally, I wanted to add some basic HTML formatting to make it easy for me to copy and paste the text into blogger... that lead me to my final version of the python script, which looks a little like this:


import feedparser
from datetime import date
from datetime import datetime
import sys

print sys.argv[1]
startdate = datetime.strptime(sys.argv[1],'%Y-%m-%d').date()

d = feedparser.parse('http://www.google.com/reader/public/atom/user%2F11424318483849164397%2Fstate%2Fcom.google%2Fbroadcast')
print '<html><head><title>'

print d.feed.title
print '</title></head><body>'

for itemnumber in range(0,len(d.entries)):

print '<h1>'
print d.entries[itemnumber].title
print '</h1>'
print d.entries[itemnumber].description
print '<br /><br />Date Shared: '
print datetime.strptime(d.entries[itemnumber].published,'%Y-%m-%dT%H:%M:%SZ').date()

if datetime.strptime(d.entries[itemnumber+1].published,'%Y-%m-%dT%H:%M:%SZ').date() < startdate: break
print '<hr />'
print '<hr />'
print '<hr />'

print '</body></html>'


So, the first part of my script was done... I named the file GeneratePage.py, and proceeded to create three more files... the second file was SaveDate.py, which would simply output the date in the format I needed it using two lines:

from datetime import date
print date.today()


I figured the best way to track the previous time the script was run would be to save the date to a file, so I created a file called date.txt that contained only the string "2011-02-26".

Then I created a batch script that would tie everything together... the batch script looks like this:

#!/bin/bash
D=`cat date.txt`
python GeneratePage.py $D
python SaveDate.py>date.txt


This script would set the date from date.txt to a variable called D. Then it would run the GeneratePage.py script while passing it the value of D. Then it would run the SaveDate.py script, with the output replacing the contents of date.txt.

At this point, the script could be run every week, and the output can be copied and pasted into blogger.

The next step will be to automate the process of putting the dialog onto the site, which will actually take a little effort, but I'm pretty sure someone else has already done the work for me, I just have to figure out who did it.

Oh, on one other note, in case you are curious why I didn't just redirect all the output to a file, it's because some of the feed items use Unicode characters that cannot be converted to ASCII... so Bash gets angry when you do that.  I might be able to fix this easily, however, I really don't mind having to copy and paste the characters into the blog anyway.

Later,

     SteveO