Anecdotal, but I have used Claude to help me write sections of games that I'm (sometimes) working on in Godot fairly recently (Opus 4.5 iirc). It's been very helpful, and it's been very easy to guide it to do this. It came up with approaches of calculating targeting and movement that I would not have thought of myself.
That being said, Claude does not structure the project in the way someone familiar with the engine would, and just like any 'real' software, if you don't guide it, the output quickly degenerates. For example, stuff that would normally, intuitively be a child item in a scene, Claude instead prefers to initialize in code for some reason. It does not seem to care about group labels, which is an extremely easy way to identify different (types of) objects that should be treated in the same way in certain cases.
The games in the video look like GameJam projects? I'm not good at Godot, and I could probably hack most of them together in a week or so. I imagine an actual game developer could put some of them together in days.
In order to have LLMs build something good with any framework, not just a game engine, you have to steer and curate the output, otherwise non-trivial projects become intractable past a certain point, and you have a mountain of bugs to sort through.
> The Training Data Scarcity: LLMs barely know GDScript.
I've not found this to be an issue. Claude does just fine when you explain what you want. I've never had it hallucinate stuff, and I've barely seen it look at docs. Granted, I've only had it write 1-2k lines of GDScript, but I've never felt like it was spouting complete nonsense.
> To fix this, I built a custom reference system: a hand-written language spec, full API docs converted from Godot's XML source, and a quirks database for engine behaviors you can't learn from docs alone.
This is the point where I feel like this is nonsense (more than what the LLM-written prose would imply). Maybe this is my inexperience talking, but I feel there is no way that this would be better in any way over any alternative. Especially if you just lazy-load stuff at runtime. Godot already has good docs. They should certainly cover much more than whatever you need to make the games you demonstrated. What is the point of making a duplicate version of the docs, when you have the docs right there? If you really think that Claude can't handle GDScript, you can just use C#?
> The Build-Time vs. Runtime State: Scenes are generated by headless scripts that build the node graph in memory and serialize it to .tscn files. This avoids the fragility of hand-editing Godot's serialization format.
Again, maybe that's my inexperience with Godot, but I have no idea what you're talking about here? When you run, you do get a different node tree (and 'state' I guess?) but where does "hand-editing Godot's serialization format" come into this? Why would you ever need to concern yourself with what Godot does to transform your code after you've written it?
> It catches the visual bugs text analysis misses: z-fighting, floating objects, physics explosions, and grid-like placements that should be organic.
Funnily enough, those are all stuff that text analysis should be better at finding. I personally use logs & actually playing the game.
Malware is very easy to build. Competent threat actors don't need to rely on open source software, and incompetent ones can buy what they use from malware authors who sell their stuff in various forums. Concerns similar to yours about 'upgrading' the capabilities of threat actors were raised when NSA made Ghidra public, yet the NSA considers the move itself to have been good (https://www.nsa.gov/Press-Room/News-Highlights/Article/Artic...).
People will build malware. It is actually both fun and educational. Them sharing it makes the world aware of it, and when people are aware of it, they tend to adjust their security posture for the better if they feel threatened by it. Good cybersecurity research & development raises the bar for the industry and makes the world more secure.
Maybe I'm misunderstanding something, but you can add filters to RSS feeds. What is proposed is pretty much just RSS, except for one specific item. Yes, it's more work on your side, but asking the creator to manage updates for whatever one thing any/every random person is interested in is pretty unrealistic, especially since the people asking for this are going to be explicitly not interested in everything else about the creator.
> There’s no AI to this. No magic. No problems to be solved.
Why would you not involve yourself in the new hotness? You _can_ put AI into this. Instead of using some expression to figure out whether a new article has links to the previous ones in the series / a matching title, you can have a local agent check your RSS feed and tell you if it's what you're looking for, or else delete the article. For certain creators this might even be a sensible choice, depending on how purple their prose is and their preferred website setup.
How much work, and is Part 3 gonna be so mindblowing to be worth it?
> asking the creator to manage updates for whatever
Managing updates in this case is...posting Part 3? Something they were already gonna do? Except now there's also some machine-only endpoint that needs to start returning "Yes" instead of "No"? Doesn't sound like a ton of work.
> Why would you not involve yourself in the new hotness? You _can_ put AI into this.
Because just involving yourself with the new hotness just because it is the new hotness is pathetic. I can put AI into this, but why would I? Why would I add all the heft and complexity and stupid natural language bullshit talking to a computer when I could just press a button that will do this for me deterministically?
How is this different than just curling the endpoint? It seems like you might be asking the producer to be able to execute any arbitrary calculation across their (codebase?, website? Thing?). The reason it’s never been implemented is because it’s impossible
Neat, but isn't packing all this stuff into a bash script overkill? You can pretty easily install and configure some good tools (i.e. crowdsec, rkhunter, ssh tarpit or whatever) to cover each of the categories rather than have a bunch of half-measures.
Also, you're calling this TheProtector, but internally it seems to be called ghost sentinel?
I'm not sure how valid most of these points are. A lot of the latency in an agentic system is going to be the calls to the LLM(s).
From the article:
"""
Agents typically have a number of shared characteristics when they start to scale (read: have actual users):
They are long-running — anywhere from seconds to minutes to hours.
Each execution is expensive — not just the LLM calls, but the nature of the agent is to replace something that would typically require a human operator. Development environments, browser infrastructure, large document processing — these all cost $$$.
They often involve input from a user (or another agent!) at some point in their execution cycle.
They spend a lot of time awaiting i/o or a human.
"""
No. 1 doesn't really point to one language over another, and all the rest show that execution speed and server-side efficiency is not very relevant. People ask agents a question and do something else while the agent works. If the agent takes a couple seconds longer because you've written it in Python, I doubt that anyone would care (in the majority of cases at least).
I'd argue Python is a better fit for agents, mostly because of the mountain of AI-related libraries and support that it has.
> Contrast this with Python: library developers need to think about asyncio, multithreading, multiprocessing, eventlet, gevent, and some other patterns...
Agents aren't that hard to make work, and you can get most of the use (and paying users) without optimizing every last thing. And besides, the mountain of support you have for whatever workflow you're building means that someone has probably already tried building at least part of what you're working on, so you don't have to go in blind.
That's true from a performance perspective but, in building an agent in Go, I was thankful that I had extremely well-worn patterns to manage concurrency, backlogs, and backpressure given that most interactions will involve one or more transactions with a remote service that takes several seconds to respond.
(I think you can effectively write an agent in any language and I think Javascript is probably the most popular choice. Now, generating code, regardless of whether it's an agent or a CLI tool or a server --- there, I think Go and LLM have a particularly nice chemistry.)
Agents are the orchestration layer, i.e. a perfect fit for Go (or Erlang, or Node). You don't need a "mountain of AI-related libraries" for them, particularly given the fact that what we call an agent now has only existed for less than 2 years. Anything doing serious IO should be abstracted behind a tool interface that can (and should) be implemented in whatever domain specific tooling is required.
I wouldn’t underestimate the impact of having massive communities around a language. Basically any problem you have has likely already been solved by 10 other people. With AI being as frothy as it is, that’s incredibly valuable.
Take for example something like being able to easily swap models, in Python it’s trivial with litellm. In niche languages you’re lucky to even have an official, well mantained SDK.
And I wouldn't overestimate a language's popularity. It's mostly a social phenomenon and rarely has anything to do with technical prowess.
I agree that integration with the separate LLMs / agents can and does accelerate initial development. But once you write the integration tooling in your language of choice -- likely a few weeks worth of work -- then it will all come down to competing on good orchestration.
Your parent poster is right: languages like Erlang / Elixir or Golang (or maybe Rust as well) are better-equipped.
Go still has a much better concurrency story. It’s also much less of a headache to deploy since all you need to deploy is a static binary and not a whole bespoke Python runtime with every pip dependency.
Easy example is Stripe. You can enable 3DS, and you can listen for 'early_fraud_warning' events on a webhook to refund users & close accounts to avoid chargebacks and all the associated fees and reputation penalties.
If I am in a call with someone using Nomi, can I send a message in the call or wherever to disable it, or will I have to ask the person using it to turn it off?
> "The real challenge in traditional vector search isn't just poor re-ranking; it's weak initial retrieval. If the first layer of results misses the right signals, no amount of re-sorting will fix it. That's where Superlinked changes the game."
Currently a lot of RAG pipelines use the BM25 algorithm for retrieval, which is very good. You then use an agent to rerank stuff only after you've got your top 5-25 results, which is not that slow or expensive, if you've done a good job with your chunking. Using metadata is also not really a 'new' approach (well, in LLM time at least) - it's more about what metadata you use and how you use them.
If this were true, and initial candidate retrieval were a solved problem, teams where search is revenue aligned wouldn't have teams of very well paid people looking for marginal improvement here.
Treating BM25 as a silver bullet is just as strange as treating vector search as the "true way" to solve retrieval.
I don't mean to imply that it's a solved problem; all I'm saying is that in a lot of cases, the "weak initial retrieval" assertion stated by the article is not true. And if you can get a long way using what has now become the industry standard, there's not really a case to be made that BM25 is bad/unsuited, unless the improvement you gain from something more complex is more than just marginal.
one thing to remember is that bm25 is purely in the domain of text - the moment any other signal enters in the picture (and it ~always does in sufficiently important systems), bm25 alone can literally have 0 recall.
It sounds like you might be looking at the wrong place. There's services like bunny.net and cloudflare CDN (I'm not affiliated with either, but I use the former) that are really easy to set up and configure, if you've built your site properly (edit for clarification: if you have clearly defined static content, and/or you're using some build system). You don't want to 'run' a CDN, you want to use one.
Configuration depends a lot on the specifics of your stack. For Svelte, you can use an adapter (https://svelte.dev/docs/kit/adapters) that will handle pointing to the CDN for you.
Cloudflare's offering is free, bunny.net is also probably going to be free for you if you don't have much traffic. CDNs are great insurance for static sites, because they can handle all the traffic you could possibly get without breaking a sweat.
This. Normal AirTags are just fine for tracking your stuff.
> "(thiefs use apps to locate AirTags around, and AirTags will warn the thief if an unknown AirTag is travelling with them, for example if they steal your car)"
The reason this was introduced is exactly because people used AirTags to stalk others. Advertising that your product turns that off is basically targeting that specific demographic.
And you can use hammers to brutally murder people as well as to drive in nails. You can use a screwdriver to grievously wound someone besides using it to repair your glasses. The fact that a tool can be used for bad things does not negate the good things it can be used for. Nor does it mean that the maker is responsible if someone chooses to use it for bad things.
That being said, Claude does not structure the project in the way someone familiar with the engine would, and just like any 'real' software, if you don't guide it, the output quickly degenerates. For example, stuff that would normally, intuitively be a child item in a scene, Claude instead prefers to initialize in code for some reason. It does not seem to care about group labels, which is an extremely easy way to identify different (types of) objects that should be treated in the same way in certain cases.
The games in the video look like GameJam projects? I'm not good at Godot, and I could probably hack most of them together in a week or so. I imagine an actual game developer could put some of them together in days.
In order to have LLMs build something good with any framework, not just a game engine, you have to steer and curate the output, otherwise non-trivial projects become intractable past a certain point, and you have a mountain of bugs to sort through.
> The Training Data Scarcity: LLMs barely know GDScript.
I've not found this to be an issue. Claude does just fine when you explain what you want. I've never had it hallucinate stuff, and I've barely seen it look at docs. Granted, I've only had it write 1-2k lines of GDScript, but I've never felt like it was spouting complete nonsense.
> To fix this, I built a custom reference system: a hand-written language spec, full API docs converted from Godot's XML source, and a quirks database for engine behaviors you can't learn from docs alone.
This is the point where I feel like this is nonsense (more than what the LLM-written prose would imply). Maybe this is my inexperience talking, but I feel there is no way that this would be better in any way over any alternative. Especially if you just lazy-load stuff at runtime. Godot already has good docs. They should certainly cover much more than whatever you need to make the games you demonstrated. What is the point of making a duplicate version of the docs, when you have the docs right there? If you really think that Claude can't handle GDScript, you can just use C#?
> The Build-Time vs. Runtime State: Scenes are generated by headless scripts that build the node graph in memory and serialize it to .tscn files. This avoids the fragility of hand-editing Godot's serialization format.
Again, maybe that's my inexperience with Godot, but I have no idea what you're talking about here? When you run, you do get a different node tree (and 'state' I guess?) but where does "hand-editing Godot's serialization format" come into this? Why would you ever need to concern yourself with what Godot does to transform your code after you've written it?
> It catches the visual bugs text analysis misses: z-fighting, floating objects, physics explosions, and grid-like placements that should be organic.
Funnily enough, those are all stuff that text analysis should be better at finding. I personally use logs & actually playing the game.
reply