This is the topic of almost every conversation I'm having with friends who are programmers right now. The compiler analogy (we basically never read compiler output) is the thing I keep thinking about.
Yes, but also ... the analogy to assembly is pretty good. We're moving pretty quickly towards a world where we will almost never read the code.
You may read all the assembly that your compiler produces. (Which, awesome! Sounds like you have a fun job.) But I don't. I know how to read assembly and occasionally do it. But I do it rarely enough that I have to re-learn a bunch of stuff to solve the hairy bug or learn the interesting system-level thing that I'm trying to track down if I'm reading the output of the compiler. And mostly even when I have a bug down at the level where reading assembly might help, I'm using other tools at one or two removes to understand the code at that level.
I think it's pretty clear that "reading the code" is going to go the way of reading compiler output. And quite quickly. Even for critical production systems. LLMs are getting better at writing code very fast, and there's no obvious reason we'll hit a ceiling on that progress any time soon.
In a world where the LLMs are not just pretty good at writing some kinds of code, but very good at writing almost all kinds of code, it will be the same kind of waste of time to read source code as it is, today, to read assembly code.
Happy to answer questions about this (or work with people on further optimizing the open source inference code here). NVIDIA has more inference tooling coming, but it's also fun to hack on the PyTorch/etc stuff they've released so far.
The Twilio integration made me smile. (For context, the default way to use this is a WebRTC connection from your mobile device to talk to Claude Code, but any network transport supported by Pipecat works.)
I'm trying to come up with a use case where I need to call my Claude on the phone, rather than connect to it in a more modern way.
Morris has written some of my favorite long-form New York Times pieces, ("Willie Nelson's Long Encore", "Aretha Franklin Had Power. Did We Truly Respect It?", ), and he has the novelist Min Jin Lee and Gilbert Cruz, editor of The New York Times Book Review, as guests on the podcast to talk about why they regularly re-read Gatsby.
Min Jin Lee talks about how amazing the craft of the novel is (beyond the obvious greatness of the sentence-by-sentence writing).
A couple of months ago I was in New York and found a new cyberpunk re-telling of Gatsby called Local Heavens. A fun read if you like Fitzgerald, or re-imaginings of famous novels, or cyberpunk.
The integrated developer experience is much better on Vapi, etc.
The goal of the Pipecat project is to provide state of the art building blocks if you want to control every part of the multimodal, realtime agent processing flow and tech stack. There are thousands of companies with Pipecat voice agents deployed at scale in production, including some of the world's largest e-commerce, financial services, and healthtech companies. The Smart Turn model benchmarks better than any of the proprietary turn detection models. Companies like Modal have great info about how to build agents with sub-second voice-to-voice latency.[1] Most of the next-generation video avatar companies are building on Pipecat.[2] NVIDIA built the ACE Controller robot operating system on Pipecat.[3]
One easy way to build voice agents and connect them to Twilio is the Pipecat open source framework. Pipecat supports a wide variety of network transports, including the Twilio MediaStream WebSocket protocol so you don't have to bounce through a SIP server. Here's a getting started doc.[1]
(If you do need SIP, this Asterisk project looks really great.)
Pipecat has 90 or so integrations with all the models/services people use for voice AI these days. NVIDIA, AWS, all the foundation labs, all the voice AI labs, most of the video AI labs, and lots of other people use/contribute to Pipecat. And there's lots of interesting stuff in the ecosystem, like the open source, open data, open training code Smart Turn audio turn detection model [2], and the Pipecat Flows state machine library [3].
Disclaimer: I spend a lot of my time working on Pipecat. Also writing about both voice AI in general and Pipecat in particular. For example: https://voiceaiandvoiceagents.com/
I'm going to politely weigh in here and say things Sean won't say about himself.
You're talking to someone who has spent the last ten years building open source WebRTC software that many, many, many people use and that he's never tried to commercialize. He works tirelessly to make the Pion community welcoming to everyone, from engineers with a ton of networking/video experience to brand new contributors. He wrote the guide that should be everyone's first read about WebRTC.[] All of it as a labor of love.
I honestly can't tell if this is trolling. LEGO bricks are pretty new technology, in the scheme of things. The original LEGO company "binding brick" was created in the late 1940s.
Of course you don't "need" an LLM to have a great toy. You also don't "need" injection-molded plastic. But if you have access to one or both, that can be pretty great!
Source: I wrote the spec for the first version of the LEGO Mindstorms programming language. These days I build a lot of voice+LLM stuff, some of it for big companies, some of it for myself and my kid.
I've done a fair amount of fine-tuning for conversational voice use cases. Smaller models can do a really good job on a few things: routing to bigger models, constrained scenarios (think ordering food items from a specific and known menu), and focused tool use.
But medium-sized and small models never hit that sweet spot between open-ended conversation and reasonably on-the-rails responsiveness to what the user has just said. We don't know yet know how to build models <100B parameters that do that, yet. Seems pretty clear that we'll get there, given the pace of improvement. But we're not there yet.
Now maybe you could argue that a kid is going to be happy with a model that you train to be relatively limited and predictable. And given that kids will talk for hours to a stuffie that doesn't talk back at all, on some level this is a fair point! But you can also argue the other side: kids are the very best open-ended conversationalists in the world. They'll take a conversation anywhere! So giving them an 8B parameter, 4-bit quantized Santa would be a shame.
I 100% agree with Sean that the computer is an exploration machine. There are lots of net positive things for kids (and non-kids) that LLMs make possible. Just like there were lots of net positive things that an Internet connection makes possible.
Of course there are things technologies can do that are bad. For kids. For adults. For societies. But I build this kind of voice+LLM stuff, too, and have a kid, and the exploration, play, and learning opportunities here are really, really amazing.
For example, we are within reach of giving every child in the world a personalized, infinitely patient tutor that can cover any subject at the right level for that child. This doesn't replace classroom teachers. It augments what you can do in school, and what kids will be able to do outside of school hours.
This repo is one possible starting point for tinkering with local agents on macOS. I've got versions of this for NVIDIA platforms but I tend to gravitate to using LLMs that are too big to fit on most NVIDIA consumer cards.
As someone who spends a lot of time looking at timestamped log lines to debug Pipecat pipelines, I'm a big fan of this work from Aleix.
In general, I have three pain points with debugging realtime, multi-model, multi-modal AI stuff. 1. where's the latency creeping in? 2. What context actually got passed to the models. 3. Did the model/processor get data in the format it expected.
For 1 and 3, Whisker is a big step forward. For 2, something like LangFuse (Open Telementry) is very helpful.
In general, for realtime voice AI you don't want this model to support multiple speakers because you have a separate voice input stream for each participant in a session.
We're not doing "speaker diarization" from a single audio track, here. We're streaming the input from each participant.
If there are multiple participants in a session, we still process each stream separately either as it comes in from that user's microphone (locally) or as it arrives over the network (server-side).
Endpoint detection (and phrase endpointing, and end of utterance) are terms from the academic literature about this, and related, problems.
Very few people who are doing "AI Engineering" or even "Machine Learning" today know these terms. In the past, I argued that we should use the existing academic language rather than invent new terms.
But then OpenAI released the Realtime API and called this "turn detection" in their docs. And that was that. It no longer made sense to use any other verbiage.
Turn detection is deciding when a person has finished talking and expects the other party in a conversation to respond. In this case, the other party in the conversation is an LLM!