Wardley's original post on this [0] is worth a read. OP adds cowboys and city folk, and makes it a bit more personal.
5 interesting things that are worth making explicit:
1. These teams/roles are as much about appetite and attitude, as they are about someone's skills and capabilities. Some people just aren't comfortable or happy when operating in these environments.
2. Innovation isn't just at the early "0 to 1" stages. Townspeople need to innovate to scale from a million users to a billion.
3. Successful orgs have teams at all stages, working together. Each team evolves what the previous stage built. And cowboys / pioneers are only successful if they can build on industrialised components.
5. As a product evolves, it moves through the stages. Teams either need to let go, or change their way of working.
In other words, gradient descent isn't good at combinatorial optimisation. I'm sure the research is better but the hype in the blog post leaves a bad taste.
There must be a version of Rich Sutton’s Bitter Lesson that applies to alternative computing like this, along with all the other exciting specialised hardware we've seen come and go over the years, like expert systems, optical computing, neuromorphic computing, etc.
Something like:
General purpose commodity silicon with rapidly evolving software generally beats specialised hardware.
Software is just so much faster to iterate and improve than hardware. AI is also improving it too (eg AlphaEvolve).
Specialized hardware may give a single, significant improvement that grabs headlines but in the long term, compounding small improvements win.
It looks a lot like a CvRDT (i.e. a state-based CRDT).
They describe it as a commutative monoid, which means it has associativity and commutativity. CvRDTs also need idempotence, so they can handle duplicate data. Either they are idempotent too (which would make it semilattice-like), or the network protocol handles the deduplication outside of the data itself.
Letting the payload/application define the merge operation is clever. I assume it would mean contracts could opt in to idempotency if it doesn't already exist.
The other bit Freenet has added is doing all this with DHT routing and subscriptions, rather than a more basic peer mesh. This is very different to a blockchain and means it probably isn't suited for anything transactional.
> Heck, there's others who were wealthy in scripture, even kings are they all doomed?
This is a great question. In the next verses, the disciples ask pretty much the same thing: "Who then can be saved?" and then Jesus explains to them:
With men this is impossible, but with God all things are possible.
Whether it's a camel or a rope (and whether it's a literal needle or a small city gate, as some people argue), I think is less important (though still interesting). Either way, after the rich young ruler walks away, Jesus turns to his disciples and paints a picture something that's completely impossible without God, no matter how hard we might try by ourselves.
Genesis is a theological narrative, which is very different to most things we read these days, especially as a software engineer.
1. The general consensus is that there were more people. This is assumed in Genesis and it (annoyingly!) doesn't bother to explain it, as the audience at the time already assumed it. Also, the authors weren't interested in all the logistics and technicalities that we are today.
2. Cities referenced in Genesis were likely fortified settlements, rather than like modern cities.
The idea that people in Africa could only build simple huts is a myth that came from the colonial era. Africa had large cities, architecture and metallurgy while parts of Europe were still tribal.
If you're keen to learn more, there are some good books that explain this much better than a comment can, such as "How to Read the Bible for All Its Worth" by Fee & Stuart and "Genesis for Normal People" by Pete Enns. I haven't read it but "African Civilizations" by Graham Connah is probably the go-to book on how African cities and technologies were so much further ahead than traditional European/US narratives place them.
The best resource for these kinds of questions is probably "The Bible Project". They have a load of YouTube videos and podcasts that cover these kinds of questions.
From the docs, `add-skill` auto detects from 16 different potential paths to copy skills to in a repository (.claude/, .codex/, .Gemini/, etc).
`add-skill` also let's you install skills globally (~/). From the code, `skills` looks like it doesn't support global installs but under the hood it passes all args to add-skill, so you should be able to install skills globally or install multiple skills (even if the wrapper doesn't expect it).
Aside: although lots of agents have adopted SKILLS.md conventions, they're currently all using their own paths. There doesn't seem to be a consensus yet, like there is with AGENTS.md. There are even 3 generic paths: .agent/skills/, .agents/skills/ and just skills/
Langton Matravers is about 2km north of the coast. The 3 norths will have met land at a place called Dancing Ledge, at about SZ 00000 76833 (50.59121, -2.00000).
I know what you're thinking: these restrictions are easy to work around. But don't worry, we can just layer more restrictions on top. Eventually the children will be safe! The government just needs to...
- require proof of age (ID) to install apps from unofficial sources on your phone or PC. Probably best to block this at both the OS and also popular VPN downloading sites like github.com and debian.org.
- require proof of age (ID) to unblock DNS provider IP addresses like 8.8.8.8 and 1.1.1.1 at your ISP.
- make sure children aren't using any other "privacy" tools that might be a slippery slope to installing a VPN.
This makes it so much easier for the parents too! The internet will be so safe that they won't even need to talk to their children about internet safety.
My tool collection [0] is inspired by yours, with a handful of differences. I'm only at 53 tools at the moment.
What I did differently:
Hosted on Cloudflare Pages. This gives you preview URLs for pull requests out the box. This might be possible with Github Pages but I haven't checked. I've used Vercel for similar projects in the past. Cloudflare seems to have the odd failed build that needs a kick from their dashboard.
Some tools can make use of Workers/Functions for backend processing and secrets. I try to keep these to a minimum but they're occasionally useful.
I have an AGENTS.md that's updated with a Github action to automatically pull in Claude-style Skills from the .skills directory. I blogged about this pattern and am still waiting for a standard to evolve [2].
I have a base stylesheet that I instruct agents to pull in. This gives a bit of consistency and also let's them use Tailwind, which they'd seem to love.
Perhaps. Though if that were feasible, I'd expect it would have been exploited already.
I think this is more about the cost and time saving of being able to use cheaper models. Sub-agents are effectively the same as parallelization and temporary context compaction. (The same as with human teams, delegation and organisational structures.)
We're starting to see benchmarks include stats of low/medium/high reasoning effort and how newer models can match or beat older ones with fewer reasoning tokens. What would be interesting is seeing more benchmarks for different sub-agent reasoning combinations too. Eg does Claude perform better when Opus can use 10,000 tokens of Sonnet or 100,000 tokens of Haiku? What's the best agent response you can get for $1?
Where I think we might see gains in _some_ types of tasks is with vast quantities of tiny models. I.e many LLMs that are under 4B parameters used as sub-agents. I wonder what GPT-5.1 Pro would be like if it could orchestrate 1000 drone-like workers.
The Claude Opus 4.5 system card [0] is much more revealing than the marketing blog post. It's a 150 page PDF, with all sorts of info, not just the usual benchmarks.
There's a big section on deception. One example is Opus is fed news about Anthropic's safety team being disbanded but then hides that info from the user.
The risks are a bit scary, especially around CBRNs. Opus is still only ASL-3 (systems that substantially increase the risk of catastrophic misuse) and not quite at ASL-4 (uplifting a second-tier state-level bioweapons programme to the sophistication and success of a first-tier one), so I think we're fine...
I've never written a blog post about a model release before but decided to this time [1]. The system card has quite a few surprises, so I've highlighted some bits that stood out to me (and Claude, ChatGPT and Gemini).
Two years ago I wrote an agent in 25 lines of PHP [0]. It was surprisingly effective, even back then before tool calling was a thing and you had to coax the LLM into returning structured output. I think it even worked with GPT-3.5 for trivial things.
In my mind LLMs are just UNIX strong manipulation tools like `sed` or `awk`: you give them an input and command and they give you an output. This is especially true if you use something like `llm` [1].
It then seems logical that you can compose calls to LLMs, loop and branch and combine them with other functions.
> BASIC is accessible for free to all users of Innate robots for 300 cumulative hours - and probably more if you ask us.
Is BASIC used just to create the behaviours or to run them too? It sounds like this is an API you host that turns a behaviour like "pick up socks" into ROS2 motor commands for the robot. Are you open sourcing this too, so anyone can run the (presumably GPU heavy) backend?
Does the robot needs an internet connection to work?
Also, more importantly, what does it look like with googly eyes stuck on?
5 interesting things that are worth making explicit:
1. These teams/roles are as much about appetite and attitude, as they are about someone's skills and capabilities. Some people just aren't comfortable or happy when operating in these environments.
2. Innovation isn't just at the early "0 to 1" stages. Townspeople need to innovate to scale from a million users to a billion.
3. Successful orgs have teams at all stages, working together. Each team evolves what the previous stage built. And cowboys / pioneers are only successful if they can build on industrialised components.
5. As a product evolves, it moves through the stages. Teams either need to let go, or change their way of working.
[0] https://blog.gardeviance.org/2015/03/on-pioneers-settlers-to...