Sometimes we will have a huge stack of changes one of us is "finished but not clear to merge".
either:
- We just swap ownership of the branches and eng 2 now commits directly in branch 1. We review the final content together and typically pull in a 3rd person to review our combined work. Eng 1 either pairs with eng 2 until its finished or starts on a task that is decoupled from those changes.
- We use an integration branch that gets threated like the temporary master branch until the feature is ready to merge.
MCP protocol layer is for all practical purposes an irrelevant implementation detail.
We need some new layer to handle things that used to be abstracted away by UIs
- filter to 6 of 50 fields for the paginated pipeline views
- show all the important fields on a detail view
- organize for understanding of fields that might have been poorly named in the public APIs
Some of this can be handled by a CLI wrapper around an API, but it really just shifts the complexity into a different system.
One thing that I haven't heard a lot of people talk about is that MCPs are often able to be far more flexible than a traditional REST api. You can ship breaking changes/renames and agents will adapt. Why should we couple the agent tooling locked 1-1 with our calcified systems?
I’ve been tangentially involved in experimenting with Meshtastic and trying to scale it for large events like Burning Man, on the order of 2000–3000 nodes on a single frequency.
Node to node mesh communication is cool and it works surprisingly well at small scale, but the moment we brought high powered repeaters online the difference was night and day. Coverage, reliability, and usability all jumped instantly.
It makes the tradeoff really obvious. Mesh is great for bootstrapping and local traffic, but once you care about real data propagation at scale, centralized infrastructure wins almost every time. Airtime is scarce, coordination matters, and having a small number of well placed high sites beats thousands of mediocre relays.
I still think there’s room for novelty P2P protocols, but mostly as an optimization layer on top of infrastructure, not as the foundation. Every time you push on this problem hard enough, you end up rediscovering the client router model for a reason.
Sometimes we will have a huge stack of changes one of us is "finished but not clear to merge".
either:
- We just swap ownership of the branches and eng 2 now commits directly in branch 1. We review the final content together and typically pull in a 3rd person to review our combined work. Eng 1 either pairs with eng 2 until its finished or starts on a task that is decoupled from those changes.
- We use an integration branch that gets threated like the temporary master branch until the feature is ready to merge.