Was non-trivial (e.g. days and days of cumulative work) but worked with Codex to build up a parametric generator where I could adjust the star size, number of rings, leds per ring. It did all the LED-to-LED routing, panel layout with mouse bites, placed decoupling caps. At the time Codex wasn't as good at spatial reasoning, I expect that Astra would do this much faster.

4 x layer PCB with GND and 5V inner layers. WS2816B LEDs (not available in strips yet). 3D printed a frame so that two stars could be opposite each other (video shows only one side). ESP32 S3 on a 3.3v to 5v shifter board sandwiched in between. ESP32 wifi antenna pokes through and sits on a keep out section. Received control signals from a central controller via ESP Now.

What's becoming more important in human's relationship with technology is restraint. Dopamine comes from the journey, not the destination, and for a journey to be meaningful, there needs to be some amount of challenge / struggle. The increasingly important skill to lead a fulfilled existence is learning how to optimally balance ease vs. challenge.

Entirely feasible that by 2031, Fable 5 (or greater) intelligence level models will run cool on smart phones, if not sooner.

Not doing crazy multi agent swarms, but have yet to hit any limits during pretty intense weekend sessions.

You still need a lot of skill to digest and understand the proofs, but "this is the worse it will ever be." I'd imagine part of the motivation of a large set of mathematicians is to be the "first" or to crack the nut that others couldn't. If Mathematics becomes working with an AI to get a Lean certificate, and then essentially reverse engineering that into something digestible, then it's fundamentally a different pursuit.

Software Engineering feels a little less impacted? Though if you identify with loving coding, then perhaps similarly? I've always liked the outcome of what writing code can do, and enjoyed the craft hand coding for the past ~30 years. But I haven't once ever missed writing code by hand since Opus 4.6, I couldn't go back.

You really need to add yourself as a human in loop to be in the middle of design choices. That is, ask the model for a plan, what the trade offs are, should parts of the code be refactored before the next feature, etc.

Also, there’s an element of reading the code and ordering refactors. I’ve noticed that for embedded code codex loves to to do everything in a main.c and too many compiler defines. Asking it to propose a refactoring into modules helps a lot.

It’s just like writing real code, if you don’t do design up front and don’t aggressively refactor as the requirements change, it becomes a mess.

Ideally you ask the agent the thing you want to know / business question you want answered.

An agentic loop then runs. The agent can look at the schema, look at any existing SQL scripts available that query similar tables, run a few limit 10 probe queries. Analyze the data, do some joins, check the data again. Show you the data, ask for feedback, etc.

Pure zero / one shot SQL generation isn’t the solution and isn’t how humans do things. We look at the schema, run some queries, do some joins, spot check the totals / row counts, etc.

Fork Tao’s convo and prompt this (with your own math level described).

GPT did a great job of translating Tao’s questions and concepts (e.g. “pre image”) into a progression I could understand.

“Ok I have a PhD in financial math and undergrad in engineering math. I have almost zero knowledge of polynomial algebra / geometry, I know what a polynomial is and what roots are but not much beyond that. Could you try and explain to my level what questions the user I the conversation has asked and what the agent has responded with, we can probably go user query by user query to build up”

One person dedicated to a single project / task baseline 100% total output.

One person split between two tasks / projects that require context switching, 70% total output at best, perhaps 50% total output, a loss of 50%.

One person working on a single task that they’re passionate about / intrinsically motivated to complete: 150-500% output.

When you have one task / project to think about and focus on, it engages your brain: sleeping, showering, walking, your subconscious is processing.

Adding just one extra project / task that requires a context switch mostly kills this subconscious processing mechanism.

Waymo is probably safer, but safety comes at the risk of not behaving like a human, and hence causing confusion for other human drivers.

Tesla drives more like humans drive.

I can only recall one "oh shit" moment on an older FSD version when it carrier too much speed down a steep hill in SF and went through a 4-way stop and I had to slam the brakes. A lot of the strangeness / hesitance of previous FSD version is gone in the latest updates.

I don't expect self driving to be 100% perfect. I feel like FSD today is a 90th percentile human driver with super human reaction speed + visibility. Holding a "never gets into an accident" it too high of a bar. FSD consistently drives better than me (with the caveat of navigation: I know the city, I know which unprotected left turns are easy vs. hard, I know which routes tend to be faster due to local conditions, etc).

FSD is excellent in how reactive it is to thing you don't even see: e.g. car on the 101 at slightly drifts into my lane, I didn't notice it, FSD reacted. I feel WAY more unsafe now riding in an Uber vs. hands off FSD'ing in a Tesla.

The gap isn't that big. Tesla still needs supervision (most around navigation honestly). Waymo's have definitely done some really dumb things.

Waymo's certainly feel safer but if I had to choose which was the better "human driver" I'd put it on Tesla.

Hand crafting a voice agent to schedule simple appointments for a barber in San Francisco where the caller is in a quiet environment, is a one day exercise in prompt engineering.

Building a voice agent to schedule real appointments (on a real calendar of a working business) for real customers, for any business type, in any city: significantly more difficult. Real customers can be on a bad cell connection, have background noise, or worse, there's somebody in the background having another conversation.

Building a working agent isn't the hard part of building a real world agent. It's establishing human and offline evals, identifying loss patterns, hill climbing, capturing and processing user feedback, doing hacks to deal with model limitations, learning how an agent-driven conversation has to be subtly different from a real human conversation, and so on.

First time I started to read it, it was a slog and I didn’t get far.

Did a bit of research on translations and chose another one (can’t recall the exact translator).

The 2nd attempt’s translation used more contemporary language, which made it much more understandable and got through it.