lunar_mycroft

The difference between what the employer makes per employee and what they spend in compensation doesn't matter. If the increase in productivity isn't greater than the increase in cost, there isn't a reason to pay for AI over hiring more developers.

Imagine an employer with 10 employees paying $500k per employee and making $2M per employee in revenue (to use your numbers). They could hire two more employees and spend an extra $1M (+20%), but make an extra $4M in revenue (+20%). Alternatively, they could buy all ten employees a $100k AI subscription, for a total of $1M extra spending (+20%) but an extra $4M in revenue (+20%). You'll notice both scenarios are identical, so an employer optimizing for profit would have no reason to prefer one over the other.

That will be clamped down on by Anthropic (and other providers) for the same reason they don't offer those plans to enterprise customers already.

Do people commonly argue Waymo isn't subsidizing rates?

Also, we do have some evidence for my position:

- We know that the consumer Claude plans provide _way_ more tokens than you could get if you were paying API prices. This is a huge part of why Anthropic's limits on other harnesses for subscription customers is such a big deal. So either their profit margin on API tokens is absurdly high, most consumer subscribers don't come anywhere near their rate limits, or they're losing money on the consumer subscriptions. - It appears that complains about people running into rate limits are common, which suggests the "consumers usually don't use much of their subscription" explanation is incorrect. - We also know that Anthropic has just become profitable, almost certainly driven mostly by enterprise customers. This rules out the "they make a very high profit margin on the API" explanation, since if that was the case they'd likely have been profitable much earlier.

Taken together, I think the case that their consumer subscriptions lose them money on net is pretty strong, even though their enterprise subscriptions (and API pricing) does make them a profit.

Right, they can do it to sell enterprise plans, but they can't offer said plans to those enterprise customers indefinitely. So if your employer wants to spend $200/month on tokens, you're going to get however many tokens $200 buys you each month, not the order of magnitude more you can get with a consumer subscription.

The $200 plan you're talking about is subsidized by Anthropic. They cannot afford to keep offering that to everyone indefinitely. Absolute best case scenario for current users is that they can continue to subsidize it as way to sell enterprise plans, but there's no way that they can keep offering it to everyone at those prices.

That might make sense (at least on the first order, second order effects would still be horrible) if the LLM generated answer was reliably correct. It isn't.

If the LLM is capable of providing good citations, then those citations could be returned in the same format as traditional search engines, not the new, LLM generated content first format. If they aren't capable of providing good citations, then the suggestion I was replying to is incorrect (and you'd have no way of knowing if they were right or not)

If I have to read the sources anyway, why not just have the model give me the links themselves? You know, like search engines already do?

It's an alternative in the same way e.g. plain markdown is an alternative to HTML, even though plain markdown lacks some of the features of HTML. "X is an alternative to Y" in this sense doesn't mean "X all the same features of Y", it means "you might reasonably choose to use X instead of Y, depending on your exact usecase"

"{Feature} is the whole point of {more complex technology}" is an objection that can very often be raised. That doesn't mean that giving up features in exchange for simplicity is always the wrong call. And there's also advantages to having the user drive what instructions go into the prompt instead of the harness/model.

Skills are notably more complex than that. They require metadata (which the model is given and uses to determine whether or not to load the main file), are intended to be loaded via a tool call, contain extra resources (also loaded by tool calls), etc. In contrast, with this system the harness doesn't need a tool to load the stored prompts, the prompts don't need to include metadata to allow for runtime discovery, etc.

