I don't think Jensen without Nvidia would be better, but he's uniquely suited to fund a company, raise an enormous amount of capital, jumpstart contracts and partnerships, utilize connections at the highest levels of the global economy, and attract talent across all levels of a new company. Very few people, if any, have the foundations to do this.
It's funny to read AI-generated documentation that is the result of a prompt instructing the LLM to be as terse and straightforward as reasonably possible. The agent was probably told to conform to ASD-STE100.
It's better than a lot of AI-generated documentation, but it also comes across as a gruff LLM that it is annoyed that it has to write the documentation at all.
I go truck camping and do a lot of day trips to places where there probably will never be traditional cell phone service. I was against taking a starlink out for a while, but on a couple of weeklong trips over the last couple of years I started to dread my phone coming back online as I was driving out of the woods and all the attendant notificiations. For better or worse I would rather get online and go through all my texts and any emergency work stuff once a day than have to sift through 7 days of catching up on context. It's easy to say "just don't catch up" but it's difficult in practice.
I spend enough time in these places that I'm happy with the balance. I don't run the dish mounted all the time. I don't go out to watch movies, though that could be nice when you are north of the 45th in winter and nights feel like they are 16 hours long. Also it's nice if you forgot to check if your offline maps are still downloaded.
You need to take care of yourself and learn to switch off man. It's quite liberating to tell your colleagues "my laptop is going in the closet for 2 weeks and I'm uninstalling teams from my phone." If my team cannot survive without me for a week, then we have a huge problem.
To clarify, I have never pulled the starlink + laptop out to address anything and I would never bring a laptop on, say, a canoe camping trip with the starlink. Some light guidance here and there via the phone. I'm pretty happy with the arrangement.
These days with AI it's a lot easier to come back after missing several days. It can often do a good job distilling things, especially if it already knows the kinds of things you'll really care to hone in on and prioritize.
Not even just mentions in a chat platform, but all the chat history I've missed out on. All the emails I've missed. All the meeting notes for the meetings I didn't attend. Read it all. Give the agent(s) what kinds of things you're likely to be interested in knowing about, if a certain project you were working on got mentioned or if they made progress on some problem.
Add to that, I take my work laptop when out on trips, not to work. But if I get stuck I don't need to call in sick and can still get something done if I need to wait out a snowstorm or road closure.
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.
reply