Most of my Waymo rides were from or to a BART station - the real utility of these services is to pull a last mile when I don't have a car.

There's no better way of getting out of Powell out of the traffic deadlock at 5 PM than BART.

But once you get south of Daly City, there's no timed connections for the surface streets.

If you need to go to Brisbane from Powell, the 2 mile car ride is worth the effect.

My agent harness spins up a VM too, but it spins up on demand, cools down in 10 minutes and warms up when I focus back on the app.

The files it works on actually lives in a mount.

People take more time to type a prompt than the VM takes to spin up on a fast machine and on a slow machine, the cooldown naturally frees RAM back to the machine.

> Again, it wasn’t perfect. As an expert, I was able to spot some errors and omissions (some as a result of the design I had asked for) that I had the AI correct

That's the bit that stuck out to me - that's longer than I would expect to work on a problem in a day or even expect to go back & fix the output of something that has a core reward loop of hours.

My customers are currently clamoring to push down my agent response times from 85 seconds down to below the 20s mark.

At the same time, it is very dissonant to see the industry heading towards hour+ long workflows with an agent.

I remember being in my 20s and not being able to sleep, but the most distracting thing I could reach for was a pile of books in my bedside table.

Now, I can't sleep, there's an endless stream of things to keep me awake.

The jokes about "5G gives you cancer" is probably not as funny, if you think about the sleep you miss while you doom scroll.

Usually we end up writing a script to incrementally refresh a data-set I'm analyzing (or have someone send me a copy after they pull it).

I've been using sqlite for anything which needs an UPDATE - modifying a row deep inside the data-set with jsonl is a pain.

My github is full of java programs which update sqlite3 files with threadpools and a single big lock around the UPDATE (& then I write or have an agent write code to analyze it).

DuckDB is slowly replacing it in the context of python, simply because of the ease of pushing a UDF into the SQL.

Also because I really like expressing things as LEAD/LAG with a UDF on top.

I might live till 72, my kids will be my age right now when they hit inheritance instead.

That's not a headstart.

My work is in tick-tock loop of learning - learn without modifying weights, demonstrate learnings to human, but then lock it back in (accumulate and spread).

This looks less like training and more like mentoring.

Getting a human to mentor an agent is a hard UX task, but the learning loop is not a technological problem anymore.

We can only get a tick once a week, no matter how many tocks we can do an hour.

Those aren't the deal breakers.

They entirely rely on the competence of the folks they hired and cross-match enforcers with the drivers they have - they deal with fallible people on both sides of that.

The fundamental difference is that the humans are good consequence predictors, have built up reputations they are not willing to trash, can say no to things and in general don't want to go jail.

AI tools look like that, but don't have any of the useful conflict which came for free with employing humans.

It also doesn't have any useless conflict, but not all conflict between what I say and what someone is willing to do is bad conflict.

In my small circle of car friends, the new Ferrari is being called the "Magic mouse" of ferraris and posting memes of the car upside down with the cable plugged in at the bottom.

