bravura

You're making the convenience argument, but I'm making the architecture argument. They're not the same thing.

You say "a very simple API baked into the model's existing context is even better". So we agree? MCP's design actively discourages that better path.

"Agents are good at writing API requests, but not so good at knowing why, when, or what to use". This is exactly what progressive discovery solves. A good CLI has --help. A good API has introspection. MCP's answer is "dump all the tool schemas into context and let the model figure it out," which is O(N) context cost at all times vs O(1) until you actually need something.

"It's just a standard way to make plugins" The plugin pattern of "here are 47 tool descriptions, good luck" is exactly the worse-is-better tradeoff I'm describing. Easy to wire up, expensive at runtime, and it gets worse as you add more servers.

The NJ/MIT analogy isn't about complexity, it's about where the design effort goes. MCP puts the effort into easy integration. A well-designed API puts the effort into efficient discovery. One scales, the other doesn't.

The last time I looked at MCPs closely, they appeared to pollute context and just hang there consuming context constantly. Whereas a self-documenting API or CLI tool enabled progressive discovery.

Has this changed?

My uncharitable interpretation is that MCP servers are NJ design for agents, and high quality APIs and CLIs are MIT design.

How do people think about the sort of access and permissions it needs?

"Don't give it access to anything you wouldn't give a new contractor on day one."

https://x.com/rahulsood/status/2015397582105969106

Understanding your audience is your first job as a writer or communicator.

Speaking to them and making them care is job two.

We use beads for everything. We label them as "human-spec" needed if they are not ready to implement. We label them as "qa-needed" if they cannot be verified through automatic tests.

I wrote beads-skills for Claude that I'll release soon to enforce this process.

2026 will be the year of agent orchestration for those of us who are frustrated having 10 different agents to check on constantly.

gastown is cool but too opinionated.

I'm excited about this promising new project: https://github.com/jzila/canopy

We're writing an internal tool to help with planning, which most people don't think is a problem but I think is a serious problem. Most plans are either too long and/or you end up repeating yourself.

