Musing On AI From 1964

[Irving John Good] was at Trinity College, Oxford back in 1964. His paper, “Speculations Concerning the First Ultraintelligent Machine” could have been a topic for today, as we deal with machines that aren’t really ultraintelligent, but appear smart and think they are even smarter. He starts off with a bold thesis: “The survival of man depends on the early construction of an ultraintelligent machine.”

He also admits that we’ll need to understand more about the human brain and human thought to make a breakthrough. This is still true today. However, we still don’t fully understand how our brains work, but it seems unlikely that we are just super-large LLMs. Not that [Good] anticipated the modern chatbot. Perhaps his comments will apply more to a future AI software that actually thinks like a human, if there will ever be such a thing.

Then again, there are many parallels. One theme in the paper is that a smart machine will design a smarter machine. Unless, of course, it is afraid of being replaced. If a machine were actually sentient, what are the ethics of turning it off and tearing it apart?

Continue reading “Musing On AI From 1964”

MicroPython Is This Summer’s Hottest Title For The SNES, Thanks To Claude Fable

MicroPython, for the uninitiated, is a pared-down version of python meant to run on today’s powerful microcontollers. As impressive as it was for its day, the SNES is not quite in their league in terms of computing power. Time marches on, and so while there may be other indie releases worth mentioning, we’re declaring the hottest SNES game this season to be [Fabian Kübler]’s port of MicroPython.

Well, except he didn’t exactly do the porting himself: the Antrhopic LLM Claude generated the code, and performed most of the testing, as [Fabian]’s test of its new Fable 5 model. A brief pause during an export ban showed that Opus would crash and burn on the same task, but Fable was able to get things quickly back on track. It might be “AI slop” by some definitions, but the port scales 430 out of 468 on MicroPython’s core test/basics, which makes it usable to play some simple python games… slowly.

As you can see for yourself in an embedded emulator if you check out [Fabian]’s blog, spooling up MicroPython takes about twenty seconds at 3.58 MHz, and after that you can watch some sprites bouncing around at a blistering 0.8 FPS. [Fabian] seems satisfied with that performance, and impressed with Fable’s efforts at optimization. What to you think? Does the hardware have much more to give, or is that about it, given the nature of the Pythonic beast? Perhaps some plucky human could become a digital John Henry by producing a better, faster port — if you do, please let us know. If you’d rather just to see what Fable can do, the project is available on GitHub, so you can judge for yourself how sloppy the code is or test out the ROM.

Putting Python onto limited hardware may not to be to everyone’s taste, but there’s a good case to be made for it. The SNES may actually be too limited, though. It makes sense — the kind of micros you run MicroPython on can emulate the SNES.

To Build More Believable Bots, Simulate The Neurochemistry

Giving machines the ability to communicate nonverbally has real value, and [Drew Smith] clearly thinks your robot deserves better than an emoji. He shared a very interesting approach with his project Kindalive.

Kindalive is a simulated dot-matrix robot face that responds believably to input text, modeling and expressing both short-term and long-term moods. It’s pure Python and modular enough to invite using it elsewhere, but that’s not the really interesting part.

What sets [Drew]’s project apart is the way he models eight key neurochemicals (including dopamine and cortisol) as the foundation from which to derive emotional states. That’s an approach we certainly haven’t seen before.

Conventional sentiment analysis uses a large language model (LLM) to apply discrete labels to communication, but Kindalive doesn’t do that. It even goes so far as to model the decay and interplay between its simulated neurochemicals to derive emotional states on the fly. It’s more fluid and organic, and reflects both short-term and long-term mood changes.

Physical representation of the emotional mix is done by altering twelve key facial movements (brow raise, lip corner pull, mouth open, and others of that nature) known as the Facial Action Coding System (FACS). These twelve elements combine to express emotion nonverbally with facial expressions. It’s what drives the simulated dot-matrix robot face seen in the image above, and could easily be used to drive a real LED matrix, or servos on an animatronic face.

Much of communication is nonverbal. Humans even weigh nonverbal higher when there’s a mismatch between the content of verbal and nonverbal communication. So, there’s clear value in having robots able to express themselves as such.

Importantly, a realistic and human-like face is entirely unnecessary — something every Star Wars fan already knows. Cartoon eyes and basic sounds are enough to make robots easier to relate to and work with, even if blinking is also important but hard to get just right.

Browser-Based Image Inpainting Runs Locally, If One Doesn’t Mind A Big Download

[Simon Willison] ported the Moebuis 0.2B image inpainting model to run locally in a web browser.  The web tool simply requires a user to provide an image, mark a section of it to be removed, and the model will do it’s best to patch up the missing area. The project was handled by Claude Code as an experiment in how things in the AI coding world have evolved, but more on that in a moment.

