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.

Just like anything in engineering really: you have to play around source control to understand source control, you have to play around with database indexes to learn how to optimize a database.

Once you've learned it and incorporated it into your tool set, you then have that to wield in solving problems "oh, damn, a database index is perfect for this."

To this end, folks doing flights and scheduling meetings using OpenClaw are really in that exploration / learning phase. They tackle the first (possibly uninventive thing) that comes to mind to just dive in and learn.

The real wins come down the line when you're tackling some business / personal life problem and go: "wait a second, an OpenClaw agent would be perfect for this!"

To then "aggregate" all of the json outputs, I had Claude look at the json outputs, and then iterate on a Python tool to programmatically do it. I saw it iterating a few times on this: write the most naive Python tool, run it, throws exception, rinse and repeat, until it was able to parse all the json files sensibly.