I often found myself falling into patterns of poor judgement, e.g. mentally filtering out resumes based on the layout because, to my tired and bored mind, they looked similar to the resumes I had seen from unqualified candidates. I actually think some automation is helpful in evaluating them more rigorously.

But the problem is LLMs can't do those things. All they can do is "edit files" and "send messages".

I'm so tired of seeing these companies trivializing other people's work! Nobody's job is "edit files" and "respond to messages"! People have jobs like "find and close leads" and "reconcile accounts" and "arrange student field trips" and "make sure the hospital has enough inventory", not "generate reports" and "write code".

Editing files, producing reports, even writing code is just a byproduct. This is like the idiotic "lines of code produced" metric, but now they apply it to all of society.

That's what the 400k/yr is for.

I'm also using Playwright, to automate a platform that has a maze of iframes, referer links, etc. Hopefully I can replace the internals with a script I get from this project.

Helpful writeup here: https://pvieito.com/2026/01/inside-claude-cowork (I am not the author)

An LLM which makes a tool call to a function called `ride_bike`, where that function is a different sort of model with a different set of feedback mechanisms than those available to the LLM, is NOT the same thing at all. The LLM hasn't "learned" to ride the bike. The best you can say is that the LLM has learned that the bike can be ridden, and that it has a way of asking some other entity to ride on its behalf.

Now, could you develop such a model and make it available to an LLM? Sure, probably. But that's not an LLM. Moreover, it involves you, a human, making novel inroads on a different sort of AI/robotics problem. It simply is not possible to accomplish with an LLM.

I mean, services _could_ make it harder to use LLMs to interact with them, but if agents are popular enough they might see customers start to revolt over it.

Using agents that interact with APIs represents people being able to own their user experience more. Why not craft a frontend that behaves exactly the the way YOU want it to, tailor made for YOUR work, abstracting the set of products you are using and focusing only on the actual relevant bits of the work you are doing? Maybe a downside might be that there is more explicit metering of use in these products instead of the per-user licensing that is common today. But the upside is there is so much less scope for engagement-hacking, dark patterns, useless upselling, and so on.

You're asking someone to answer this question in a text forum. This is not quite the gotcha you think it is.

The distinction between "knowing" and "putting into language" is a rich source of epistemological debate going back to Plato and is still widely regarded to represent a particularly difficult philosophical conundrum. I don't see how you can make this claim with so much certainty.

I happen to think there is validity to the statement if you control for other actuarial factors. But if you don't think that makes sense as a lens through which to look at the problem, I won't quibble, even though I disagree. We're also only talking about drug prices here, which is a small portion of overall healthcare spending.

In any case, the central point, that insurers benefit from higher prices, still stands.

Yes. As I wrote above, insurers compete on premiums, and they do do so by using rebates to subsidize those premiums by spreading patients' deductibles across the insured population. As far as profits go, I can't speak to regulatory issues since they will vary by state, but in any case the same critique would apply if insurers are pocketing a fixed percentage of a larger amount.

Re your second point, it completely twists my point and is largely irrelevant. Yes, older people paying the same premiums as younger people is a counter-argument in that older people are more likely to need healthcare, but the central point is that people who have to USE their insurance (i.e. sick people) subsidize the premiums of people who don't (healthy people), and this critique applies regardless of age. Now, one could argue that the structural factors that control costs across age cohorts counterbalances this phenomenon. And I'd agree with you! But that doesn't negate the original point that insurance companies benefit from, and advocate for, high sticker prices.

They can use the rebates they get from the providers to subsidize the insured, allowing them to offer lower premiums and gain market share. This is what people mean when they say "In America, the sick people pay to subsidize the health care of the healthy people".

Of course, that above only applies if there is competitive pressure. If there is no competitive pressure (e.g. in states with only one or two insurers), they can keep premiums high and book as profit the difference between what the patient paid out and what the patient would have paid out in a lower-cost no-rebate world.

For data MCPs, we use remote MCPs that are served over an stdio bridge. So our configuration is just mcp-proxy[0] pointed at a fixed URL we control. The server has an /mcp endpoint that provides tools and that endpoint is hit whenever the desktop LLM starts up. So adding/removing/altering tools is simply a matter of changing that service and redeploying that API. (Note: There are sometimes complications, e.g. if I change an endpoint that used to return data directly, but now it writes a file to cloud storage and returns a URL (because the result is to large, i.e. to work around the aforementioned broken factor of MCP) we have to sync with our IT team to deploy a configuration change to everyone's machine.)

I have seen nicer implementations that use a full MCP gateway that does another proxy step to the upstream MCP servers, which I haven't used myself (though I want to). The added benefit is that you can log/track which MCPs your users are using most often and how they are doing, and you can abstract away a lot of the details of auth, monitor for security issues, etc. One of the projects I've looked at in that space is Mint MCP, but I haven't used it myself.

> What's your hit rate on researchers actually converting LLM explorations into permanent artifacts vs just using it as a one-off?

Low. Which in our case is ideal, since most research ideas can be quickly discarded and save us a ton of time and money that would otherwise be spent running doomed lab experiments, etc. As you get later in the drug discovery pipeline you have a larger team built around the program, and then the artifacts are more helpful. There still isn't much of a norm in the biotech industry of having an engineering team support an advanced drug program (a mistake, IMO) so these artifacts go a long way given these teams don't have dedicated resources.

> Do you think this pattern (LLM exploration > traditional tools) generalizes outside domains with high uncertainty?

I don't know for sure, as I don't live in that world. My instinct is: I wouldn't necessarily roll something like this out to external customers if you have a well-defined product. (IMO there just isn't that much of a market for uncertain outputs of such products, which is why all of the SaaS companies that have launched their integrated AI tools haven't seen much success with them.) But even within a domain like that, it can be useful to e.g. your customer support team, your engineers, etc. For example, one of the ideas on my "cool projects" list is an SRE toolkit that can query across K8s, Loki/Prometheus, your cloud provider, your git provider and help quickly diagnose production issues. I imagine the result of such an exploration would almost always be a new dashboard/alert/etc.

[0] https://github.com/sparfenyuk/mcp-proxy - don't know much about this repo, but it was our starting point