The only solution I see is some kind of hardware-linked signature showing that the image was produced at a certain time, by a certain device. In theory, you could make this signature somewhat “provable” and anchored to a specific time by combining something like 1) the latest Bitcoin block hash, and 2) a blockchain anchor, thereby proving that the photo was taken within a certain time widow after the hash was known and before the anchor was published. But even that arrangement is highly susceptible to hardware attacks.

My take is that some of your architecture decisions are fundamentally incompatible with [what I believe to be the state of] most enterprise codebases.

And that’s fine if you have a very specific client base and are focused on fellow startups.

Edit: they have another page describing Alaska. It seems that the linked page might only describe the contiguous US? But also, wow. This seems stupid:

> Thoughts of roadless Alaska came to mind and our amazing, wild trek through the Brooks Range of the Arctic National Wildlife Refuge. We hired a bush plane to drop us off in a nameless valley. At 50 miles from the nearest village or road, we were awed with excitement and healthy fear. We agreed to meet up 9 days and 35 miles later at a flat spot where he could land on the tundra marked by a heap of moose antlers. He looked at us awfully cock-eyed when we told him we had no satellite phone. He asked, “well, why not?” We told him that we were deliberately here to remove ourselves from civilization and contact with it. Watching our pilot fly away, we realized we were as far from towns and roads, and therefore, humans as we could possibly imagine.

I do like the grug-brain approach of keeping things extremely simple and easy to reason about.

One thing that I don't like about Pi is that it's almost too extensible, in the sense that I can add a lot of shit into it without really understanding what a given extension is doing. And both from a security and token efficiency standpoint, I like the premise of converting things like MCPs into CLIs. It might be worth investing in tooling that works nicely with the agent harness, but that is not directly integrated with it. I'd be glad to work on that for smol if I can get a workflow going.

I jest, but not completely. The US is more dense but more distributed too. You can’t realistically link someone in a rural West Virginia holler up to a regular bus schedule, nor can you build a train between Morgantown and Pittsburgh that gets ridership.

America doesn’t do badly at public transit in places like Florida where private companies can fill the gap and the communities are within a reasonable distance and the geography is flat and simple. See the Brightline trains for proof of concept. But it’s kind of ridiculous to imagine Australia and the US to be comparable in that way.

That conversation had a tremendous impact on me and completely changed my attitude towards meeting new people.

I am heartbroken for him and his family. And I can see that kind / heartfelt / grandfatherly nature throughout this memoriam.

And please, God, let me die with my wife like John Nash did in that NJ Turnpike taxi crash.

I have a dev box with 96 GB of RAM, 2x4 TB NVMe drives, and an unbelievably beefy AMD CPU. This box costs me less than $150 per month and is so hyperlocal that I can log into it and use it as a remote desktop, while also using it as an always-on server that I can use to run T3 code and tmux and so forth. I can then connect to it from my laptop or my phone using Tailscale and prompt using the T3 Code or Remux mobile apps. Voilà — I have my own outsourced development center.

In this setup, my agent can handle everything: previews with a NixOS environment, unlimited threading, “autofixing” (which is just a loop between my agent and Copilot review comments), etc.

But it requires a LOT of custom setup/tooling so that my local environment works with my agent.

Why am I telling you this? Well, I've tried a number of serverless or ephemeral VM-type solutions, and it turns out that once you're working on "real code," you can't use ephemeral micro VMs reliably because your code starts interacting with too many different dependent services. You have to run migrations, so that your tests run properly, and to do that, you need to pull five different Docker images, and it goes on indefinitely. Eventually, the overhead of making little micro VMs is so high that it makes much more sense to take a monolithic approach to development and have a persistent workstation. You can still use things like worktrees, which allow you to massively parallelize your work, but you're building off of a shared local drive and cache.

So I believe there's a place for something like Hoplite with simpler software, but the problem is that the minute you get beyond toy software, it becomes really hard to test, scale, and deploy everything in micro VMs. There are also other companies that have tried this approach (like https://shipyard.build, although I think they had a slightly different philosophy from what you're doing) and I don't know that they've been massively successful.

What is it that you're doing differently that will allow Hoplite to succeed? How do you think that you'll compete against the legacy players in this space and the more full-spectrum players like Devin, et al.?

I can’t decide which is more disappointing.