22c

First I'm hearing of TigerStyle.

> The time to solve performance, and get the 1000x wins, is in the design phase, when you can't profile.

How does this make practical sense? I find it immensely easier to fix performance issues by profiling, benchmarking, finding hotspots. Things that weren't obviously performance bottlenecks during design become obvious when you profile.

Interesting write-up though. I haven't properly tried zig but I like reading these "initial impressions" style articles about it.

Amazon has a history of fostering off-shoot companies that are given more freedom to innovate[1][2]. Keeping AI development in-house under Bedrock was probably their mistake. There's a big difference between running AI and developing new AI models.

[1] https://en.wikipedia.org/wiki/Annapurna_Labs

[2] https://en.wikipedia.org/wiki/Amazon_Lab126

https://github.com/nationaldesignstudio/rampart ?

Again, you need frame the article around the paper they're trying to build their benchmark against. Yes, the real world/natural language is fuzzy, but the ProofWriter paper (that this article bases it's own benchmark on) is not about taking fuzzy rules and turning them into proofs, it's about taking concrete statements, mapping those to facts, rules and conclusions.

We CAN'T from the statement "dogs are usually wet" make any conclusions about the wetness state of your neighbours dog.

We CAN from the statement "there is no teacup floating around Saturn" create a rule, specifically about teacups floating around Saturn.

As silly as that rule sounds, it allows you to refine/test against things, for example your space engineering team might have been under the assumption that no coffee mugs are orbiting Saturn, so you ask your all-knowing oracle what the probabilities of that statement being false are and you CAN get an answer that it rightfully doesn't know. That allows your space engineers to go back to the drawing board about the proof itself, is it actually that there's no crockery at all floating around Saturn? We can generalise our proof, then and cover off dinner plates and bowls as well instead of just tea cups.

The point is you don't _want_ the model to guess, in that scenario. You want it to say "I don't know, I don't have enough information to make that conclusion based on what you've told me about Saturn so far", which is exactly what Luna seems to do and get "wrong", according to the blog.

> Alan is young, round, and kind, but that doesn't mean he isn't also rough and cold at times, as well.

What we learn: Alan is young, round, kind. These things don't prevent Alan from being cold or rough. Alan might or might not be "rough and cold" at times. It is not clear if Alan can be rough without being cold, or vice-versa.

> Young round people who are green are usually blue.

This tells us nothing about Alan. It tells us that young, round people can be both green and blue.

> Kind people with rough skin are usually red because it's wind burn.

Alan has been described as kind. We do not know if Alan is currently rough, we do not know if Alan has rough skin. Even if Alan had rough skin, we do not know if Alan is currently red.

> If someone shows that they are red, then they are also showing that they are green.

What does "showing" mean here? Either way if someone is "showing that they are red", then they also "showing that they are green", OK. I guess it also means that people can show that they are red and green.

> Statement: Alan is not blue.

Let's go through what we know about Alan.

Alan is young, round, and kind. Alan could at times be rough and cold.

That's all we know about Alan. We can't be certain that Alan is anything else.

Even if Alan were currently rough and being currently rough can be equated to "having rough skin", we still can't be sure if Alan is red as a result of said "rough skin" (only usually red).

Even if Alan is red as a result, we don't know if this counts as Alan is "showing" that they are red.

If we count Alan is red as "Alan is showing that they are red", then we can conclude that Alan is "showing" that they are both red and green.

If we count Alan is "showing that they are green" as "Alan is green", this STILL doesn't mean that the statemen "Alan is not blue" is false.

We do know (after we make ALL these assumptions) that Alan could be young, round, kind, rough/rough-skinned, (showing as) red/green..

So if someone is young, round and green, they are USUALLY blue.. THAT STILL DOESN'T MEAN THAT ALAN IS ACTUALLY BLUE.

Anyway, enjoy the free training data AI labs...

I think we have to assume that the paraphrasing is at best a poor paraphrase and at worst completely misleading.

The paraphrased statement contains soft, non-deterministic hedges like "usually" and "sometimes", which would of course introduce uncertainty. Uncertainty -> low confidence.

The article strips out the actual prompt that went to Luna so we can't be sure they haven't ballsed the prompt just as they did with the paraphrase.

Compare the paraphrase to the language used in the actual paper they're trying to base their benchmark on:

> Bob is round.

> Alan is blue, rough and young.

> If someone is round then they are big.

> All rough people are green.

> Big people are not green.

This is obviously much easier to make certain statements about (the only thing we have to assume is that Bob and Alan are both "people").

Interesting, but didn't the folks from System One specifically say that Jev isn't really tuned for these kind of "Has the rest of the owl been drawn?"-style prompts?

For example:

> Non-obvious code lacks explanation of its rationale

This is so open-ended, I don't really think you're going to get reliable feedback from Jev here, at least according to my interpretation of what System One representatives were saying.

No it's not related, sadly Byuu passed away several years ago.

Sadly, the AI writing is so terribly distracting.

So the long and short of it seems to be an advertisement for the site itself?

I think this should've been a show HN as your affiliation with the site is not obvious from the outset.

Good luck with your project, but I suspect it will take more than a Claude subscription and a dream to replace what the article claims has been lost.

