One thing I found was tool calling in GLM 5.2 on github using Claude Code was mostly failing then fixing. But I didn't compare to z.ai's harness. (Nothing to do with Deepseek, sorry.)
Interesting points. Building on your "bits of freedom" point, given they are doing this to comply with the EU AI Act, it's also possible that the algorithm is quite weak. And they could play all kinds of games, such as embed it in the session data overall, not just the output (I don't know any details, so just guessing).
And thinking out loud, they could be really horrible and embed by using unicode characters instead of ascii, which would give a lot of flexibility, but would make the result almost unusable (but easy to defeat).
I've been building a triage agent for my inbox and whatsapp (it's product shaped), which has ironically left me not building one of these. So even while productizing, I'm getting fomo on the full monty.
I've also been building a harness that maintains my apps which I'm hoping to open source.
Hard agree that these things don't have personal ROI, and are actually quite hard to build reliably.
But it's really fun! And having a bot fix a live error is pretty exciting.
I've been running auto-mode for quite a while. The main thing that pushed me over the edge was constantly being prompted in the accept-edits mode because of back ticks or backslashes in tool calls. There was no way to approve those preemptively so I was just sitting there saying approve, approve, approve and having to babysit CC.
With self-driving agents, the costs stop being evident as you go, and show up after the fact. I've been building governors that slow the agents down, and then also look at odd things some of the harnesses do, such as constantly making mistakes in tool calls.
But overall, it's quite a task, and you really have to decide what you are prioritizing for. Do I want my agents doing lots of work, or (in my case), leaving some of my subscriptions available for me to do work.
I think LLM policies which ban usage are ultimately self-defeating. They neatly switch concerns about quality of contributions to concerns about "AI slop". These two things are not the same. But the biggest problem is that they ignore the (unevenly distributed) future.
The future: SWEs will no longer write code by hand. The era of hand coding is over. We only saw that for sure in the last 6 - 9 months. But it's over.
Many coders have not yet made this transition, true, but it's happening regardless. You may not like it, but as a coder, you will not be hired if you refuse these tools. You will look as ridiculous as an accountant that refuses to use spreadsheets.
For now, we're not there yet.
As a profession, we are learning how to deal with the massive influx of review work that occurs because of LLMs. The bottleneck has moved. And as of now, there aren't good answers. But there will be. We will figure it out, like we figured out CI/CD and agile.
So personally, I'd focus my policies much more on dealing with the issues that this new era presents, and how to make LLM contributions work, and I'd avoid banning LLMs.
Thanks, but I did read the policy. This is what they say: "It's fine to use LLMs to answer questions, analyze, distill, refine, check, suggest, review. But not to create."
And later:
"There are very strict guidelines on LLM-generated code changes:
Pre-arranged, non-critical, high-quality, well-tested, and well-reviewed code changes that are originally created by an LLM are allowed, with disclosure."
That's a pretty limited wedge of allowed cases in my opinion.