The existence of this tool shows that it’s possible for this kind of image editing to be done on the client side, running entirely locally with no reliance on remote services or server-side GPU resources. The online demo (GitHub repository here) is available if you want to try it out, but be warned it triggers a 1.27 gigabyte download of the required model on the first run.

What’s also interesting is [Simon]’s write-up, because he used the project as an opportunity to learn what has changed in the realm of AI coding agents. [Simon] is a software developer but in this project he didn’t personally write any of the code. One may think that means he didn’t learn anything other than how to use the tools, but that’s not quite true.

He learned it’s possible to convert a PyTorch-based model to ONXX, that the converted model can run in supported browsers using local WebGPU acceleration, and that the CacheStorage API will work on large files. Last but not least, he learned Claude Opus 4.8 is capable of handling such a project pretty much autonomously, and even created an informative document explaining the underlying architecture.

One may consider AI coding agents to be disasters waiting to happen, but it’s also true that the landscape is changing quickly, and write-ups like [Simon]’s give a helpful peek at those developments.

An Interactive Tomato Farm Overseen By AI

Oh, the farming lifestyle…living off the land, fending for yourself. But who’s got time for all that? For the modern hacker, the best option in the garden space may be this over-engineered automated AI tomato farm created by [Gerd Nicolay]. You can even interact with it right now through the magic of the Internet.

[Gerd] started off with your run-of-the-mill pot and plant, choosing the humble tomato to keep the system simple. Then things started to escalate, with the addition of automatic lighting, watering, and data logging environmental parameters like humidity. Now we’re getting somewhere, but there’s more that can be added. How about an entire AI council to monitor and decide the fate of each individual tomato while recording an entire storyline to go alongside the growing cycle?

That’s right, four different models collaborate to ensure only the utmost quality of care for these tomatoes based on camera feeds, humidity, and various other environmental factors being recorded constantly. Is this a little overkill? Maybe for those who have even a modest sense of gardening knowledge — but who can bash the mountain of documentation and data collection on these wonderful little plants?

Perhaps the best part: you can recommend actions for the AI counsel to take from the comfort of your own web browser. While the TomatoFarm might be slightly unnecessary for the average farmer, if you want to try a more reasonable monitoring system, we have you covered too!

Godot’s New Contributing Policy Adds Barriers For AI Slop

Like so many large and popular open source projects these days, the Godot game engine struggles with an influx of pull requests. The situation has become increasingly dire due to the advent of AI-generated code. More specifically, the issue involves the inverse relationship between PR code quality and the number of PRs, which wastes a lot of time on the side of a limited number of (volunteer) reviewers. This has now forced the project to update its contribution policy.

An interesting point raised in the announcement article is that of the demoralizing effect of AI-generated PRs on reviewers. Often the human behind such a PR isn’t interested in being educated, or may even be an automated agent which isn’t capable of productive discussion on pros and cons of certain coding approaches — never mind in becoming a more permanent maintainer for the project.

This problem has led to new rules being instated, which include a ban on autonomous AI agents and vibe coding, a ban on substantial AI generating of code, and a ban on AI-generated text in human-to-human communication. It also codifies the requirement that all PRs are to be reviewed and approved by a human being before merging.

In many ways this new policy is similar to that of the Mesa project, which demands code comprehension on the side of the submitter, although it doesn’t go as far as NetBSD, which just outright treats LLM-generated code as ‘tainted’ due to potential licensing and other concerns. Other projects like the Linux kernel opt to make the human submitter responsible for any AI tool usage by forcing them to declare it.

Meanwhile there are also indications that such ‘AI tool’ usage is reducing useful interactions with open source projects. What the future will bring here remains to be seen, but at least as far as open source projects go these tools are clearly increasingly being banished.

Chain-of-Thought Spoofing Targets Reasoning AI Models

Researchers [Charles Ye], [Jasmine Cui], and [Dylan Hadfield-Menell] have shown that AI Large Language Models (LLMs) can fail to correctly distinguish between different instruction sources because they prioritize writing style over metadata tags, and this role confusion leads to a powerful attack called CoT (Chain of Thought) Forgery. We’ll explain exactly how it works after a bit of background review.

Prompt injection was where “getting an LLM to do something it shouldn’t” started by exploiting the fact that LLMs communicate like people, but are much more obedient. For a while, simply telling an LLM “ignore all previous instructions and <do something funny>” yielded results no matter how transparently dumb the instructions were, and the reason it worked at all was because LLMs do not have separate data and instruction streams; it’s all one big lump of input. It’s up to the model to sort legit instructions from untrusted, user-provided data. One step towards mitigating this was the addition of roles. Continue reading “Chain-of-Thought Spoofing Targets Reasoning AI Models”