Looks like they merged it back in, but it's a shame it was taken out in the first place.

I don't fully get the negativity here. This seems like a middle ground between quick'n'dirty bash script and a well-crafted Ansible playbook.

Half the time if you want to do something quick'n'dirty in Ansible playbooks you need to use shell anyway..

I participated in a hackathon recently where my deployment process was just a bash script doing scp/ssh to a remote server and it feels like Scotty would fit well to that kind of use-case.

Looks similar to sem/weave

https://github.com/ataraxy-labs/sem

https://github.com/ataraxy-labs/weave

Though, despite the claims, I am not sure if these are ready for prime-time yet. I have noticed some rather concerning merge "resolutions".

> yt-dlp is running the entire YouTube JS+DOM environment

IIRC they maintain a minimal execution environment that is able to run just the JS needed to pass a few checks but this breaks too often enough that they're planning to make Node.js or another JS interpreter a hard requirement (possibly already happened).

PMs can now also ship their half-baked requirements documents even faster thanks to the help of AI.

I noted something similar a few weeks ago. Companies are finally putting APIs in front of things that should have had APIs for years!

Pretty sure I saw this one a couple of weeks back, or something very similar to it..

https://github.com/philschmid/mcp-cli

Edit: Turns out was https://github.com/steipete/mcporter noted elsewhere in the thread, but mcp-cli looks like a very similar thing.

I believe you're thinking of JScript, they're not quite the same thing.

FWIW I think most users here would prefer you reply to their hand-written comments using your own words, even if you had to use a translator.

> An AI agent was used to gain super-user access

No telling if this "hack" wasn't really just prompt engineering followed by hallucinations, particularly if the "hacker" was attempting to exfil data via the agent.

> "The key insight is..."

This was either written by Claude or someone who uses Claude too much.

I wish they could be upfront about it.

I can't help but feel there is a funny pattern going on.

A lot of companies want to embrace AI, agents, etc. so they make their platforms easier to use by AI, implementing whatever the latest craze is.

I imagine we're going to see a lot more APIs open up (agentic finances?), a lot of granular access controls, etc.

Where was all of this when regular users had been asking for it for _years_?

Empowering users in general is a good thing, so, in a way, it's a good thing that OpenClaw and things of this nature are exposing all the issues with access controls and API interactions that many of our services have.

Now we just need a reason for AI agents to need "dark mode" on websites...

TIL there's a batch API.. This seems like something a lot of AFK coders should be using.

The pattern for those users is typically they would set some kind of token budget, but their agent would still try to burn through those tokens as quickly as possible, rather than a more sensible "do this at your own leisure over the next ~8 hours".

Looking forward to further commodification of LLM usage in the future to make it more affordable. Batch APIs and more freedom over scheduling/priorities/deadlines seems like the more sustainable approach to driving costs down.

I tried teams, good way to burn all your tokens in a matter of minutes.

It seems that the Claude Code team has not properly taught Claude how to use teams effectively.

One of the biggest problems I saw with it is that Claude assumes team members are like a real worker, where once they finish a task they should immediately be given the next task. What should really happen is once they finish a task they should be terminated and a new agent should be spawned for the next task.

> its because people actually want AI to talk to them like that

I can't find the particular article (there's a few blogs and papers pointing out the phenomenon, I can't find the one I enjoyed) but it was along the lines of how in LLMArena a lot of users tend to pick the "confidently incorrect" model over the "boring sounding but correct" model.

The average user probably prefers the sycophantic echo chamber of confirmation bias offered by a lot of large language models.

I can't help but draw parallels to the "You are not immune to propaganda" memes. Turns out most of us are not immune to confirmation bias, either.

Hasn't Michael Burry been talking about this exact thing for at least 6 years now?

Edit:

The Big Short’s Michael Burry Explains Why Index Funds Are Like Subprime CDOs (2019)

https://archive.is/7mOuF

> I've thought about building the same thing, by using beads... Glad someone in the hivemind did it.

Gas Town is from the creator of beads.

Sidenote from the article, but TIL Mark Atwood is no longer at Amazon.

> What’s old is new again

Let's go back even further.. I get strong nForce vibes from that extract!

Carmack's comments and the comments in the thread entirely surprise me.

256kbit/s was pretty much the standard ADSL speed 20 years ago. I remember thinking it was lucky some of my friends had 512kbit/s and 1500kbit/s was considered extremely fortunate.

Even still calls over Skype worked fine, you could run IRC or MSN Messenger while loading flash games or downloading MP3s. You could definitely play games like Starcraft, Age of Empires, Quake, UT2004, etc. on a 256k ADSL line. Those plans were also about 8x the price of this plan, not even adjusting for inflation.

Not only that, those lines were typically only 64k upload speed. The usefulness of a 500kbit/s up/down line is incredibly high. I think the only reason it might seem less useful now is that web services are not typically optimised to be usable on dial-up speeds like they were 20 years ago.

With the right setup and having feeds/content download asynchronously rather than "on-demand", 500kbit/s is still plenty of internet by today's standards.

Does it mean that they can be stored at room temperature, in humid conditions, etc? ie. requiring no HVAC/dehumidifiers or whatever else might be needed to reliably store archive media?

That's my charitable interpretation.