I was hoping for an SF90 meets Nevera when they were talking about it originally :(

But that is entirely unoriginal and derivative, compared to a designer wanting to make a mark.

Unlike the usual Bettridge's law, the answer to the headline is only a qualified "No".

It is a "So is all other cancers!", which is pretty bad news for folks who are young and healthy right now.

The day it broke away and became centralized was when we had a PR + mandatory "Required actions" to merge to main.

I use AI coding tools every day, but AI tools have no concept of the future.

The selfish thinking that an engineer has when they think "If this breaks in prod, I won't be able to fix it. And they'll page me at 3AM" we've relied on to build stable systems.

The general laziness of looking for a perfect library on CPAN so that I don't have to do this work (often taking longer to not find a library than writing it by hand).

Have written thousands of lines of code with AI tool which ended up in prod and mostly it feels natural, because since 2017 I've been telling people to write code instead of typing it all on my own & setting up pitfalls to catch bad code in testing.

But one thing it doesn't do is "write less code"[1].

[1] - https://xcancel.com/t3rmin4t0r/status/2019277780517781522/

My systems are hitting exponential delay retries, so this might not get better because retries overload things again.

> {'type': 'error', 'error': {'details': None, 'type': 'overloaded_error', 'message': 'Overloaded'}, 'request_id': 'req_ ...

I can see a weird spike in my cache hit-rate a few minutes before, so this might actually be some extra caching they have thrown in.

There's many reasons, but in general incompetence, malice and small crumbs problem.

I've done my small share of M&A DD work as an engineer, which was a lot of fun, but the results on my sanity and my outlook was bad.

On one hand, you get to go talk to a core founder of a company and they're entirely open to you picking their brain on "Why this" / "Did it pay off?" on pure eV math they did in their heads.

On the other, you see what happens after your recommendation and it is not within your control to change any of it.

Incompetence is generally "Please rewrite this software by our practices" devops hell or "Let's look for better customers for this product, ignore the old ones" in the ICP land. Google and dodgeball comes to mind.

Malice is more clear cut, where "Let's buy it and shut it down, so that we don't have a threat to our business" - I'm eagerly waiting to see what happens with Groq and Nvidia for example. AWS buying Groq would've been massively different. Classic case in point is Apple buying Fingerworks & shutting it down, but launching the iPhone.

Lastly, there's the small crumbs problem (or as it has been famously said "Do not anthropomorphize the lawn mower").

A company can get bought and the product doesn't really add great value to the buyer, beyond getting a few people who really know the space. The small number of people them gets redistributed into a neat set of existing reqs where they just accelerate the existing company's products based on that knowledge or in general fail to surface back to make a significant ripple in the future.

For example, I am wondering what will happen to Promptfoo after OpenAI.

The Claude Code rendering UI is the first place where I realized the TUI is more like a DOS or Borland UI system rather than a command line interface.

I was poking about CLAUDE_CODE_NO_FLICKER=1 setting when I realized what exactly this TUI is, it is layers of stuff showing up on top of each other with terminal codes.

Ended up reading the Ink Terminal implementation of React

https://github.com/vadimdemedes/ink

Fascinating how it ends up looking Wordperfect or Wordstar from the past instead of pixel based graphics.

The usability for a vision impaired user is about the same, though I remember braille pads for DOS tools (80x25) which work better than all the screen readers which came later.

I haven't pushed out a full version[1] which uses ducklake-wasm + this to make a completely local SQL answering machine, but for now all it does is retype prompts in the browser.

[1] - https://notmysock.org/code/voice-gemini-prompt.html

I really loved all the places where they snuck in "Game Never Ending" in the product, because they didn't set out to make a photo sharing product, but steered hard into that.

Flickr was the only property which was allowed their own version of PHP and despite having PHP inside, every single URL said ".gne" (Game Never Ending). I worked for the PHP team and that was my only excuse to show up to work in the SF office instead of being stuck in Sunnyvale when visiting the US.

They had all the right bits of architecture built out - rest of Yahoo had great code (like vespa or the graph behind Yahoo 360), but everything was more complex than it should be.

Flickr had the simplest possible approach that worked and they tried it before building anything more complex - the image urls, the resize queues, the way albums were stored, machine-tags, gps co-ordinates.

I also took a lot of photos to put up on flickr, trying to get featured on the explore page up front - it was like getting published in a magazine.

Every presentation I made had CC images backed by flickr, it was a true commons to share and take.

And then Instagram happened.

https://github.com/llvm/llvm-project/pull/181288/files

As the PR clearly points out, you can do this in a register but not inside vectors.

I don't think fastdiv has had an update in years, which what I've used because compilers can't do "this is a constant for the next loop of 1024" like columnar sql needs.

That is sort of comparable to how NAND simplify scaling.

Division is hell on gates.

The single component was the reason scaling went like it did.

There was only one gate structure which had to improve to make chips smaller - if a chip used 3 different kinds, then the scaling would've required more than one parallel innovation to go (sort of like how LED lighting had to wait for blue).

If you need two or more components, then you have to keep switching tools instead of hammer, hammer, hammer.

The Smedly Butler book was eye opening to read for me.

Diplomacy and trade works wonders when the enemy still wants you to buy things.

Sanctions work when they've got things to sell (and raw materials to buy), not bombed out craters where their factories were.

Si vis pacem ...