They may seem like small details, but I think a couple novel design decisions are going to prove to be widely adopted and revolutionary. The biggest one (as Karpathy notes) is having skills for how to write a (slack, discord, etc) integration, instead of shipping an implementation for each. Call it “Claude native development” if you will, but “fork and customize” instead of batteries-included platforms/frameworks is…
> having skills for how to write a (slack, discord, etc) integration, instead of shipping an implementation for each I'm not sure what is the advantage. Each user will have to waste time and tokens for the same task, instead of doing it once and and shipping to everyone.
Old world - each platform writes APIs and then has to publish rich client libraries. Despite the server APIs theoretically being well documented, because users want the quickest time-to-first-demo platforms also ship a bunch of client code. This may bring in dependencies you don’t care for, or otherwise have a wide attack surface.
New world - platforms publish good REST APIs and specs, and Claude can trivially implement the client that is idiomatic for your own app deployment. Within Nanoclaw you don’t even need to handle eg streaming APIs if you only need a simple poll on one endpoint, even though the server (and official client library) might support them. In the best case, this can keep your app more secure.
Of course, the tradeoff/risk is that an individual implementation might be broken. So right now I’m not convinced it’s a win. But I generally buy that it’ll be possible to maintain a high enough security bar within the next year or two.
The time and token cost is probably seconds and cents already, I don’t buy that one.