I still review PRs, all of which are written by agents. I almost never have meaningful feedback to offer unless it's feedback on the architectural approach. And even then, a lot of architectural/coding patterns that I've been a stickler for in the past mean less to me now because those patterns served to create maintainable code for human beings, which just isn't a priority anymore.
At our company (big Rails/React monolith) all PRs do get a human review. Now, I use LLMs to accelerate my reviews, but there's still a lot of space for humans.
- LLMs struggle, or at least burn oodles of tokens, on big complex codebases. Managing tech debt helps the agents as well IMO.
- If you ask an LLM to review a non-trivial pull request, it nearly always seems to find at least 10 issues. Many of which are not worth pursuing. Often, they would introduce a lot of extra complexity to harden the code against scenarios we don't care about or can never happen. So there's a lot of room for human judgement there. Typical scenario - the LLM reviewer finds 10 issues and I judge that 2-3 are worth pursuing
- As you said, often the architectural approach sucks even with frontier LLMs. Usually from a lack of problem space / usage scenarios more than a lack of technical chops
- LLMs tend to err on the side of overengineering the shit out of everything
I do not see how LLMs will be able to manage huge, hairy polygot codebases without humans-in-the-loop in the near future.
Given the pace of progress, I'd be a fool to bet against LLMs in the medium term future. But I think it's far from a given. LLMs themselves, and large codebases, are essentially many-to-many problems approaching something like O(n^n).
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.
reply