shelajev

good catch, it's naturally `ANTHROPIC_API_KEY`, but I could have been more specific.

Nice, I really like the recent Vulkan support.

my background is mostly Java so I know this happens-before: (https://docs.oracle.com/javase/specs/jls/se8/html/jls-17.htm...).

from the article: > [Note 8: Informally, if A strongly happens before B, then A appears to be evaluated before B in all contexts. — end note]

this is the Java happens-before, right? What's the non-strong happens-berfore in C++ then?

I recently was trying to build an AI assistant to help with various chess things, which took shape of an MCP server: https://github.com/shelajev/mcp-stockfish

it builds as a docker image which has stockfish and maia (maiachess.com) together with different weights so it can simulate lower-level players.

It was a fun exercise, I tried a bunch of local models with this MCP server, which isn't particularly optimized, but also doesn't seem that bad. And the results were quite disappointing, they often would invent chess related reasoning and mess up answering questions, even if you'd expect them to rely on the tools and have true evaluation available.

It was also fun to say things: fetch a random game by username 'X' from lichess, analyze it and find positions which are good puzzles for a player rated N.

and see it figure out the algorithm of tool calls: - fetch the game - feed the moves to stockfish - find moves where evaluation changed sharply - feed it to maia at strength around N and to stockfish - if these disagree, it's probably a good puzzle.

I don't think I got to have a working setup like that even with managed cloud models. Various small issues, like timeouts on the MCP calls, general unreliability, etc. Then lost interest and abandoned the idea.

I should try again after seeing this thread

> "...engineers often mistakenly optimize for speed of information consumption over depth of understanding, leading to superficial knowledge."

really. Learning should [never] be fun - https://news.ycombinator.com/item?id=42099596

This is a Voxtral WebGPU demo for audio transcription where everything runs entirely in your browser with Transformers.js and ONNX.

Saying CI is a developer experience thing is completely misunderstanding the point.

AI workflows, vibe coding and such only emphasize the need for proper test suites and for a measured release process, where you don't actually delete your production databases on the whim.

It took me an embarrassingly long time to internalize what the reverse proxy is. My brain got stuck on the fact that it is just proxying requests. What's so reverse about this? Silly.

> "Closed platforms are going to lose to open ones that allow innovation"

Only if people (end-users) actually care. If you're trying to build against the momentum but misjudge your values for the community values, then you're in for a disappointment.

what a strange place to link to. Even Wikipedia has a better entry [1].

The model itself is fun to think about: preventing failures by stuffing more cheese into the system. If you're interested, the classic example of the cheese failure is Chernobyl, where many different things had to fail in order to become a catastrophe.

--- [1] https://en.wikipedia.org/wiki/Swiss_cheese_model

it's the latter: "you can actually start telling it to write a Playwright Python script instead and run that".

and while running the code might faster, it's unclear whether that approach scales well. Sending an MCP tool command to click the button that says "X", is something a small local LLM can do. Writing complex code after parsing significant amount of HTML (for correct selectors for example) probably needs a managed model.

"spooky action at a distance" sounds bad, but this is how most frameworks that embrace convention over configuration work. You add a dependency to your SpringBoot application and suddenly your app actually has new endpoints and config for them and so on.

If the code generation quality is so good you trust it to generate your verification system. You might as well write the tests yourself, and generate the actual implementation.

This way you're in control of what it means the code works, and formalize the acceptance criteria. Instead of feeding it a potentially incorrect implementation, and asking it to come up with a set of requirements what it should actually do.