around 9:30 "this is a thing that has its use for the little things, but the moment you start expanding it"

This is just plain wrong. We deal with codebases in double digit millions LOCs with models - it takes genuine skills and instrumentation to do right, but it does work. And I know devs who take this view - that AI is dumb, useless, a gimmick - and what they have in common is they have not tried to put in the hours to learn how to tame the beast.

Anyway, I am losing interest in debating the topic, the efficient markets will deal with this objectively. I can't see how a company employing the usual high-low mix of developers can compete with a company that has a small number of elite devs equipped with those tools and unencumbered by having to manage large development teams and associated bureaucracies. Time will tell.

Now, remind yourself when was the last time you had to work with a developer who went to CS because it pays well, and has zero enthusiasm for what they are building, and are just phoning it in, with minimum effort and low skills. AI models are coming for those people first. And those people are in the fricking millions. Strip IT teams to people with passion either for product or for tech, give them such tools, and watch. Compare this with a normal IT shop with a bunch of great people, a metric ton of average people, a few toxic imbecilles, and the necessary HR/management bureaucracy to keep that bunch on a leash.

Also, I dont think Boris C. is coming here for PR. He is a tech guy, and this is the best place for tech discussions. Why so cynical? The guy is an engineer.

I just completed recreating one of my childhood favourites, Thrust. Opus 4.7 almost one-shot the game (was perfect in 30 mins based on just the wikipedia entry describing the game), and then I spent 3 full nights trying to build perfect algorithmic AI to auto play it. (It thoroughly failed, sticking to a sub-par algo that was ok, but not nearly as good as possible).

My next stop is reimplementing Mercenary. First open world game I played. On a 8b commodore Plus/4.

For now its just tls fingerprinting, not client attestation - so, I managed to implement a working solution. But I am sure they will tighten the screws still further.

They lost a lifetime customer in me - i think i have spent close to 20k on garmin gear between my wife and myself, watches, gps devices for cars, boats, and hiking gear. If they refuse to give me access to my data, i will (a) lobby for laws to be passed to make this mandatory (b) absolutely never ever buy anything garmin until i see a reversal of this policy and an apology.

More broadly though, its yet another service that blocks API access. No doubt this is caused by proliferation of amateurs armed with agentic tools building nice, personalized frontends for themselves. Companies seem to absolutely hate it when people dont go through their shitty websites with dark patterns, misleading search results and analytics.

I am nearly 50, started with computers when I was 7. I did sort of everything -from wiring individual transistors together into custom logic circuits, assembly on various platforms, drivers and other kernel level stuff on dos and then windows, low level networking, higher level monolithic systems design, infrastructure management, various storage systems, various compute implementations, obnoxious types of software defined networks, security stacks - from hardware based attestation through identity/role management in multi-cloud environments, higher level distributed systems and finally i am a cto for a large-ish company and do a lot of enterprise architecture.

I also dabble in hobby programming on various things, building custom firmwares for chinese electronics, building frontends and backends for side projects, I have built a js framework or two just to understand state and rendering stuff, and of course now i am dabbling with local LLMs, because thats the new thing that can be learned.

I am sure there are lots of people with similar experiences in my age bracket (I am 48) - who had a lot of exposure to all levels in the stack. Sure, I was never particularly good with anything I mentioned, but thanks to a mix of diverse work experiences and absolute, uncompromising love of learning new computer things, I think I do have a fairly good understanding of what happens in computer systems, big and small. Now, could I design, say, a modern ELB properly, no, but I do understand the networking stuff enough to at least outline the design and key elements of the system without asking a friendly LLM. No such luck for kids these days, I am afraid - they will be actively shielded from having to learn stuff the hard way.

Linus Torvalds, a few months ago, said something to this effect when discussing AI coding tools. That his (also, mine) generation was lucky to have started with low level stuff and managed to retain the understanding of the whole stack - and kids these days don't get that. Good luck acquiring this level of feel for computers, algorithms, data structures today, when a kid's first experience with coding will be a seemingly genius chatbot.

As for webrtc - it was mainly for decent support in browsers and built in AEC. I think we will take another look at this design choice if we run out of ways to further optimize.

There is a great resource for learning this stuff - the CEO of Daily, Kwindla Kramer, hosted a series of 1hr sessions on low latency voice ai. Here:

https://youtube.com/playlist?list=PLzU2zoMTQIHjMPZ-OnpC3ozZs...

Some of this is a bit outdated but most of it is very valuable.

Kwindla posts a lot of extremely useful stuff on x and linkedin, incl. working, easily replicable sub 500ms setups.

Not my experience, running around 6,000 conversations per day with voice, with webrtc + cascading (stt/llm/tts) architecture.

Maybe I misunderstood your comment, but that 500ms is basically the floor of a stat of the art voice implementation these days - if you are lucky and don't skimp, and do various expensive things like speculative decoding and reasoning. 450ms on the LLM pass alone. Every ms counts in commercial applications of voice ai. If you add 200ms or 300ms to that, it really degrades the conversation.

We do a lot of voice stuff to support our business, largely with unsophisticated, non technical users. Last year's attempts, with measured turn to turn latencies of around 1200ms-1500ms, led to a lot of user confusion, interruptions, abandoned conversations and generally very unpleasant experiences. We are at around 700ms turn to turn now, depending on tool usage needed, and its approaching an OK experience, rivalling an interaction with an actual human. We are spending quite a lot to shave another 100ms off that. We do expensive, wasteful things such as speculative LLM passes, we do speculative tool executions (do a few LLM inferences as the user speaks, but don't actually execute non-idempotent tool calls before you know that that LLM pass is usable and the user did not say anything important at the tail end of their sentence) just to shave 100-200ms. When someone says 500ms is irrelevant I am sure they are describing some other use case, not human-to-AI voice interactions.

In my experience with voice AI, the problem is not with some occasional dropped webrtc packets. The real hard problem is with strong background noises, echo, and of course accents. WebRTC with its polished AEC implementations helps quite a lot at least with echos. I get the protocol is a major PITA to implement at OpenAI scale, but for anything but hyperscale applications there is lots of good, viable solutions and commercial providers (say, Daily for instance) that make it a no problem. The real problems to solve are still elswhere. But boy, add 500ms to my latency budget and you've killed my application.