roberttod

Does this work with remote agents though? I want my claude.ai agents running on my phone to be able to hit my local MCPs on my Mac Mini - my understanding is that tailscale wouldn't work because the execution is being called remotely. But seems like these tunnels would support that.

I created my own version with an inner llm, and outer orchestration layer for permissions. I don't think the OTP is needed here? The outer layer will ping me on signal when a tool call needs a permission, and an llm running in that outer layer looks at the trail up to that point to help me catch anything strange. I can then give permission once/ for a time limit/ forever on future tool calls.

Mostly, it's not the model that is lacking but the visibility it has. Often the top level business context for a problem is out of reach, spread across slack, email, internal knowledge and meetings.

Once I digest some of this and give it to Claude, it's mostly smooth sailing but then the context window becomes the problem. Compactions during implementation remove a lot of important info. There should really be a Claude monitoring top level context and passing work to agents. I'm currently figuring out how to orchastrate that nicely with Claude Code MD files.

With respect to architecture, it generally makes sound decisions but I want to tweak it, often trading off simplicity vs. security and scale. These decisions seem very subtle and likely include some personal preferences I haven't written anywhere.

It's unintuitive, but having an llm verification loop like a code reviewer works impeccably well, you can even create dedicated agents to check for specific problem areas like poor error handling.

This isn't about anthropomorphism, it's context engineering. By breaking things into more agents, you get more focused context windows.

I believe gas town has some review process built in, but my comment is more to address the idea that it's all slop.

As an aside, Opus 4.5 is the first model I used that most of the time doesn't produce much slop, in case you haven't tried it. Still produces some slop, but not much human required for building things (it's mostly higher level and architectural things they need guidance on).

I remember such a project, and due to our large and aging TypeScript frontend projects it would have added a couple of weeks to adjust all the types affected. All IDs in many places deep in code caused thousands of errors from the mismatch which was a nightmare. I can't remember exactly why it was so tough to go through them all, but we were under intense time pressure.

To speed things up we decided to correct the ID types for the server response, which was key since they were generated from protobuf. But we kept everything using number type IDs everywhere else, even though they would actually be strings, which would not cause many issues because there ain't much reason to be doing numeric operations on an ID, except the odd sort function.

I remember the smirk on my face when I suggested it to my colleague and at the time we knew it was what made sense. It must have been one of the dumbest solutions I've ever thought of, but it allowed us to switch the type eventually to string as we changed code, instead of converting the entire repos at once. Such a Javascript memory that one :)

I need to look into this a little more, but can anyone tell me if this could be used to bundle a Linux container into a MacOS app? I can think of a couple of places that might be useful, for example giving a GPT access to a Linux environment without it having access to run root CLI commands.

As much as I agree with the sentiment, I can buy a firestick, Apple TV or Roku for a very small cost. Sure, a dumb TV would be lovely, but only because of a quicker boot time.

Given a dumb TV is going to be more expensive, I can't see a market for it based on a small marginal gain for the consumer. And 90% of people don't even care enough about the poor user experience vs the marketing that hypes up features no one uses or needs.

I wasn't sure what an "interlock" was, and it's a breathalyzer that prevents the vehicle from starting. Was that a mistake?

Edit: ah! I think you meant engine immobilizer

Do these providers really bring enough value to use them over a colocated managed db? (Not just the same region, but subnet etc)

I was under the impression for quite some time that it wasn't that bad to have 2-3ms latencies compared to a co-located DB which is typically <1ms. However, we recently switched from Neon to a colocated, managed db and there was a huge improvement. Some of our queries were executing sequentially (due to our ORM, Prisma), and so what was a 3 second transaction was reduced to only 1 second. Yes this could be rearchitected better, but it illustrates a major floor in my mind for these companies providing only a DB.

Managed vs. unmanaged is a massive difference and would be worth it. But these days I was under the impression most hosting companies also offer managed DBs.

Thanks for mentioning this. I did a bit of reading about the special alignment - very interesting stuff!

It seems like the alignment you refer to inspired the launch of Voyager 1 and 2 because they could visit so many planets at one time, and indeed it did slingshot them at quite some speed. However newer launches have reached similar speeds, and will escape the solar system due to improvements in launch technology.