Can you please expose the functionality as a self-documenting CLI command with machine readable output? (Or did I misunderstand that MCP isn't the only way to use it?)

I am curious to try it but do not want to adopt MCP servers.

Telling Claude to call the CLI tool is more efficient.

A rigorous approach to predicting the future of text was proposed by Li et al 2024, "Evaluating Large Language Models for Generalization and Robustness via Data Compression" (https://ar5iv.labs.arxiv.org/html//2402.00861) and I think that work should get more recognition.

They measure compression (perplexity) on future Wikipedia, news articles, code, arXiv papers, and multi-modal data. Data compression is intimately connected with robustness and generalization.

Now, please make it easy to control network egress!

My friend is organizing a challenge to build a clean room SQL implementation from scratch as fast as possible, using agents:

https://vibesql.org/

https://github.com/vibesql-challenge

“ If your x noise was greater than your y noise, you generally wouldn't bother taking the measurement in the first place.”

Why not? You could still do inference in this case.

What's the startup time for using beancount if I've never done it before?

I just spent a few hours using LLMs (aider, specifically) to reconcile my books for the past year. Worked great, but was slightly fiddly.

Do you mind elaborating?

And what do you use instead?

I know this is a general question, but:

Assuming a US startup is considering engineering hires outside the United States, how does one currently assess the likelihood of getting them a visa to work in the USA? And what timeline and cost would be involved?

Agreed, to me they are very different takes on what is a punk attitude.

Palahniuk: Underneath the veneer of the banal, you will discover everything is rotten and sycophantic but somehow tender and relatable.

Bourdain: Underneath the veneer of the banal, you will discover an honest struggle for something far more respectable than what is typically venerated. Eat their food, dance to their music, and you will enjoy.

Isn't the challenge that introspecting graphql will lead to either a) a very long set of definitions consuming many tokens or b) many calls to drill into the introspection?

Call your father. And just chit chat for ten minutes.

Thoughts on any-llm-gateway versus litellm-proxy?

litellm is a great library, but one team using litellm-proxy reported having many issues with it to me. I haven't tried it yet.

LLMs are not deterministic though. So by definition MCPs are not deterministic.

For example, GPT-5 doesn't support temperature parameter. And even models that do support temperature are not deterministic with temperature=0.

How large is a lion?

Learning the size of objects using pure text analysis requires significant gymnastics.

Vision demonstrates physical size more easily.

Multimodal learning is important. Full stop.

Purely textual learning is not sample efficient for world modeling and the optimization can get stuck in local optima that are easily escaped through multimodal evidence.

("How large are lions? inducing distributions over quantitative attributes", Elazar et al 2019)

Have you tried e2b or Daytona fast start vms?

How do you use a non Anthropic model with Claude Code?

The text-based software that would eat work management is one that embraces the incumbents rather than avoid them.

I want a bidirectional SaaS <=> YAML/JSON adapter. So that I can push and pull our CRM (and other SaaS utilities like project management) into a common (schematized) YAML format.

The YAML then can be analyzed and modified using LLMs and/or stored in git.

And then use the bidirectional sync to reconcile conflicts and push.

So I can do work processes on the console, and still collaborate with people who want the native web UI.

I'm curious about tptacek's comment (https://news.ycombinator.com/item?id=28279426). 'the "security" paragraphs in this page do the rest of the argument a disservice. The fact is, C is a demonstrable security liability for sqlite.'

The current doc no longer has any paragraphs about security, or even the word security once.

The 2021 edition of the doc contained this text which no longer appears: 'Safe languages are often touted for helping to prevent security vulnerabilities. True enough, but SQLite is not a particularly security-sensitive library. If an application is running untrusted and unverified SQL, then it already has much bigger security issues (SQL injection) that no "safe" language will fix.

It is true that applications sometimes import complete binary SQLite database files from untrusted sources, and such imports could present a possible attack vector. However, those code paths in SQLite are limited and are extremely well tested. And pre-validation routines are available to applications that want to read untrusted databases that can help detect possible attacks prior to use.'

https://web.archive.org/web/20210825025834/https%3A//www.sql...

Sorry fat fingers. It should be the y axis that is log scale, not x axis. (Sometimes both is good.)

Did you notice the inflection point in which the loss drops faster than expected in the top graph? Maybe you should let it run more…

The measures that drop exponentially like val/bpb and train/loss you should put the x-axis in log-scale. That will better show you if it's converged

Naturally, the science of science study supporting the controvening „Newton hypothesis“ is pseudo scientific piffle.

My scientific study of the science of science study can prove this. Arxiv preprint forthcoming.

Yeah, overall I think we agree.

If you want to read some mind blowing early neural language sequence modeling approaches that everyone completely slept on, look at Pollack's work on "recursive auto-associative memory" (RAAM) and Sperduti's later labeled RAAM (LRAAM) work. Both from the early 90s. Didn't have a probabilistic interpretation IIRC.

Yoshua was always sort of agnostic about probabilistic approaches and used them when they made sense. 50% of his work included them, and other like early deep vision works of his purely motivated the use of deep models in terms of circuit theory and compactness / model complexity.

Collobert and Weston taught us we could train Yoshua's NLM models much much faster using negative sampling and a hinge loss, thus dropping the probabilistic story entirely.

I suspect the historical reason is that in the mid 2000s, the NLP community only very broadly started adopting statistical methods. (i.e. grad started began to be more likely to use them than not, which hadn't been true historically when linguistics not stats drove many intuitions, and using a CRF felt sort of next-level). So once every got comfortable with stats as table-stakes, they felt a sort of whiplash to stop approaching things through this lens.

"my explanation would also to apply to where other commenters note that this behaviour is emitted to some degree with similar other "plausible" but non-existent emoji (but which are less likely to be in the training data, a priori)."

I agree with you partially. I just want to argue there are several factors that lead to this perverse behavior.

Empirically:

Use web gpt-5-instant in TEMPORARY mode. If you ask for "igloo emoji" it confidently (but ONLY in temporary mode) says that "Yes, igloo emoji is in Unicode 12 and is [house-emoji ice-emoji]." Then it basically stops. But it has satisfied its condition of confidently expressing its false knowledge. (Igloo emoji doesn't exist. gpt-5-instant in non-temporary mode says no. This is also weird because it suggests the temporary mode system prompt is laxer or different.)

The mechanism you describe partially explains why "seahorse emoji" leads to babbling: As it outputs the next token, it realizes that the explanation would be worse off it if next emits stop token, so instead it apologizes and attempts to repair. And cannot satisfy its condition of expressing something confidently.

The upstream failure is poor knowledge. That combined with being tuned to be helpful and explanatory, and having no grounding (e.g. websearch) forces it to continue. Finally, the token distance from the manifold is the final piece of the puzzle in this unholy pathological brew.

You're incorrect that statistical language modeling is "post-hoc", it's rather "pre-hoc" / "pre-hack". Most foundational works in language modeling started as pure statistical models (for example, classic ngram models and Bengio's original neural language model from 2003), and it was later that hacks got introduced that removed statistical properties but actually just worked (Collobert and Weston 2008, as influenced by Bottou and LeCun). Where I agree with you is that we should have done away with the statistical story long ago. LeCun's been on about energy-based models forever. Even on HN last week, punters criticize him that JEPA hasn't had impact yet, as if he were behind the curve instead of way ahead of it.

People like statistical stories but, similarly to you, I also think they are a distraction.

You're missing one key point, which is what makes this failure mode unusual.

Namely, that there is (incorrect) knowledge in the training data that "seahorse emoji" exists.

So when prompted: "Does [thing you strongly believe exist]?" the LLM must answer: "Yes, ..."

(The second nuance is that the LLM is strongly encouraged to explain its answers so it receives a lower score just by saying only "Yes.")

But I and probably others appreciate your more detailed description of how it enters a repair loop, thank you.

[edit: I disagree that LLMs are not statistical or probabilistic, but I'm not sure this is worth discussing.]

[edit 2: Google is no longer telling me how many web pages a term responds, but "seahorse emoji" and "lime emoji" quoted both return over ten pages of results. The point being that those are both 'likely' terms for an LLM, but only the former is a likely continuation of 'Does X exist? Yes, ..."]

It correctly represents "seahorse emoji" internally AND it has in-built (but factually incorrect) knowledge that this emoji exists.

Example: "Is there a lime emoji?" Since it believes the answer is no, it doesn't attempt to generate it.