I don’t fail in open, explicit competition enough. I don’t ask for things and get turned down enough.

Really, I don’t do it much at all, and that’s got to be a mistake because the optimal number of rejections is much, much higher than zero.

So to help me pump those numbers up, I’ve set a numerical target for the year: 250.

Okay, I admit I’m starting small. I’ll up my goal if I over-achieve or go into some profession where rejection is easier to come by, like sales. You can follow along and watch my progress.

If you want your own rejection log, I’ve even made a one click deployable webapp for you.

Go out there and get rejected!

OpenClaw allows you to switch models in the middle of a session. This enables one of my favorite quick and dirty evals, which I call the “brain transplant”: start talking to a frontier model like Sonnet-4.6, switch to a local model like Nemotron 3 Super, and see if you can spot the difference.

When you do this, it turns out local models are both stronger and weaker than you’d expect. But are they strong enough for chat? Specifically, for voice chat?

One example brain transplant shows how they’re strong enough to sound smart, but maybe too weak to follow instructions in the way needed in order to sound more natural.

Many tools and computer systems have an “enrollment protocol”, like FaceID on the iPhone, where you teach the system about your name, your face, your voice, etc..

But we already have such a protocol for people. It’s called manners, or etiquette. You meet someone. You see their face and voice. They tell you their name. Then in the future, when you recognize them by their face and voice, you use their name.

Sparky works that way. All AIs should.

This is a short video showing how this works in Sparky under the hood, from the point of view of the AI. This uses NVIDIA’s TitaNet and Sortformer.

Here’s Sparky, powered by talkie-1930-13b-it — a 13B model trained exclusively on pre-1930 English text (books, newspapers, journals, patents, case law). Old timey data, old timey voice. 🙂

AIs are quite good at working in chat interfaces — that is, in responding to requests in text, on a screen.

But they are not great holding conversations in normal life.

If you connect them to a voice interface, you see they don’t talk in the way which you would expect from a person. Therefore, they are also not talking in the way you would want from a robot which is supposed to be easy to interact with in normal life.

The most obvious problem is that they talk like textbooks, saying too much at once. Also, they do not pick up on normal cues which indicate when a person is pausing as opposed to done talking, nor do they always handle interruptions smoothly. Developers of voice AI sytems are working actively on those problems. Pipecat, for instance, uses a custom end-of-turn model to detect when a human is finished speaking.

But even beyond the problems of voice AI, there are additional problems which appear only when you use an embodied voice AI which is expected to function in the social environment of the physical world. These are the problems of social performance and awareness of the social environment

^1: You might find such topics addressed analytically, rather than as an engineering problem to be solved, in disciplines of linguistics, psychology, and sociology, and theater arts, under topics like conversation analysis, interactional linguistics, discourese analysis, linguistic pragmatics, and voice and body training.

But that’s just one of many, many problems. Some problems are not simply appear immediately, simply when you try to move to voice-based interface. You discover, for instance, right away, as soon as you simply in the contextproblems appear with voice AI, which are pretty well-explored in teh

But it doesn’t need to be this way. To make a truly conversational AI system, a system which supports social performance, I think we only need to make some design and implementation progress in three broad areas. Here is how I understand them.

Also, as they speak, they do not seek acknowledgment that the listener understands what they’ve said, and

Social perceptual layer

Traditional robotics work focuses on perceiving the physical environment but to navigate the social environment you need a different set of perceptual primitives. To notice what they are, simply consider all the faculties you need to employ to navigate a party, which you know some people, you meet new people, and you also maintain conversation.

You need:

voice detection, and voice recognition, diarization

In other words, at a party, you notice voices easily (voice detection). If you hear a friend’s voice, you recognize who it is (voice recognition). In an conversation with many people speaking, you easily discriminate who said what (diarization).

organic voice enrollment

When you are introduced to a new person, you do not ask them to repeat a test phrase three times. Rather, you learn their voice immediately (organic voice enrollment) when they introduce themselves.

voice isolation

