The reason for this is pretty clear; where we used to have a lot of time to ensure we were building the right thing, the reduced build time of the world we now live in means, for better or worse, there is a lot more pressure on getting things into the funnel.

The other component at play is that everyone is now managing a team of agents, and the amount of output reflects this, which is the exact cause of, for lack of a better phrase, "misunderstanding amplification".

Something I've been thinking a lot about is how we effectively bring the context of contributors to the same place, and how agents and the cross-functional drivers of those agents work together. Another piece of this puzzle that I think will remain relevant for some time to come is local agent execution. It's fast, convenient and far cheaper than current cloud offerings.

With these things in mind I've been building Braid. Braid allows realtime collaboration while sparring product decisions, proposing designs and ultimately build plans. The execution model is a self-hosted server that allows teams to enrol their client applications (with a pairing key), and is responsible for holding shared state and keeping all participants contexts up to date with what their colleagues are currently working on. Take it for a spin! I'd love the feedback.

I'm not sure if the shape of the solution is right for all teams and the varying challenges they face; I am sure however that as companies and organizations move further down the agentic path, we'll need solid solutions ensuring everyone shares the right context and can interface with their systems and the work of their colleagues seemlessly.

I am currently very into building small, interesting (I think so anyway) projects that replace deeply engrained SaaS products. Not necessarily because I expect to use them as my daily driver, but just to prove that it's possible. Openhub is current example of this. Sick of Github, want control over your git server? Openhub might just be for you.

But the question is, how do you realistically make these types of things available on the internet. You don't want to pay for the reoccuring cost of an EC2, and cloud servers represent the very thing we are enjoying breaking away from.

My setup is simple, and has an uptime of >99.9%, although your milleage will vary.

1. Have a Raspberry Pi running on your home network (I had one running as a Plex media server anyway)
2. Use Cloudflare for your domain nameservers and configure tunneling so that you can use cloudflared to tunnel web traffic onto your Pi without exposing it or any of your network ports to the scary internet.
3. Deploy your services with systemd and register them with your tunnel.

What are the risks? Most obviously remote execution vulnerabilities on your Pi that could then expand to your network as a whole. IMO this is pretty unlikely and not a reason to not have fun deploying whatever you want to make the internet fun again.

I have a few things running from my Pi today:

• this site
• My openhub instance
• My Braid API