This is also incorrect. It's often not ethical to cause harm, and it can be counter productive in the right circumstances, but there's absolutely nothing that makes "causing harm to others" always be against an intelligence's goals. Humans, for example, routinely cause harm to other species. Sometimes this is deliberate, but other times it's because we're barely even aware we're doing so. We want a new road, so we start paving, and may not even realize there was an ant hill in the way (and if we did, we almost certainly wouldn't care).

Their own survival, not necessarily the survival of others (especially others of different species and/or conflicting other goals). A super intelligence having self preservation as a goal wouldn't help us keep it from harming us, if anything it would do the opposite.

I've seen the code these models produce without a human programmer going over the results with care. It's still slop. Better slop than in the past, but slop none the less. If you aren't at minimum reading the code yourself and you're shipping a significant amount of it, you're either effectively the first person to figure out the magic prompt to get the models to produce better code, or you're shipping slop. Personally, I wouldn't bet on the former.

A corollary to the linked article is that a specification can also have bugs. Having a specification means that you can (in theory) be sure you have removed all inconsistencies between that specification and the source code, but it does not mean you can know you have removed all bugs, since both the spec and the source code could have the same bug.

In some ways these methods are similar to the model "learning", but it's also fundamentally different than how models are trained and how humans learn. If a human actually learns something, they're retain that even if they no longer have access to what they learned it from. And LLM won't (unless trained by the labs not to, which is out of scope). If you stop giving it the instructions, it won't know how to do the thing you were "teaching" it to do any more.

1. Interns learn. LLMs only get better when a new model comes out, which will happen (or not) regardless of whether you use them now.

2. Who here thinks that having interns write all/almost all of your code and moving all your mid level and senior developers to exclusively reviewing their work and managing them is a good idea?

> I really don't understand the "stop telling me I'm holding it wrong" argument. You probably are holding it wrong!

I can't speak for others, but from my end it really seems like there's no actual way to detect whether someone is holding it right or wrong until after the implications for LLMs are known. If someone is enthusiastic about LLMs, we don't see claims that they're holding it wrong. It's only if an LLM project fails, or someone tries them and concludes they don't work as well as proponents say, that the accusations come out, even if the person in question had been using these tools for a long time and previously been a supporter. This makes it seem like "holding it wrong" is a post hoc justification for ignoring evidence that would tend to contradict the pro-LLM narrative, not a measurable fact someone's LLM usage.

What you've experienced is different from what was originally mentioned though. Even with the best human developers, you can't provide a normal natural language prompt and get back the exact code you would have written, because natural language has ambiguities and the probability that the other person (or LLM) will resolve all of them exactly as you would is approaches zero.

Collaborating with someone/something else via natural language in a programming project inherently trades control for productivity (or the promise of it). That tradeoff can be worth it depending on how much productivity you gain and how competent the collaborator is, but it can't be avoided.

It's impossible for human developers too. Natural language descriptions of a program are either much more painful and time consuming to write than the code they describe, or contain some degree of ambiguity which the thing translating the description into code has to resolve (and the probability of the resolution the entity writing the description would have chosen and the one entity translating it into code chose matching perfectly approach zero).

It can make sense to trade off some amount of control for productivity, but the tradeoff is inherent as soon as a project moves beyond a single developer hand writing all of the code.

Not a scientific study, but someone did replicate the experiment on themselves [0] and found that in their case, any effect from LLM use wasn't detectable in their sample. Notably they almost certainly had more experience with LLMs than most of the METR participants did.

[0] https://mikelovesrobots.substack.com/p/wheres-the-shovelware...

None of those changes address the issue jdlshore is pointing out: self assessed developers productivity increases from LLMs are not a reliable indication of actual productivity increases. It's true that modern LLMs might have less of a negative impact on productivity or increase it, but you won't be able to tell by asking developers if they feel more productive.

(Also, Anthropic released Claude Code in Febuary of 2025, which was near the start of the period the study ran).

> Who told the agent to write the blog post though? I'm sure they told it to blog, but not necessarily what to put in there.

I don't think it matters. You as the operator of the computer program are responsible for ensuring (to a reasonable degree) that the agent doesn't harm others. If you own a ~~viscous~~ vicious dog and let it roam about your neighborhood as it pleases, you are responsible when/if it bites someone, even if you didn't directly command it to do so. The same applies logic should apply here.

StrongDM is attempting that. The code they produced is not inspiring confidence on a relatively small scale [0], and based on what I saw with a cursory inspection I very much doubt I wouldn't find much deeper issues if I took the time to really dig into their code.

Don't get me wrong, "sort of works if you squint at it" is downright miraculous by the standards of five years ago, but current models and harnesses are not sufficient to replace developers at this scale.

[0] https://news.ycombinator.com/item?id=46927737

To pick a few (from the server crate, because that's where I looked):

- The StoreError type is stringly typed and generally badly thought out. Depending on what they actually want to do, they should either add more variants to StoreError for the difference failure cases, replaces the strings with a sub-types (probably enums) to do the same, or write a type erased error similar to (or wrapping) the ones provided by anyhow, eyre, etc, but with a status code attached. They definitely shouldn't be checking for substrings in their own error type for control flow.

- So many calls to String::clone [0]. Several of the ones I saw were actually only necessary because the function took a parameter by reference even though it could have (and I would argue should have) taken it by value (If I had to guess, I'd say the agent first tried to do it without the clone, got an error, and implemented a local fix without considering the broader context).

- A lot of errors are just ignored with Result::unwrap_or_default or the like. Sometimes that's the right choice, but from what I can see they're allowing legitimate errors to pass silently. They also treat the values they get in the error case differently, rather than e.g. storing a Result or Option.

- Their HTTP handler has an 800 line long closure which they immediately call, apparently as a substitute for the the still unstable try_blocks feature. I would strongly recommend moving that into it's own full function instead.

- Several ifs which should have been match.

- Lots of calls to Result::unwrap and Option::unwrap. IMO in production code you should always at minimum use expect instead, forcing you to explain what went wrong/why the Err/None case is impossible.

It wouldn't catch all/most of these (and from what I've seen might even induce some if agents continue to pursue the most local fix rather than removing the underlying cause), but I would strongly recommend turning on most of clippy's lints if you want to learn rust.

[0] https://rust-unofficial.github.io/patterns/anti_patterns/bor...

I've looked at their code for a few minutes in a few files, and while I don't know what they're trying to do well enough to say for sure anything is definitely a bug, I've already spotted several things that seem likely to be, and several others that I'd class as anti-patterns in rust. Don't get me wrong, as an experiment this is really cool, but I do not think they've succeeded in getting the "dark factory" concept to work where every other prominent attempt has fallen short.

LLMs can regurgitate almost all of the Harry Potter books, among others [0]. Clearly, these models can actually regurgitate large amounts of their training data, and reconstructing any gaps would be a lot less impressive than implementing the project truly from scratch.

(I'm not claiming this is what actually happened here, just pointing out that memorization is a lot more plausible/significant than you say)

[0] https://www.theregister.com/2026/01/09/boffins_probe_commerc...

Probably, but not necessarily. Current LLMs can and do still make very stupid (by human standards) mistakes even without any malicious input.

Additionally:

- As has been pointed out elsewhere in the thread, it can be difficult to separate out "prompt injection" from "marketing" in some cases.

- Depending on what the vector for the prompt injection is, what model your OpenClaw instance uses, etc. it might not be easy or even possible to determine whether a given transfer was the result of prompt injection or just the bot making a stupid mistake. If the burden of proof is on the consumer to prove that it as prompt injection, this would leave many victims with no way to recover their funds. On the other hand, if banks are required to assume prompt injection unless there's evidence against it, I strongly suspect banks would respond by just banning the use of OpenClaw and similar software with their systems as part of their agreements with their customers. They might well end up doing that regardless.

- Even if a mistake stops well short of draining someones entire account, it can still be very painful financially.

I'm not a lawyer, but if I'm reading the actual regulation [0] correctly, it would only apply in the case of prompt injection or other malicious activity. 1005.2.m defines "Unauthorized electronic fund transfer" as follows:

> an electronic fund transfer from a consumer's account initiated by a person other than the consumer without actual authority to initiate the transfer and from which the consumer receives no benefit

OpenClaw is not legally a person, it's a program. A program which is being operated by the consumer or a person authorized by said consumer to act on their behalf. Further, any access to funds it has would have to be granted by the consumer (or a human agent thereof). Therefore, baring something like a prompt injection attack, it doesn't seem that transfers initiated by OpenClaw would be considered unauthorized.

[0]: https://www.consumerfinance.gov/rules-policy/regulations/100...

I think if you care about privacy and security, you wouldn't run moltbot in the first place (or wouldn't give it access to anything you wanted to keep private).