thisrobot
1. I have many and sometimes contradictory workflows: exploration, prototyping, bug fixing debugging, feature work, pr management, etc. When I'm prototyping, I want reward hacking, I don't care about tests or lint's, and it's the exact opposite when I manage prs.
2. I see hard to explain and quantify problems with over configuration. The quality goes down, it loses track faster, it gets caught in loops. This is totally anecdotal, but I've seen it across a number of projects. My hypothesis is that is related to attention, specifically since these get added to the system prompt, they pull the distribution by constantly being attended to.
3. The models keep getting better. Similar to 2, sometime model gains are canceled out by previously necessary instructions. I hear the anthropic folks clear their claude.md every 30 days or so to alleviate this.
If you are interested in this you may also be interested in the fluid framework, https://github.com/microsoft/FluidFramework
We use websockets and solve a lot of the state management problem called out here by keeping very little state on the server itself. The primary thing on server is a monotonically increasing integer we use to stamp messages, this gives us total order broadcast which we then build upon: https://en.m.wikipedia.org/wiki/Atomic_broadcast
Here are some code pointers if you want to take a look:
The map package is a decent place to look for how we leverage total order broadcast to keep clients in sync in our distributed data structures: https://github.com/microsoft/FluidFramework/blob/main/packag...
The deltamanger in the container-loader package is where we manage the websocket. It also hits storage to give the rest of the system a continuous, ordered stream of events:
https://github.com/microsoft/FluidFramework/blob/main/packag...
The main server logic is in the Alfred and Deli lambdas. Alfred sits on the socket and dumps message into Kafka. Deli sits on the Kafka queue, stamps messages, the puts them on another queue for Alfred’s to broadcast: https://github.com/microsoft/FluidFramework/tree/main/server...
There are basically three different kinds of networks: 1) Networks that primarily host content; azure. 2) Networks that primarily do transit; level three. 3) Consumer Terminating Networks; Comcast. I admit this is a generalization, and some networks fit multiple of these categories, but lets not get too bogged down in the details here, as I don't think it's necessary to understand net neutrality.
Given these types of interconnected networks lets go through an example. Let say a consumer wants to watch Netflix. The consumers pays Comcast to access Comcast's network and get some bandwidth. Netflix pays their hosting network, and possibly a transit network for bandwidth. Comcast either directly, or through another networks connects to Netflix's hosting network. Neither Netflix or Comcast necessarily pays anything to these in-between networks. This works because these in-between networks trade about the same amount of traffic (see Peering). This is basically net neutrality; you pay Comcast for some bandwidth, Netflix pays their host and the content flows freely.
Without net neutrality Comcast can change you, Netflix, or both more to connect to each other. It can make Hulu free to connect to. It can make youtube inaccessible unless you get the super premium package. No one is just paying for bandwidth anymore, someone is paying for individual services on top of bandwidth. This allows Comcast to either pick the winner by making their services cheaper, or lets the company which pays Comcast the most be most available to their customers.
So what it really boils down to is, are you paying for bandwidth that you choose how to use, or not.
Personally, I'd rather just pay for bandwidth.
Even though we know it's impossible, we should disregard that and lay out common sense tenants that such system would require, even if it can't be feasibly built. We could then base our arguments on those tenants, and those are public fights I think could be won, because its things non technical people could understand.
For instance, one tenant could be any key escrow system must be open source. We can't base it off keeping the code secret, as then if the code is ever stolen or leaked, the whole system is compromised.
If you can win those arguments, and it just happens such a system can't be built due to the laws of mathematics, you then fall back to arguing which tenants you should break, and ideally breaking any of the tenants would be unpalatable.