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 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.

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 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.

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

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

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.

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

- 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'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...

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.

> 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...

No, that isn't. To quote your own blog, his job is to "deliver code [he's] proven to work", not to manage AI agents. The author has determined that managing AI agents is not an effective way to deliver code in the long term.

> you don't have the agent-managerial skills to tell the coding agents how to clean up the mess they made

The author has years of experience with AI assisted coding. Is there any way we can check to see if someone is actually skilled at using these tools besides whether they report/studies measure that they do better with them than without?