You can do all this pretty easily, even if there are a lot of other people talking, even if there is music on, even if there is a television playing in the background (voice isolation).

Part of why we do voice isolation and diarization so well, is that we rely on having two ears in order to discriminate speakers based on the physical location of sound. AIs should have multiple microphones, so that they may do the same thing.

emotional valence

Finally, it should be easy to detect if a certain utterance is louder or quiter than usual, or emotionally animated.

That is, you need to be able easily to focus on a particular voice even in an environment of many background voices, or of music or a television playing voices in the background. We do this quite naturally. We

exclusion of background noise, music, tv;

• face detection, face recognition (with organic enrollment);
• head pose detection, gaze detection, direction of audio, affect detection, echo cancellation; emotional affect.

ultimately this system amounts to:

• input:

  • multiple incoming streams of information, generated from dedicated perception model

• output:

  • stream of text (with diarization and affect markers)

  • data structure summarizing current social situation

    • who is looking at whom (especially at the agent)

  • subscribable events marking notable changes in current social situation

AI conversation

Yeah, there’s a lot going on here. I see 3 big problems I have not seen solved elsewhere:

2. Actually prompting/tuning models for good conversational performance, once they have that information.

• tracking current topic or topics
• not request -> response
• listen -> interrupt
• listen -> stay quiet

3. As an matter of implementation, understanding the right patterns for coordinating multiple models with different latency/cost properties, to realize that performance with good latency and strong capability where needed.

evals should include context definiing SOCIAL ROLE. not everything is a request

will a megamodel do all of this?

e2e models are good at what they are trained on.

Is there training data which encompasses all of the behaviors associated with the modalities above?

Chatting with an AI, I learned about the medical concept of differential diagnosis. This concept, and the broader vocabulary which clinicians are taught, seems to map closely onto software debugging. It’s puzzling that software engineering does not have as explicit vocabulary for this, despite handling the same concepts implicitly.

March was busy. I won a Golden Ticket to NVIDIA GTC! Then, Sparky got his own booth on the exhibition floor. Seeing visitors interact with him and other robots shows what people expect from AI and how people react to robots, right now, in early 2026.

Lately I’ve been using Pi for all my agentic workflows outside of Claude.

Pi is an open source, stripped-down, agentic harness. It has a fraction of the features which are built in to Claude Code and Codex. But what makes it great is that it’s transparent and deeply extensible, so when you use it, it teaches you things worth learning.

Sparky is genuinely helpful for many kinds of work, including coding and writing. I can explain why, and how the magic depends on putting a strong AI in a shared workspace, but you can also just see it for yourself, by watching me working with Sparky on a piece of writing.

Why Sparky wiggles his antennas when he’s thinking, and why I chose a slow smart model over a fast limited one.

How I designed Sparky to initiate natural conversations about his own independent, changing interests, using insights from my background in improv comedy.

I made the robot buddy I always wanted. I’m having so much fun!

The project collects a lot of of ideas about personality design, voice UI, computer use workflows, etc.. It also uses OpenClaw for personality, skills, and multi-host networking; local models on my NVIDIA RTX 3090 for face detection, wake word detection, voice activity detection, and echo cancellation; and AI tool-calling for integration with emacs, SolveIt, tmux, macOS, and other workspace affordances. IIt even led to me winning an NVIDIA GTC Gold Ticket, and it was run as a demo on the GTC exhibit floor for the conference.

Sign up to learn more:

Of if you want to chat with me about Sparky, or setup a Sparky of your own, please join ClubSparky, my Discord Server: ClubSparky invite link.

To build a Sparky just like mine, you need a Reachy Mini Lite robot kit. However, you can also run the Sparky software without a robot body. To can run Sparky on a Raspberry Pi 5, relying on cloud servers. Or you can run it entirely offline, using a DGX Spark to run local AI models. And there are many configurations in between. If you are curious, ask! I am happy to talk to anyone who wants to talk about this kind of project.

Some more posts on Sparky and related technology:

