I still review PRs, but rarely suggest changes. The most meaningful reviews come from our review bots. I mostly review broad architectural decisions as a way to keep abreast of changes in the codebase. There's a cohort of engineers I work with who I would be perfectly okay with letting the clankers review, approve, and merge their PRs. But there's a larger cohort of engineers who need what I would call a directional code review.
Couldn't agree more. MCP is just Tool Use and the terminal agents all have embedded tool uses like WebSearch, Bash, Grep, etc and those are just MCP by another name. CLI's called by a model are just Bash Tool usage calls. Bash tool is just the most open ended broad MCP you can expose and what you gain is less context bloat (no specialized tool descriptions, just Bash) and what you lose is control over the agent -- until you setup a rigorous set of governing permissions on the Bash Tool.
I have a fleet of sandboxed Claude Code instances running and they share files with each other. The files are stored on AWS but they don't have access to AWS at all -- they can't see the access keys. In fact they don't know the files are on AWS. Instead they have a set of MCP tools for listing/uploading/downloading from an internal, virtual filesystem with a special URI handler (ie agentfiles://somefile.json) and the outer orchestrator of the Claude Code instances takes the MCP requests and does the actual file manipulation on Claude's behalf. The LLM seems to adapt quite well to this strange, arbitrary filesystem and I get to keep these agents fully compartmentalized. And I have tool request logs and logs in the outer orchestrator for full auditing of the agents. MCP is a really natural fit for this kind of stuff.
The spec describes Resources, Prompts, Tools, and Elicitation.
In practice, I believe Tools represent 95%+ of what people actually use MCP for. I've not seen an MCP with Resources or Prompts that seems to have widespread use of those features, and I don't think I've ever seen anything implement Elicitation.
> what you gain is less context bloat (no specialized tool descriptions, just Bash)
Couldn't they train the understanding of a specific tool set directly into the model instead of needing it to be in context? Like isn't that basically what happens now with the Bash tool?
Is there a reason we need to rely on such a high level of access for something that should really only ever be cleaning up the project directory, hitting the 'Run Test' button and authoring some Git commits?
Perhaps a little out of date now, but I found claude was better (trained?) with the gh command line than with the github mcp. For a $corp internal tool ... I don't really see how and LLM would be able to be trained on it.
Google already has gVisor running in Kubernetes as a product (GKE Sandbox), which provides the security guarantees necessary for secure sandboxes (regular k8s isn't great in this respect). They also have pod snapshots running at scale (which run on gVisor), so you can spin up process(es) and snapshot the memory and fs of a pod at a point in time, ship it to a blob in GCS, and then rehydrate those snapshots very quickly (or fork into new instances), which allows for the fast/cheap startup and suspend times and the instant scaling they advertise here. One of these snapshots can be created in one cluster and spun up in another.
Not sure if this is an extension of tech they already have had in their systems, but I've experimenting with it to build my own orchestrator and it's been a pretty neat set of tools and abstractions so far.
Yeah, I wanted a Matrox so bad at that time because you could also do dual monitor on some of those cards. I had a sick NEC with a degauss button and trinitron style horizontal lines and a shit packard bell monitor. I wanted to do dual monitors so bad with both, despite the resolution asymmetry. Some matrox also had connection points for antennas and video capture. They were truly workhorse cards. But they sucked at 3D and were lapped in the Boot mag benchmarks for Quake 3D et al. I ended up with a 3D Labs Permidia 3D card anyway because I couldn't afford a Diamond or Voodoo and ended up turning textures off fully on Quake 3d in the end. Fun times, shout out Hard OCP.
I had dual Trinitrons around that era, to this day when I build myself a new computer desk I massively over build it (the latest one I can stand in the middle without noticeable flex..) because I lived in slight dread that the spacetime warping monitors would crush the one I had at the time.
I remember people I knew wanting the Matrox because it was possible to have duel screen on Linux. They usually had a huge grin on LAN parties, once they got their breath back from carrying two heavy CRT monitors and a PC tower. Good times.
Maybe I misunderstood something at the time, but the mga X11 driver was weird. My understanding, at least at the time, is that it is/was possible to provide an X11 driver that would work regardless of the underlying operating system, providing features such as dual-head support.
This feels intuitively wrong to me now and I doubt that's how it worked. In any case I dutifully copies the Matrox provided X11 driver to OpenBSD and enjoyed multi-monitor support.
Looking at a few old mailinglists agrees with you. Apparently the mga_drv and mga_hal_drv could just be copied to any system running XFree86, at least Linux and the BSDs, and would let you utilize dual-head support.
I have one of their dry food ones and no longer need it. Sad story, but it happens.
My cat scarfed and barfed periodically, and I always wanted the Petlibro (the simple one) to slow feed by incrementally turning the auger, just to see if it helped. I might dig it out and try my hand at this.
I put it in a hook, and Claude basically re-evaluates every changed comment that it makes against a prompt in the hook. This burns tokens, but my company pays for it, so I don't care.
Sure, but there is nothing in the world of the last 30-40 years that can compare to GLP-1s in terms of helping people consume fewer calories. This is a very coarse statement, but I'm confident in making it: there is nothing healthier than being skinny, and GLP-1s make people skinny in a way that is unique in modernity. Our modern food systems are optimized to encourage people to consume as many calories as they can, and GLP-1s are bulwarks against this system, if you will.
Being fit is healthier. Studies support the idea that being overweight but physically active is cardiovascularly healthier than being skinny(GLP-1 or not) and sedentary.
People are so worked up online in places like Reddit and YouTube comments about how there aren't small trucks anymore. It feels almost like a strange mania. So it makes sense that someone like this would come along and capitalize on that (and probably never produce anything). People will throw $25 at a company without intention to actually purchase the truck, just because they feel some weird memetic vibe to support a small truck movement or whatever.
There is a lot of truth here. Especially the part about capitalizing on the interest without ever producing a vehicle. This is something that I have considered when looking at Slate, Rivian, and other interesting vehicle concepts. Those two did end up with production vehicles. Others were a lot more vaporware.
It feels great and sad at the same time that automakers have lost touch with their customers and no longer produce vehicles that the average consumer would buy and use.
Ford, with the Bronco, took years to commit to resurrecting the nameplate. In the process, they gathered so much critical information from Bronco drivers and other 4WD enthusiasts that they were able to condense their configurations to match the options that buyers were requesting and to offer factory installs of and warranties for components that buyers usually had to buy from aftermarket sources. They did everything right and even though there are hiccups with the vehicles, some due to pandemic parts shortages, others due to similar quality issues, they have a bonafide hit. It is hard to go anywhere around me in NTexas without seeing multiple Broncos and Bronco Sports.
If this guy at REO is smart and committed to the process he will scour forums for configuration information for his vehicles so that he can select components that buyers prefer. He can work on styling once he hires someone with CAD experience.
These are called EREVs in China and are fairly popular. Ford has a patent for one in trucks but never built it. It makes a ton of sense. Use the generator to get extended range, but avoid all the moving parts of a driveline.
Stellantis almost built one, I think the Ramcharger?
A couple other companies tried EREVs but AFAIR one was suboptimal (Mazda had one but the motor was so small it was dangerous to use for uphill) and the other was in an expensive German thing.
Where it is challenging is that, AFAIK, a direct driveline (i.e. Honda's system) or close to (THS used by Toyota/Ford/Subaru/others), it is easier to hit a higher Gas-only MPG rating than with an EREV due to the conversion losses on each end.
And, If you compare a BYD Seal 5 DM-i to the Current Prius Prime, AFAIK if you compare euro WLTP numbers the Prime gets better MPG when it switches to gas, and has a competitive electric only range. The Seal 5 DM-I is a little bigger but close enough. The BYD certainly wins on 'price' however it is unclear how much of that is due to a truly simpler design versus labor/material input cost.
reply