Global electricity provider revenue is $7T, so $6T for a whole new horizontal category of "thing" isn't unreasonable.
982 karma · joined November 15, 2012
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.
The better pitch would be, "this is how easy observability, guardrails, monitoring, deployment, evals, versioning, A/B testing are with our framework." What the agent code looks like is somewhat incidental.
BUT, if you boil it down, an agent really is context building, making an LLM call, executing requested tool calls, parsing the final model output, returning it to some frontend. There's extensions like memory, async tool calls, etc, but not THAT complicated from a traditional software engineering perspective.
Everyone seems to want to build their agent framework. But if you're tasked with building an agent, I've found it much easier and more maintainable to just build 1:1 code for THAT agent: most of the abstractions you get from an agent framework purely get in the way and obfuscate core agent logic.
You end up being forced to use the abstractions chosen by the agent framework, which sometimes are a mismatch for what you're actually trying to do.
Naive thought: I could use a large bolt cutter to cut chain links. Started trying to cut a link, felt it was sketchy, went and put on some safety glasses.
Restart cutting (had these bolt cutters with like 1m long arms), apply full force, jaws slip a bit on the chain, jaws bite hard. Chunks of steel fly into my chin and face, metal chunks embedded in chin, cracked safety glasses. Dodged a bullet.
Ended using a small welded up jig so I could stretch the chain and then use angle grinder to cut the chain links. Still sketchy, but no flying metal chunks.
Wish I had a plasma cutter.
Genuinely curious about your statement that its an illusion / arbitrary distinction, to figure out if there's a gap in my thinking / reasoning. To me there's a clear distinction between the actual thing happening via physical dynamics vs. us (humans) having creating a discretized abstraction (binary computation) on top of that and running a process on that abstraction.
Maybe there's some true computational universality where the universes dynamics are discrete (definitely plausible) and there's no distinction between how a processes dynamics unfold: i.e. consciousness binds to states and state transitions regardless of how they are instantiated. I did use to hold this view , but now I'm not so sure.
a) Actually pouring a cup of water into a pond (layer zero), and
b) Running a fluid dynamics simulation of pouring a cup of water into a pond (some layer above layer zero).IIUC the author is saying that the human brain is running directly on "layer zero": chemical gradients / voltage changes, while AI computes on an abstraction one layer higher (binary bit flips over discretized dyanmics).
In essence, our brains are running directly on the "continuous" physical dynamics of the universe, while AI is running on a discretization of this (we're essentially discretizing the physical dynamics and to create state changes of 0 -> 1, 1 -> 0).
My currently belief is that consciousness is some kind of field or property of the universe (i.e. a universal consciousness field) that "binds" to whatever information processing happens in our wet ware. If you've done intense meditation / psychedelics, there's this moment when it becomes obvious that you are only "you" due to some kind of universal consciousness's binding to your memory and sensory inputs.
The "consciousness arises from information processing," i.e. the consciousness field binds to certain information processing patterns, can still hold, and yet not apply to AI (at least in its current form): The binding properties may only apply to continuous processes running directly on the universe's dynamics, and NOT to simulations running on discretized dynamics.
Those days of grinding on some grad school maths homework until insight.
Figuring out how to configure and recompile the Linux kernel to get a sound card driver working, hitting roadblocks, eventually succeeding.
Without AI on a gnarly problem: grind grind grind, try different thing, some things work, some things don't, step back, try another approach, hit a wall, try again.
This effort is a feature, not a bug, it's how you experientially acquire skills and understanding. e.g. Linux kernel: learnt about Makefiles, learnt about GCC flags, improved shell skills, etc.
With AI on a gnarly problem: It does this all for you! So no experiential learning.
I would NOT have had the mental strength in college / grad school to resist. Which would have robbed me of all the skill acquisition that now lets me use AI more effectively. The scaffolding of hard skill acquisition means you have more context to be able to ask AI the right questions, and what you learn from the AI can be bound more easily to your existing knowledge.