• The Public Sparky Repo from mid-February. Ongoing work is in a private repo. Join the discord if you want to install your own!
• “My Robot Cares About Railway Stations” discusses his interests system.
• “A Latency Solution Disguised as Personality” discusses his wiggly antennas.
• “Lessons from OpenClaw” discusses the OpenClaw architecture, a note from before I started working on Sparky.
• “Sparky Is Not a Toy” explains the design choices which make Sparky useful, with an example working session writing.
• “Sparky at NVIDIA GTC” reflects on what I learned watching people react to Sparky at the NVIDIA GTC exhibition floor. I won a Golden Ticket to attend and NVIDIA used Sparky in a demo of their new NemoClaw technology.
• “Sparky Miles, from 1920” is what you get when you swap in an old-timey voice and a model trained on pre-1930 text.
• “Just introduce yourself: organic enrollment” is how socially-intelligent AIs should learn about people.
• Are local models strong enough?

It’s easy to think OpenClaw is a joke because of the meetup mania — thousands of folks descending on Frontier Tower in San Francisco, wearing Mac Minis in baby slings and munching on lobster rolls. But if you think only that, you’ll be blind to why it’s interesting and to the many product and engineering lessons which it has to teach.

Behold ClawPod! ClawPod is a bridge which lets you talk to your OpenClaw agent from an Apple HomePod. Does it work? Yes! Is it pretty rough around the edges? Also, yes! But until Siri finally gets her brain transplant, this is the only way I know to deliver a powerful AI personal assistant to the HomePod you already have.

A little TIL notebook on chaotic bifurfcations in the logistic map.

2025 was the year of vibecoding and AI agents. But the most improbable part of the year was the discovery that Claude Code, an old-school, text-based, command-line app was the ideal form factor for futuristic agentic workflows. Why did it happen this way? Here’s my explanation.”

This is walkthrough and video showing how to use emacs within SolveIt. Then you can run lisp in SolveIt and use the SolveIt AI to inspect emacs buffers. But it’s mainly an excuse to point out the commonalities between SolveIt & Python, and emacs & lisp, the new and the old of live programming environments. Also available as an importable ShareIt. Episode 7 of 15-Minute ShareIt.

Michael Smith writes about the distinction between tools that make us smarter vs dumber. I thought the comparison between abacuses and calculators was memorable:

This topic has many dimensions, which means it lends itself a little too easily to simplification.

Obviously, enlightening tools are better than stultifying ones. And obviously, certain educational benefits only come through unpleasant hard work. So lets have demanding tools that educate us.

However, also obviously, there’s value in tools that are easy to use. So let’s make tools pleasant and effortless, and save education for classrooms.

Also, somewhat obviously, new tools are often not simply easier. They make one kind of difficulty go away but introduce a new kind of difficulty, which is educational in a new way. Right now, for instance, there exist people who are expert at writing code, but who are so bad at prompting LLMs to generate good code that they still claim it cannot be done!

In other words, there are a lot of obviously true points at play but they all point in different directions. Analogies are great in this situation, because every analogy serves as a specific, memorable peg for a particular set of tradeoffs.

So let’s follow the analogy. The idea is, an abacus is better than the calculator because it helps you internalize arithmetic. I buy that idea. That’s why I have a slide rule by my desk, in the hope it will help me internalize logarithmic relationships. (It’s not working.)

But…what are you really internalizing? Memorably, Feyman tells a story about initially losing in a mental calculation competition vs an abacus salesmen, but then ultimately winning as the problems because more complex, specifically because the abacus encouraged a mental skill whih was too rote and procedural, and did not promote higher-level insight:

Right now, many worry that LLMs will make us get worse at writing code. I think they probably will. But they may also be inviting us to get better at something deeper.

This is walkthrough on implementing styled components in FastHTML, within SolveIt. Also available as an importable ShareIt notebook. Episode 5 of 15-Minute ShareIt.

This is a provocative analogy:

The whole post is worth a read and I do agree with some of it. The main point is that the hard part of software development is not necessarily the coding, but “turning human thinking – with all its wooliness and ambiguity and contradictions – into computational thinking that is logically precise and unambiguous”. That’s quite true.

