Ambition has to match the problem space. Sometimes I stare at the Bay Bridge here in San Francisco, and I wonder to myself, as an exercise of "how much more ambitious could AI make us?" imagining a 10x version.. would it simply be a bridge 10x bigger? Is that the best I could come up with though? And why is the bridge there at all? ~15,000 years ago you could have walked from SF to Oakland across a dry valley floor (that is now the Bay, true story). Then the glaciers melted, water flooded in, and only then did crossing it become a problem worth solving: first with boats, then with a bridge, and eventually with BART’s Transbay Tube, which isn’t a bigger bridge at all.

Bridges exist to move people and goods across water within a particular envelope of needs and constraints. In this specific case, when the needs grew, the most ambitious answer was not a bigger bridge, but BART's Transbay Tube, which is an entirely different kind of thing.

So when I reflect on Dan's piece, it seems we're in agreement that AI is not provoking us to simply build bigger versions of things we already have.. but what remains unsettled is whether we know what we’re really building for yet.

There's of course the by-now oft-repeated story of electrification of factories, which had a 'first pass' of mostly swapping out the steam engine with one big motor, and otherwise preserving the same layout. Over time people redesigned floor plans around small motors at each machine (with Paul David’s “The Dynamo and the Computer” being the classic telling of this).

A lot of AI-assisted software development right now still feels like the one-big-motor pass at this. I suspect the projects really worth being ambitious about are probably the ones that only make sense once the entire factory floor changes, and I don’t think we're able to see that just yet. What Dan's doing is probably the right answer at the moment, building a lot of odds things and seeing what sticks.

Back to the Bay story, I think this moment is equivalent to our digital glaciers melting, and the water rushing in, than us having to figure out better "cranes", for example. It's changing what the world we're designing for is, what the whole problem space is, instead of whether we build bigger versions of things within the prior paradigm.

We look to our software stack today and we are tempted to imagine 'bigger', 'better', 'faster', 'more efficient', but... why? What are we really building _for_? We shall see!