A compiler writes machine code do a file. The OS then loads the code from the file into executable memory before it runs the program. The compiler isn't actually trying to execute the machine code it produces. This is why a JIT wouldn't work - the JIT bypasses the interpreter and produces machine code _that executes directly on the CPU_ inside of the same app.
I don't know any details about Python's architecture, but it's totally possible to write an interpreter for machine code; that's basically what an emulator is. The trade off is that pure interpreters tend to be very slow.
Yes, and that's my doubt. Compiling is turning data (text) into code (something executed by the CPU). I thought the point of the hardware is that data can't become code. If data can become code, then data is code, and it doesn't matter if the data is compiled first or interpreted at runtime. There doesn't seem to be a way to prevent "data" from becoming "code".
Most likely pretty bad. It's not all that difficult to sweet talk Fable into doing a security review of a code base. I've pointed it at a few of the major open source projects in the main tech stack I work with and it found dozens of bugs in each. Many were fairly minor, and some of the more significant issues relied on fairly narrow attack vectors (for example, a compromised DB server being used to attack a web server). But this was just a single search pass, literally a few lines of prompt and an hour's worth of agent time.
You're looking for Young's penetration equations, developed at Sandia National Lab in the 90s. Your favorite LLM can walk through the math step by step if you're interested, but a US WW2 era AN-M64 500 lb bomb gives results of 15-20 ft penetration in average soil. Reality might be a little less because free-falling bombs have forward velocity from the aircraft that dropped them, so they hit at angle instead of penetrating straight down.
If you need to review every edit that claude wants to make what's the point in using it? We're now treating it basically like a junior dev. Do our best to make sure that it's on the right path (leaning hard on the superpowers plugin) then let it work and look at the result. Though even that review is heavily AI assisted now. Our leadership has mandated that everything that can be done by AI, should be done by AI. We've only been in that mode for a couple of months but I'm starting to think that it's plausible with proper human steering and oversight.
I'm not being flippant. If I need to sit and watch a claude session reviewing every edit it makes, that's slower than me coding the changes by hand. Either it's good enough to work independently or it's not worth using. I have no idea how Google is using AI, but from what I've seen at my own company I do know that using AI effectively _and_ setting up repos/projects for good AI usage (and with guardrails to keep AI in check) are both acquired skills. Skills that the majority of devs don't have right now.
Really the single biggest piece I use today is using a tool like superpowers to ensure your task is well defined. Added bonuses are its TDD implementation skills and multiple review steps baked into the workflow. Before I discovered superpowers I was manually telling claude to do these workflows, the plugin makes it easy.
In the repo itself:
* Keep agents.md focused; claude likes to really bloat it by default. The "Adding guidance for AI agents" rules go into every project and have worked pretty well.
* Aggressively use nested agents.md files. Focused rules located where they're relevant seem to do much better than having a large whole-project rule dump in the root agents.md.
* Recently I've started using the tech debt and deferred work documentation rules. Claude frequently decides on its own that some piece of functionality or issue is "deferred until later" or "out of scope". These rules help make it clear so that you can make it fix the item or at least have it documented for a followup session.
* Have it test all the things. Most of my personal projects with claude have about a 3:1 ratio of test:application code and high coverage. Claude make it easy to build test harnesses for things that most of us wouldn't have bothered with 5 years ago.
* Strict type checking, linting, static analysis, warnings as errors, etc. Anything you can turn on or add to block questionable code, do it.
* Use a claude pre-tool hook to run all of your checks before you allow a git commit command. Left on its own it can and will decide that it has a valid reason to bypass git commit hooks (husky) to commit broken code or tests.
There's a company based in Kentucky named Big Ass Fans that makes a lot of these. I talked to them at a job fair about 15 years ago, at least at the time they were writing a lot of software for motor controllers, etc. in house. Sounded pretty interesting.
Use the superpowers plugin. It's a game changer. You start by building out a spec defining the work you want to be done, then claude writes a detailed implementation plan. It can easily work for hours without interruption, and the process integrates testing (TDD when possible) and review steps along the way. I even did one fairly complex POC for work that had claude implementing for almost 3 days straight, with me stopping it and handing off to a new session when context hit about 800k. The process is slower and more methodical than the way claude works by default but the output is much better.
The A-12 was built in an era when the aerospace industry was flush with knowledge and active R&D into mach 3+ flight - everyone was convinced that it was the future. Today's industry is heavily optimized for subsonic airliners and fighter jets that have top speeds of "only" mach 1.5-2. No one in the west has built a mach 3 aircraft since the 60s and not in Russia since the early 80s. The knowledge isn't _lost_ (well, we hope) but there is a lot that will need to be relearned, and we all know how even the best documentation is usually missing a lot of details.
Not the Gmail app, but a Gmail account, yes. You have to at least have the default Mail app installed and signed in for it to be able to index the emails.
I don't think this will work reliably. Pretty sure it's not the LLM deciding to read the files, it's the harness in Claude Code itself injecting the instructions files based on the paths the model accesses.
Edit: sometimes if Claude lists files in a directory or does a search that shows it an AGENTS.md exists it will decide to read it. But it's not a reliable behavior.
"Space weapons" here most likely means some combination of anti-satellite weapons and electronic warfare such as GPS jammers. AFAIK it's been widely believed that the USSR/Russia has had these capabilities in orbit since the 80s. I'd be willing to bet that the US has had them for decades as well, it just hasn't been publicly acknowledged.
For some reason they did not provide any details beyond that they have kinetic and non-kinetic means. Kinetik indeed can mean just ability to blow up satellites but IMHO it is good enough to trigger an arms race.
The arms race was always happening. Russia put a weapon on a space asset decades ago, basically for shits and giggles, but was recently practicing a space asset maneuvering and deploying a smaller asset, and there's very little justification for such a system other than "Attack another satellite", especially since no public cover has been offered.
Both Russia and China have demonstrated anti-satellite weapons. Ages ago.
Space being not militarized was always a fiction. Space was militarized first and foremost, and everything NASA ever did was to encourage and help that goal. This has only gotten dramatically less symbolic and more actually meaningful since recent massive advances in space sensor platforms and scale.
This is only a change in public messaging unfortunately.
This was always the inevitable outcome, because there's no "Bigger fish" to make independent nations follow any rule other than the rule of the jungle, and space is the highest ground.
I don't know any details about Python's architecture, but it's totally possible to write an interpreter for machine code; that's basically what an emulator is. The trade off is that pure interpreters tend to be very slow.
reply