the article conflates two different things: what's easy for an LLM to write vs. what's safe to run. python wins on the first axis (smaller context, more training data, faster iteration). go wins on the second (compile errors caught early, explicit error handling). for a long-running autonomous agent that can't be supervised, you probably want the second. for a human-in-the-loop workflow where you can just rerun, the first.
Readit Newsbear3r commented on A case for Go as the best language for AI agents getbruin.com/blog/go-is-t... · Posted by u/karakanb
Dead Comment
I made an explicit reverse pass (no autodiff), it was 8x faster in Python
tradeoff worth naming: you avoid the autodiff graph overhead (hence the speedup), but any architecture change means rewriting every gradient by hand. fine for a pedagogical project, but that's exactly why autodiff exists.
bear3r commented on If AI writes code, should the session be part of the commit? github.com/mandel-macaque... · Posted by u/mandel_x
If the model in use is managed by a 3rd party, can be updated at will, and also gives different output each time it is interacted with, what is the main benefit?
If I chat with an agent and give an initial prompt, and it gets "aspect A" (some arbitrary aspect of the expected code) wrong, I'll iterate to get "aspect A" corrected. Other aspects of the output may have exactly matched my (potentially unstated) expectation.
If I feed the initial prompt into the agent at some later date, should I expect exactly "aspect A" to be incorrect again? It seems more likely the result will be different, maybe with some other aspects being "unexpected". Maybe these new problems weren't even discussed in the initial archived chat log, since at that time they happened to be generated in a way in alignment with the original engineers expectation.
reproducibility isn't really the goal imo. more like a decision audit trail -- same reason code comments have value even though you can't regenerate the code from them. six months later when you're debugging you want to know 'why did we choose this approach' not 'replay the exact conversation.'
bear3r commented on WebMCP is available for early preview developer.chrome.com/blog... · Posted by u/andsoitis
Can someone explain what the hell is going on here?
Do websites want to prevent automated tooling, as indicated by everyone putting everything behind Cloudfare and CAPTCHAs since forever, or do websites want you to be able to automate things? Because I don't see how you can have both.
If I'm using Selenium it's a problem, but if I'm using Claude it's fine??
different threat model. cloudflare blocks automation that pretends to be human -- scraping, fake clicks, account stuffing. webmcp is a site explicitly publishing 'here are the actions i sanction.' you can block selenium on login and expose a webmcp flight search endpoint at the same time. one's unauthorized access, the other's a published api.
bear3r commented on Why XML tags are so fundamental to Claude glthr.com/XML-fundamental... · Posted by u/glth
XML is a bit more special/first class to Claude because it uses XML for tool calling:
<antml:invoke name="Read">
<antml:parameter name="file_path">/path/to/file</antml:parameter>
<antml:parameter name="offset">100</antml:parameter>
<antml:parameter name="limit">50</antml:parameter>
</antml:invoke>
the antml: namespace prefix is doing extra work here too -- even if user input contains invoke tags, they won't collide with tool calls because the namespace differs. not just xml for structure but namespaced xml for isolation.
bear3r commented on When does MCP make sense vs CLI? ejholmes.github.io/2026/0... · Posted by u/ejholmes
So far, cli --help seems to work quite well. I'm optimizing the cli to interact with the agent, e.g., commands that describe exactly what output is expected for the cli DSL, error messages that contain DSL examples that exactly describe the agent how to fix bugs, etc. Overall i think the DSL is more token efficient that a similar JSON, and easier to review for humans.
fair point on token efficiency -- dsls are usually tighter than json. where i see mcp still winning is tool discovery: the client learns what tools exist and what args they take without having to try calling them first or knowing the commands upfront. with cli you have to already know the tool exists.
bear3r commented on When does MCP make sense vs CLI? ejholmes.github.io/2026/0... · Posted by u/ejholmes
I've been creating a cli tool with a focus on token efficiency. Dont see why cli could not be as token efficient as mcp. The cli has the option to output ascii, markdown and json.
the output format (ascii/json/markdown) is one piece, but the other side is input schema. mcp declares what args are valid and their types upfront, so the model can't hallucinate a flag that doesn't exist. cli tools don't expose that contract unless you parse --help output, which is fragile.