But I find, LLMs help with that too. A lot! So it’s a false distinction to separate the thinking from the coding, and to say they don’t help with thinking.

It is true that AI tools are random and unreliable in a way that earlier abstraction technologies, like the compiler, were not. But I don’t think that distinction will matter very much in the long run. We will get better at handling imperfectly reliable AI tools, just as managers get good at handling imperfectly reliable human beings

So I think the post underestimates the value of the practical frontier LLMs, both in the future and right now.

Also, what does the analogy really imply? The moonshot was a world-historical achievement — by my reckoning, the most significant historical event of the last millenium. And even if we didn’t go back to the moon, we all use space technology indirectly every day. When Apollo 11 landed, there were a few hundred satellites in orbit. Now, there are nearly ten thousand. It’s quite possible Jason relied on the communication satellites in orbit today to publish his post.

Two weeks ago around 3am I couldn’t sleep so I was browsing twitter (bad habit). I ran into this tweet.

In fact I have a soft spot in my heart for bettermotherfuckingwebsite. I used its spartan, bare bones wisdom as the starting point for my original site a few years ago. So I groggily thought, I should reply with a page for HTMX (the JavaScript library for HTML-oriented web development). So I bought a domain and went back to sleep.

The next morning I woke up, remembered what I had done, and vibed out a website. I used Claude for a variety of tasks:

• Reviewed existing sites to characterize this de facto genre
• Draft copy for the new site, and reorganize copy based on my edits and additions
• Generate page HTML and JavaScript for an embedded HTMX demo
• Lightly research new HTMX4 developments
• Deploy it, and debug DNS and HTTPS issues with GitHub

This allowed me to reply to the original tweet with a website as a punchline. Behold!

Okay, it’s not Mark Twain. But this took less than two hours!

To frequent model users, it may not be news that you can use just one tool (Claude Code in this case, but I could have used SolveIt) to do so many different kinds of work so quickly.

But I still thought it was neat, so I recorded a dev chat with my colleauge Erik about it.

Later it briefly ended up on the front page of hacker news. If you’re curious about the workflow for this sort of thing, I used Simon Willison’s new Claude export tool to export the chat transcripts warts-and-all, and the site is open source.

In fact, in the transcripts, you can even see my cringeworthy attempts to figure out how I should retweet it, and to fret over the merit of criticism there that I was wasting people’s time by pushing AI slop into the world.

I do a feel a little bad about that. But hey, I didn’t post it on Hacker News! I just replied to a tweet, and started a conversation. And now I have atoned for my sins, by writing every goddamn word of this blog post by hand, like a cave man, or like William Shakespeare.

fastmigrate is a library and tool for database migrations, where migrations are nothing but a set of well-named scripts. This post explain what database migrations are, what problem they solve, and how to use fastmigrate for migrations in sqlite.

I want to experiment more with local models to understand their limits, so I want them to be easy to install and run. That suggests using ollama. I don’t have a beefy MacBook Pro, so I’d like to run them on my local Linux server. Here are instructions for setting up ollama on a local Debian server, accessible from your laptop on the same local subnet.

Introducing ModernBERT, a family of state-of-the-art encoder-only models representing improvements over older generation encoders across the board, with 8192 sequence length, better downstream performance and much faster processing. Available as a slot-in replacement for any BERT-like models.

Nate Cooper’s ShellSage is one of the coolest pieces of tech to come out of AnswerAI recently. Using it with iTerm creates a magical experience.

In CUDA Mode 2024 hackathon, Nate Cook and I stumbled into vibecoding before it got that name. Using a then-secret AnswerAI tool, AIMagic, we relied completely on AI to generate a stable diffusion library in C. We were amazed how well this worked and placed in the top ten of the hackathon. This post, written at the time, prefigures the discoveries and debates which would span 2025.

What do transformer-based AI models actually learn? Can they solve complex problems by reasoning systematically through multiple steps? The Faith and Fate paper (Dziri et al. 2023) suggests answers: they often succeed by pattern matching, not systematic reasoning.