It would have made far more sense, for reliability, efficiency, cost, etc., every metric really, to use or write a source to source translator that preserves as much structure from the original code as possible. Typically if you do a rewrite there are lessons learned from the existing code base that you want to take into account when doing the rewrite; using a bunch of agents to do the porting file-by-file buys you none of that. In either case the code will be an unidiomatic translation, just with LLMs you get an added source of indeterminism and a huge bill at the end of the month.

I think it is inevitable that more capable models will require export controls, KYC, background checks, verification of credentials, etc. Even if you don’t buy Anthropic’s marketing of their current models, there is a future where models are capable of developing chemical weapons, biological weapons, cyber weapons, etc. which are genuine security threats governments will care about controlling and preventing. Maybe this prevents big commercial labs from developing more capable models until they figure out appropriate safeguards, but this is a good thing, a world where you can ask an LLM for an airborne rabies genome and it will simply produce it for you is not a world we should want to live in.

I always thought it was confusing to design a circuit mentally (or on paper) out of things like muxes, encoders, flip flops, etc. and not have language-level elements to represent these things (without defining your own components obviously).

I remember looking this up, and I believe it’s because the languages were originally designed for simulation and verification, and there are things you might want to do in a simulation/verification language for testing that are outside of what the hardware can do. Mixing the two is confusing IMO, but clearly demarcating the hardware-realizable subset of the language would be better than the current state.