With a bit of education one would know that manus is Latin for hand. That's where "manual" comes from.

And their logo is, lo and behold ... a hand!

Since it's an AI company, and not actually doing anything by hand, it wouldn't surprise me if they came up with the name "manus" because it has "anus" in it, and then designed the hand logo due to the Latin meaning of the name. [this is a sarcasm, in case that was not clear]

So it is the Ancient Romans who were obsessed with butts. Got it.

There are more English words that end in -ass than Latin words that end in -anus, so who's really obsessed?

Canonically it was winged penises, but yes.

I've been preaching similar thoughts for the last half year.

Most popular programming languages are optimized for human convenience, not for correctness! Even most of the popular typed languages (Java/Kotlin/Go/...) have a wide surface area for misuse that is not caught at compile time.

Case in point: In my experience, LLMs produce correct code way more regularly for Rust than for Js/Ts/Python/... . Rust has a very strict type system. Both the standard library and the whole library ecosystem lean towards strict APIs that enforce correctness, prevent invalid operations, and push towards handling or at least propagating errors.

The AIs will often write code that won't compile initially, but after a few iterations with the compiler the result is often correct. Strong typing also makes it much easier to validate the output when reviewing.

With AIs being able to do more and more of the implementation, the "feel-good" factor of languages will become much less relevant. Iteration speed is not so important when parallel AI agents do the "grunt work". I'd much rather wait 10 minutes for solid output rather than 2 minutes for something fragile.

We can finally move the industry away from wild-west languages like Python/JS and towards more rigorous standards.

Rust is probably the sweet spot at the moment, thanks to it being semi-popular with a reasonably active ecosystem, sadly I don't think the right language exists at the moment.

What we really want is a language with a very strict, comprehensive type system with dependent types, maybe linear types, structured concurrency, and a built-in formal proof system.

Something like ADA/Spark, but more modern.

What you are saying is: no, it doesn't.

Of course dynamic dispatch can be implemented in almost every language. The Linux kernel uses dynamic dispatch with C!

But that's a hack, not a language feature.

I think you might mean “ad hoc polymorphism” rather than “dynamic dispatch”. Gleam, C, Erlang, etc have the latter, not so much the former.

It's not a "hack" because many language DO NOT let you store functions with state. Gleam does, I write PHP, and that does as well.

PHP has interfaces and whatnot, but a lot of the time I do polymorphism by just having a class that has Closure members. When you can arbitrarily pass around functions like that, it's basically equivalent to an interface or abstract class, with a bit more flexibility.

Would love a Rust implementation of this.

To be fair, you can enforce this just by filling all the allocated memory with zero, so it's possible to fail at startup.

Or, even simpler, just turn off over-commit.

But if swap comes into the mix, or just if the OS decides it needs the memory later for something critical, you can still get killed.

I would be suprised if some os detects the page of zeros and removes that allocation until you need it. this seems like a common enough case as to make it worth it when memory is low. I'm not aware of any that do, but it wouldn't be that hard and so seems like someone would try it.

There's also KSM, kernel same-page merging.

I use AoC as a chance to try a new language every year.

In the past I used it to try out Swift, J, R, ...

LLMs, and especially coding focused models, have come a very long way in the past year.

The difference when working on larger tasks that require reasoning is night and day.

In theory it would be very interesting to go back and retry the 2024 tasks, but those will likely have ended up in the training data by now...

> LLMs, and especially coding focused models, have come a very long way in the past year.

I see people assert this all over the place, but personally I have decreased my usage of LLMs in the last year. During this change I’ve also increasingly developed the reputation of “the guy who can get things shipped” in my company.

I still use LLMs, and likely always will, but I no longer let them do the bulk of the work and have benefited from it.

Last April I asked Claude Sonnet 3.7 to solve AoC 2024 day 3 in x86-64 assembler and it one-shotted solutions for part 1 and 2(!)

It's true this was 4 months after AoC 2024 was out, so it may have been trained on the answer, but I think that's way too soon.

Day 3 in 2024 isn't a Math Olympiad tier problem or anything but it seems novel enough, and my prior experience with LLMs were that they were absolutely atrocious at assembler.

https://adventofcode.com/2024/day/3

Last year, I saw LLMs do well on the first week and accuracy drop off after that.

But as others have said, it’s a night and day difference now, particularly with code execution.

Knowing that the rules for your first small deployment are not the same as the rules for everywhere, is valuable for designing well. Trying to implement all of those sets of rules in your initial deployment, is not a good idea. There is a general principle that you shouldn't code the abstraction until you've coded for the concrete example 2 or 3 times, because otherwise you won't make the right abstraction. Looking ahead is not the same as starting with the whole enchilada for your initial deployment.

Side question: what are the current top goto open models for image captioning and building image embeddings dbs, with somewhat reasonable hardware requirements?

For pure image embedding, I find DINOv3 to be quite good. For multimodal embedding, maybe RzenEmbed. For captioning I would use a regular multimodal LLM, Qwen 3 or Gemma 3 or something, if your compute budget allows.

Try any of the qwen3-vl models. They have 8, 4 and 2B models in this family.

What do you mean "bounding boxes"? They were talking about captions and embeddings, so a vision language model is required.

I suggested YOLO and non llm-vl as a lot faster alternative.

Of course CLIP would be otherwise the other option than a big llm-vl one.

Which YOLO?

Any current one. they are easy to use and you can just benchmark them yourself.

I'm using small and medum.

Also the code for using it is very short and easy to use. You can also use ChatGPT to generate small exepriments to see what fits your case better

There aren’t any YOLO models for captioning and the other models aren’t robust enough to make for good embedding models.

You can get labels out of the classifier and bounding box models.

They are super fast.

Its just an alternative i'm mentioning. I would assume a person knowing a little bit of that domain.

Otherwise the first option would be CLIP i assume. llm-vl is just super slow and compute intensive.

The key is learning how to provide proper instructions.

Treat it as a developer that just joined the project and isn't aware of the conventions.

Provide hints for the desired API design, mention relevant code locations that should be read to gain context on the problem, or that do similar things.

An AGENTS.md that explains the project and provides some general guidelines also helps a lot.

Codex can be incredibly strong when prompted the right way.

This is generally the right approach imo (when it comes to codex).

In my experience Codex is pretty "bad" at spotting conventions or already existing code. Yesterday I told him a feature to implement (maybe 40 loc?) and he 1. did added unnecessary atomics and 2. he kinda reimplemented a function that already existed that he should've just reused.

I told him that and he fixed it but these are the things that kinda hold AI back by a lot. It's MUCH harder to read code than to write it, and if he writes the code I must 100% understand it to have the same confidence in it as if I did it myself. And that to me is mentally almost more taxing than doing it myself.

If you just let codex write the code while instructing him exactly what you want in terms of logic and architecture it works really well and saves a on of typing.

But when I’m at that point. I think either I myself or a faster agent can do the jobs, ergo no need for a long-running smart agent..

This might be in the nature of problems I’m facing in my coding endeavors. I just don’t have any tasks that I cant solve in less than 45 minutes, or the problem is so vague in my head, that I can't accurately describe it to an AI or human. Then usually I either need to split it in smaller problems or take a walk.

Since claude 4 I barely wish, omg I wish this agent would be smarter. I still wish it would be faster.

But what you described is of course good practice and necessary for smart execution as well.