LLM 批评者说得对，但我还是会用 LLM

无聊也很棒 | UMH 联合创始人兼首席技术官

我几乎同意所有对大语言模型（LLM）的批评，但我仍然大量使用 LLM。我知道这听起来像我在自欺欺人，而且因为这种认知失调，我有时也会有这样的感觉，但我认为我并不是唯一一个有这种感受的人。

本周我在柏林参加了 Local-First 会议，这种认知失调无处不在。Armin Ronacher 刚刚做了一场关于构建机器实体的演讲。他创建了 Flask，并且是 Sentry 早期团队成员之一，所以他显然是一位优秀的软件工程师。最近，他创立了自己的公司 Earendil，开发 Pi.dev，这是一个“开源编码代理框架”。演讲后，你可以通过 Discord 提问，问题会在舞台上被念出，我问道：

你们会接受 Pi 的 PR 吗，或者你们如何处理来自 LLM 的大量 PR？

他当场在全体观众面前回答说，他们几乎自动关闭所有 PR 和问题。但不应该因为这个而气馁去提交 PR，因为人类的价值总会显现。

所以不仅是我，显然一些非常聪明的工程师也是如此。那些为 LLM 构建工具的人自己也被自己的创造所淹没，为了保护自己，他们几乎自动关闭所有请求。在他们的宗旨页面上写着：

在一个向 AI 急速发展的世界里，我们相信人类是最好的执行者。

当我坐在观众席上时，我看到很多人打开了 Claude Code。而讲者会说出这些对 LLM 的批评性话语，并且会得到热烈的掌声。即便是那些打开 Claude Code 的人也是如此。

我自己也在那次会议上做了演讲，后来和一些人交谈时，他们描述的感受与我非常相似，这让我感到宽慰，因为我知道我并不孤单。

所以这篇文章是我尝试去描述这种感受。我会先梳理所有公平且合理的关于使用 LLM 的担忧，这些内容会得到热烈掌声。然后我会解释为什么我仍然使用 LLM。最后，我会总结一些我发现的模式，希望通过提供具体示例，其他人也可以加入进来描述他们的体验，以便我们可以共同更好地理解这种认知失调。

昨天的一些谈话印象 @adamwiggins.com @martin.kleppmann.com @stevenruiz.bsky.social @jakelazaroff.com

仅仅通过听人们的讲座或阅读 HN，我觉得我对为什么某些人拒绝使用 LLMs 有了相当好的理解。更奇怪的是，我几乎同意他们所有的观点！

让我逐一讲解最重要的几点。

先从最常见的批评开始：“LLMs 产生大量低质内容”。

如果你看看开源软件，你会发现越来越多的仓库和项目要么直接拒绝所有类型的贡献，要么试图在前面设置某种过滤器。类似于 Armin 和 Earendil 通过自动关闭所做的事情。

我认为核心问题是信任。无论如何，你永远不应该信任互联网上的陌生人。但在 LLM 出现之前，有一个基础点：创建一个带有适当描述的正确 PR 至少需要一些人工时间，因此可以阻挡恶意用户和低质量提交。或者至少你可以在几秒钟内轻松过滤掉它们。即使有新用户加入，你也可以信任这个人至少会花几个小时处理它。然后它可能值得你更仔细地查看。

这个基础点现在不再成立了。每个人都可以轻松创建一个新的 GitHub 账户并让其 LLM 自由发挥，作为维护者，你无法轻易判断某人是不是在 PR 上花了大量时间（也可能只是使用 Claude 完成 PR 描述），也无法判断这是否只是 OpenClaw 机器自行操作。像 Zig 或 Gentoo 这样的项目已经拒绝接受 LLM 生成的 PR（我认为这不是解决方案，因为你根本分辨不出来？）

我认为如果我们找不到恢复信任的方法，LLMs 可能会严重威胁开源软件。一个想法可能是只允许一小部分经过验证的人向项目贡献，而为了获得验证，你需要参加真实的线下聚会之类的活动。

然后是关于初级工程师的情况。这里实际上有两个不同的点：a) 你不再能信任初级工程师代码背后的努力，b) 高级工程师也没有了教导初级工程师的动力。

让我们从 a) 开始：资深人员一直在纠正和修复初级人员的代码。而初级人员总是写出一些很糟糕的代码（我写的最糟糕的代码是在 LLM 出现之前写的）。只不过现在作为资深人员在审查时，你不知道那个初级人员是仅仅用 10 分钟随便写写，还是坐在那里几个小时但确实缺乏一些好的见解。

再说 b)，教学，也就是“我们如何教新人？”：以前，有这种平衡，即“初级人员做一些比较枯燥的任务，但资深人员会和他一起审查并帮助他成长”。而现在作为资深人员，你已经不再需要初级人员。枯燥的任务，至少我发现很多人对此都赞同，可以完全外包给 LLM。那么为什么还要招聘初级人员呢？

然后是地缘政治紧张局势。如果中国或美国一夜之间切断我们对这些技术的访问会发生什么？就在几周前，美国政府就展示了它有能力也愿意切断非美国公民访问 Anthropic 最新前沿模型的权限。

Anthropic 自己的声明，2026 年 6 月 12 日：美国的出口管制指令迫使他们突然对所有客户禁用 Fable 5 和 Mythos 5。

我不想在这里做末日预言。我认为 Martin Kleppmann 在他的演讲舞台上描述得相当好：

欧洲和美国之间发生冲突的概率仍然很低。但去年，它是零。

最后，即使只是使用 LLM 进行研究，它们也有一种自然倾向，会悄悄渗入大多数训练材料的观点，或者有时甚至是创造模型者的政治信念。

这就像两个在对话的人类：随着时间的推移，他们的观点会慢慢融合。有没有注意过那个总是用一个奇怪单词的朋友，然后几周后你整个朋友圈都在用它？就是这样，只是换成了观点。

而参与对话的一方不是人类。

但我们再也不能让它们完全消失。它们来了，而且会留下来。与其逆流而上，我们不如顺流而行，然后进行控制并塑造它。

例如，通过确保模型可以在你的笔记本电脑上运行。它们已经越来越好了，而且它们让我们程序员不再依赖这些大公司。当补贴结束，价格上涨时，正是那些开源权重模型在制衡大厂。并且在你自己的硬件上本地运行的模型，也不会被任何政府一夜切断。我甚至可以说，当泡沫破裂时，世界经济将受到很大损害，许多公司会倒闭。但开源权重模型不会消失，所以我们程序员可以依靠它们。即使在会议上，那些关于 AI 的演讲，大多也认真对待了本地模型。

想象一下：你会有这样一个科幻般的 AI 在后台运行，你可以随时问它问题，它也会随时回答你。就像《星际迷航》之类的场景。

在很多演讲中，AI 只是顺带提了一下：“我们用 Claude Code 做的这个。”有些演讲者甚至公开说：“是的，我只是把它交给 Claude Code 就好了。”但他们的演讲被接受了，并且得到了观众的热烈掌声，其中包括一些非常资深和受人尊敬的人。

关键是有人把他们的信誉站在了前面。那才会让你认真听。如果他们展示了一些 AI 做得马马虎虎的东西，他们就会失去信誉。我认为这让他们以不同的方式使用 AI。他们说：“我只是让 Fable 5 去实现它。”听起来像一个科技狂热者。我也会这么描述。但我只能说这是我的猜测，我只能代表我自己：他们并没有让大型语言模型去思考。那是他们的想法，现在被超级强化了。

大型语言模型会放大你已有的东西：观点、结构、框架。如果你有想法，它们会更快、更清晰地呈现出来。它们擅长帮助头脑风暴、检查语法、迭代句子、提供替代方案、充当橡皮鸭或反方角色。如果你什么都没有，那么就算再流畅，也什么都不会出现。大型语言模型擅长产生大量看起来不错的内容，但没人会在观众面前大声读出来。

对我来说，价值就在这里：我可以简单地把事情做得比我自己单独做时更高质量。我可以用它做更多事情，但我用它来把更少的事情做得更高质量。我倾向于使用极多的 token，只为了给人类准备几句话。我认为这是 LLM 的一个好用途。而且我发现 LLM 能够在思考上支持你。

我非常同意书面文本应该是人类传达人类的观点。然而，我仍然用 LLM 写我所有的文本。我并不觉得这矛盾。“AI 垃圾”与“好写作”的区别在于是否有人类的思想投入。而思考是不能外包的。

但问题在于：是否有人类的思想投入，正是你从外部无法看到的。句子“我用 AI 更好地思考”，无论是我说还是某个随机 AI 技术宅说，字面上完全一样，你无法根据我说的话判断这是真是假。你根本无法做到。由于放大的废话听起来像天才，剩下的唯一办法就是信任。而信任很难建立，却很容易失去。尤其是在 LLM 时代。我自己也能看到：一个短横线居然能让整个内容失效，因为我会自问，这个人难道不想至少去掉明显的 AI 垃圾痕迹吗？

在会议的 Discord 里，在一次演讲期间，有人问其他人如何处理这种紧张关系：许多对地方优先政策感兴趣的人，同时也是坚决反对 LLM 的。他们在知道可能会被社区拒绝的情况下，用 LLM 开发软件会担心吗？有人回答说，包括当时台上的演讲者在内的多个演讲者，都在谈论关于这个问题的“复杂想法”。我认为这说明了很多问题：即使在这里，人们也害怕公开说他们使用 LLM。我也有点害怕说这一点：上个月我在 token 上花了将近 1 万美元。这听起来太疯狂了。

我 2026 年 6 月按模型的 token 开销，单位为美元，直接来自开销报告。我知道这很极端。从那以后我改变了两件事：我现在只非常有选择地使用 Fable，它实在太贵了。而对于纯代码执行，我使用 OpenRouter 和更便宜的模型如 GLM 5.2。

当人工智能刚出现时，我尝试使用它，但在某种程度上损害了自己的可信度。但后来我意识到，可信度就是你赢得信任的方式：你会站在台前朗读它吗？如果答案是“嗯，我会解释它的意思”，那就是敷衍。如果你会逐字逐句地朗读它，并且不为此感到羞愧：恭喜，这是好文本。

那么我如何使用它们呢？这里有一条难以解释的微妙界限，很难用语言描述，我认为只能通过亲身体验，从使用这些工具的过程中以开放的心态去学习。我知道这句话听起来像什么，这正是科技男们所说的。我甚至无法在不显得像他们的情况下邀请你去尝试。所以我会尝试描述我发现的一些模式。不是作为“这是如何做的”，而是希望澄清这个情况。

是的，如果它不了解实际问题和需求，它会写出糟糕的软件。有了正确的技能和工具，你可以制作出相当不错的软件。但在你和那个不错的软件之间，存在一个顺从性问题：它不会告诉你它哪里不理解，只会继续去做。这也是为什么/grill-me 技能（改编自 Matt Pocock 的“grill me”技巧）如此强大的原因。它非常简短：

说实话，grill-me 感觉很好。当我发现这个技能时，我对这样简单的东西竟然能产生如此大的影响感到非常兴奋。因为它迫使你逐个问题形成自己的想法。我从那时起把这种逐步的方法应用到所有事情上，这种在单句上花费极多 token 的方法，例如用来写文章。本文就是我混乱地写下我的想法，然后逐句接受 LLM 烤验的结果写成的。

每当我编写代码，即使是小事情，我也会遵循 Basecamp 的“Pitch”，并非常认真地思考简短的“问题”、“我们正在交付的内容”和“我们不交付的内容”。我强迫自己写出三句话的问题陈述。这非常容易，使用大语言模型（LLM）甚至更容易去填写。但要写得好却非常困难。我认为它在 LLM 工作流程中之所以非常有效，正是因为它是为人类设计的：三句话迫使我真正去阅读它们。如果我读了，其他人也能读懂。

我现在往往不会真正阅读大部分 LLM 输出；我只是浏览，看看我是否认同它。但三句话的问题陈述，我会非常仔细地进行事实核查。这就像代码审查：一段 1,000 行的代码审查通常只会得到“LGTM”。一段 100 行的代码审查会得到 15 条评论。

我对我的 PR 描述也同样注重细节：我花很多时间去确保它们保持可读、简洁，并始终描述实际问题、我们正在交付的内容以及我们不交付的内容。我还会添加运行截图，以给审查者一个明显的信号，表明值得与该 PR 互动，因为它显然是可工作的。但我必须总是与 Claude 在描述上进行较量，因为它总是会增加冗余。有时候如果 PR 不重要，我也会让 Claude 略微占上风。

你需要一些东西来对抗他们，以应对他们创造的大量内容。在我的编码工作流程中，我会使用较小的代理来抵消这种情况。

我喜欢的另一种技术（Ralph Wiggum 循环，或者现代叫 Claude 的 ultracode）是将 LLM 锁定在文本、计划、陈述、代码或其他内容中，然后不断生成子代理（带有新的上下文的 LLM），它们的唯一任务是拆解该上下文。它们会不断进行，直到被迫产生虚拟问题。然后我才会继续工作流程。

如果它们被迫产生虚拟问题，你实际上可以利用它们的弱点：它们试图与你达成共识，认为上下文中存在问题，但却找不到任何问题。

尤其是如果你将其与 /grill-me 技能结合使用，最终的结果是作为人类的你没有任何进一步的评论或想法，甚至连最微小的想法都没有。LLM 也尝试剖析你的想法，有时会烤你数小时，迫使你形成自己的想法。

甚至有一种方法利用幻觉本身：在去年的会议上，Anselm Eickhoff 介绍了如何让 LLM 幻觉它所期望的 API 或 UX：https://www.youtube.com/watch?v=e3-yIWGNBLQ，然后再向它展示真实的内容。无论它猜测什么，很可能也是大多数人会猜测的。所以你不是去对抗幻觉，而是利用它：作为一种廉价的测试，看看你的设计是否符合人们的预期。如果你想尝试，我也已将其构建为技能。

我的直觉探测技能：一个盲目的代理在看到真实内容之前就提交它所期望的设计。可以从 gist 免费获取。

不过，所有这些模式都有一个要求：我必须能够判断结果是否优秀。而我使用的 LLM 越多，我最终涉及的领域就越不熟悉。那时我就需要专家。因为我只能在理解的情况下编程。这就像委派任务：我只有在至少了解基础知识并知道什么是好的情况下，才会将任务委派给团队的其他成员。LLM 也是同理。

如果我对某件事非常了解，我可以快速分辨“好”和“绝对烂”。如果我对某件事了解不多，我使用 LLM 只是为了帮助我学习它。因为如果我在无法区分好坏时就使用它们，我最终会产生彻头彻尾的垃圾作品。

根据结果是否可以明确区分为好或坏，有两种学习方式。好或坏指的是：代码能否编译，测试套件是否通过，协议能否解码。不是指“代码好不好”，因为代码质量是另一回事。在有这样明确检查的领域，你可以让大语言模型（LLM）参与进来，一起学习。一次会议上有个人描述了他如何使用 Opus 4.6 逆向工程二进制文件和协议，他所需要的只是基本的逆向工程知识。他修改的二进制文件要么能工作，要么导致设备无法使用。结果是否正确很清楚，因此他甚至能够在过程中发现自己的技巧。

在有很多主观看法的领域，比如编程，LLM 只会告诉你大多数人想要的东西：最流行的技术，而它可能并不是你情况中最好的。

我们曾经有一次团队讨论，有人告诉我，代码是 AI 废料，这是一个通用 AI 的问题。当我们深入讨论时，结果发现他们不喜欢 TDD。但我们团队里还有另一个人在 LLM 时代之前就进行了大量的 TDD。于是，AI 废料就不再是 AI 废料的问题了。这是关于人类存在不同意见的问题。正如我所说，LLM 只是放大工具。用它们，你可以放大你的观点。在这里，你需要人类来大致指引方向，并提供好的初步意见，然后你可以用这些意见继续，直到能够独立进行。

我希望你能够信任我，如果你不信，我完全理解。你真正了解的唯一方法是参与我的内容，但这需要大量时间，所以我理解你可能不参与。但如果你此时仍在这里，你已经花了相当多时间阅读这篇文章。也许你已经意识到，这篇文章付出了很多努力，并不是一些显而易见的废话。

我并不孤单地面对这种认知失调。

单独写作并没有让我看到这一点。但在写作的过程中，我浏览了会议的 Discord，直接向会议上的人提问，并阅读了过去几周的 HN 文章。这让我看到了：其他人也在描述同样的不协调感。所以，也许其他人也可以描述他们的经历和学习路径，以阐明这条微妙的界线。

Boring is Awesome | Co-Founder & CTO at UMH

I almost agree with all of the LLM critics, yet I still use LLMs a lot. I know this sounds like I am delusional, and I also feel like that sometimes because of this dissonance, but I don’t think I am alone with it.

This week I was at Local-First Conf in Berlin, and the dissonance was everywhere. Armin Ronacher had just given a talk about building machine entities . He created Flask and was one of the early team members of Sentry, so he is clearly a good software engineer. Just recently he founded his company Earendil, which builds Pi.dev, an “open-source coding agent harness”. After the talk you could ask questions via Discord, which would be read out loud on stage, and I asked:

are you accepting PRs for Pi, or how do you handle the flood of PRs from LLMs?

He replied, live on stage, in front of the entire audience, that they auto-close almost all PRs and issues. But that one shouldn’t be discouraged from opening PRs, because the human will always shine through.

So it is not only me, but apparently some pretty clever engineers too. The people building a tool for working with LLMs are themselves flooded by their own creation, and in order to protect themselves they are auto-closing it all. On their purpose page it says:

In a world hurtling towards AI, we believe humans are the best agents.

When I was sitting in the audience, I could see a lot of people having Claude Code open. And then the speakers would say these critical things about LLMs, and they would get this big round of applause. Even from the people with their Claude Code open.

I spoke at that conference myself, and when I later talked to some of the people, they described the feeling as pretty similar to mine, which is a relief, because I know I am not alone with this.

So this article is me trying to describe it. I’ll start by going through all of the fair and valid concerns about using LLMs, the things that would get the big round of applause. Then I will explain what makes me still use LLMs. And I’ll finish up with some of the patterns I found, in the hope that by giving concrete examples, others can step in as well and describe their experiences, so we can all come together and get a better understanding of this dissonance.

A few impressions from yesterday‘s talks @adamwiggins.com @martin.kleppmann.com @stevenruiz.bsky.social @jakelazaroff.com

Just by listening to people or the talks or reading HN, I think I got a pretty good sense of why certain people refuse to use LLMs. And what makes it extremely weird is that I agree with almost all of their points!

Let me go through the biggest ones one by one.

Let’s start with the most common critique “LLMs produce a lot of slop”.

If you look at open source software, you will see more and more repos and projects either straight up refusing all types of contributions or trying to put some kind of filters in front of it. Similar to what Armin and Earendil are doing with their auto-closing.

I think the core issue here is trust. You should never trust random people on the internet anyway. But before LLMs, there was this base thing: creating a proper PR with proper descriptions would require at least some human time, so it would keep trolls and low quality submissions out. Or at least you could easily filter them out within a couple of seconds. So even if a new person came in, you could trust that this person would have at least spent a couple of hours on that. And then it was probably worth taking a closer look at it.

That base thing is not true anymore. Everyone can simply create a new GitHub account and let their LLM loose, and as a maintainer you cannot easily tell whether someone put a lot of time into the PR (and maybe used Claude for just the PR description), or whether it is just an OpenClaw machine acting on its own. Projects like Zig or Gentoo are already refusing to accept LLM generated PRs (which I don’t think is the solution, because how would you even tell?)

I think LLMs might have serious potential to kill OSS, if we don’t find ways to restore that trust. One idea could be to only allow a small set of verified people to contribute to a project, and in order to get verified you would need to go to a real-life meetup or something.

And then there is the situation about junior engineers. There are actually two different points in there: a) you cannot trust the effort behind your junior’s code anymore, and b) seniors have no incentive left to teach juniors.

Let’s start with a): Senior people have always corrected and fixed the code of junior people. And juniors have always written some pretty bad code (my worst code was written in the before-LLM times). It is just now that as a senior while reviewing you don’t know if that junior just vibecoded it in 10 minutes, or if he sat there for a couple of hours but is genuinely lacking some good insights.

And b), the teaching, aka “How do we teach new people?”: previously, there was this balance aka “the junior does some pretty mundane tasks, but for this the senior reviews it together with him and helps him to grow”. Now as a senior, you don’t need juniors anymore. The mundane tasks, at least I find that a lot of people agree with that one, can be fully outsourced to an LLM. So why hire juniors at all?

And then there are the geopolitical tensions. What happens if China or the US cut us off overnight from these technologies? Just a couple of weeks ago the US government showed it was able and willing to cut off non-US citizens from Anthropic’s latest frontier model .

Anthropic’s own statement, June 12, 2026: a US export-control directive forced them to abruptly disable Fable 5 and Mythos 5 for all customers.

I don’t want to be a doomsayer here. I think Martin Kleppmann described it on stage in his talk pretty well:

the probability of a conflict between Europe and the US is still very low. But last year, it was zero.

Last but not least, even when just researching with LLMs, they have the natural tendency to silently sneak in the thoughts of the majority of the training materials, or sometimes even the political convictions of the ones who created the model.

It is like two humans talking to each other: over time, their opinions will slowly merge. Ever noticed that one single friend who just keeps using this one weird word, and then a couple of weeks later your entire friend group is using it? It is like that, just with opinions.

And one of the participants of the conversation is not a human.

But we cannot make them go away entirely anymore. They are here, and they are here to stay. And instead of going against the flow, we can go with the flow, and then control it and shape it as well.

For example by ensuring models can run on your laptop. They are already getting better, and they make us programmers independent of these big corporations. And when the subsidies end and the prices rise, it is the open-weights models that keep the large vendors in check. And a model that runs locally on your own hardware cannot be cut off overnight by any government either. I would even make the argument that when the bubble bursts, there is going to be a lot of damage to the world economy, and a lot of companies will topple. But the open weights models are not going anywhere, so we programmers can fall back on them. Even at the conference, the talks that were about AI mostly took local models seriously.

Imagine: you would have this Sci-Fi AI running in the background, and you could always ask it questions, and it would always answer you. Like in Star Trek or something.

In many of the talks, AI appeared only as an aside: “we built this with Claude Code.” Some of the speakers even openly said “yeah, I just gave it to Claude Code”. But their talks got accepted, and they got a big round of applause from the audience, including from some pretty senior and well-respected people in there.

The main thing is that there are humans who put their credibility on the line. And THAT makes you listen. If they presented something with AI slop they would lose their credibility. And I think that makes them use AI differently. They say: “I just asked Fable 5 to implement it.” It sounds like a tech-bro. And it is exactly how I would describe it too. But I am guessing here, and I can only speak for myself: they are not letting the LLM do the thinking. It is their thoughts, now supercharged and put on crack.

LLM’s amplify what you already have: opinions, structure, frameworks. If you have thoughts, they come out sharper and faster. They are good at helping with brainstorming, checking your grammar, iterating on sentences, giving alternatives, acting as a rubber ducky or a devil’s advocate. If you have nothing, nothing comes out, very fluently. LLMs are good at producing massive amounts of content that looks good, but that nobody would read out loud in front of an audience.

And this is where the value is for me: I can simply make things higher quality than I could do them alone. I can do way more with it, but I use it to make fewer things more high quality . I tend to use an extreme amount of tokens, just to prepare a couple of sentences for a human. I think this is a good use of LLMs. And I find very much that LLMs can support you in thinking .

I strongly agree that written text should be from humans to humans. Yet I still write all of my texts with LLMs. And I don’t find that contradictory. What distinguishes “AI slop” from “good writing” is whether a human has put thoughts behind it. And you cannot outsource thinking .

But here is the problem: whether a human has put thoughts behind it is exactly the thing you cannot see from the outside. The sentence “I use AI to think better” is word for word the same coming from me and from some random AI tech-bro, and there is no way for you to tell, based on what I am saying, if it is bullshit or not. You simply cannot. Since amplified bullshit sounds like genius, all that’s left is trust. And trust is difficult to gain, and easy to lose. Especially in the era of LLMs. I see it myself: a single em dash can somehow invalidate the entire thing, as I catch myself thinking, didn’t the person want to at least remove the obvious signs of AI slop?

In the conference Discord, during one of the talks, someone asked how the others deal with the tension: a lot of people who are politically interested in local-first are also staunchly anti-LLM. Did it worry them to make software with LLMs, knowing it might get rejected by the community? Someone answered that a number of speakers, including the one on stage at that moment, had been saying “complicated thoughts” about exactly this. And I think that says a lot: even here, people feared saying out loud that they use LLMs. I am a little bit scared to say this too: last month I spent almost 10k USD on tokens. It sounds so insane.

My June 2026 token spend by model, in USD, straight from the spend report. I know it was extreme. I have since changed two things: I use Fable only very selectively now, it is just too expensive. And for pure code execution I work with OpenRouter and cheaper models like GLM 5.2.

When AI was new and I was trying it out, I partly ruined my own credibility with it. But then I realized that credibility is how you earn the trust: would you stand in front of an audience and read it out? If the answer is “well, I would explain what was meant by it”, then it is slop. If you would actually read it out, word by word, and not be ashamed of it: congratulations, it is a good text.

So how do I use them? There is this unexplainable fine line that is hard to describe, and I think it can only be experienced, learned from using these tools with an open mind. I know how this sentence sounds. It is exactly what the tech-bros say. I cannot even invite you to try it without sounding like them. So I will try to describe some of the patterns I found. Not as a “this is how to do it,” but in the hope of clarifying the situation.

Yes, it will write bad software if it doesn’t understand the actual problem and the requirements. With the right skills and tools, you can produce some pretty decent software. But between you and that decent software stands agreeableness: it will not tell you when it didn’t understand something, and just go ahead and do something. This is also why the /grill-me skill, adapted from Matt Pocock’s “grill me” technique , is so extremely powerful. It is extremely short:

And honestly, the grill-me feels good. When I found this skill, I was absolutely excited about how something so simple can have such an impact. Because it forces you to form your own thoughts, question by question. I have since adopted this step-by-step approach for everything, this spending-an-extreme-amount-of-tokens-on-a-single-sentence kind of approach, for example for writing articles. This article here was written by me chaotically writing down my thoughts, and then going sentence by sentence, getting roasted by the LLM.

Whenever I code something, even for minor things, I follow the Basecamp “Pitch” and think really, really hard about a short “Problem,” “What we are shipping,” “What we are not shipping.” I force myself to write a problem statement of three sentences. It is incredibly easy, and even easier with LLMs, to fill this out. But it is incredibly difficult to make it good. I think this works so well in an LLM workflow precisely because it was designed for humans: three sentences force me to actually read them. And if I read them, another human can also read them.

I tend not to actually read most LLM output anymore; I skim it, to check if I vibe with it. But a problem statement of three sentences, that I will fact-check really hard. It is like code review: a review with 1,000 lines of code gets an “LGTM”. A review with 100 lines gets 15 comments.

The same care goes into my PR descriptions: I spend a lot of time on them, to ensure they remain readable, are concise, and always describe the actual problem, what we are shipping, and what we are not shipping. And I add screenshots of it working, to give the reviewer an obvious sign that it is worth interacting with this PR, as it is clearly working. But I have to always fight with Claude about the descriptions, as it keeps adding slop to them. And sometimes I just let Claude win too much there, if it is not an important PR.

You need something against them, to counter the large amount of stuff they create. In my coding workflow I put in smaller agents that counteract that.

Another technique I like (the Ralph Wiggum loop , or more modernly Claude’s ultracode ) is to lock the LLM in with a text or plan or statement or code or whatever, and keep spawning subagents (LLMs with a fresh context) with their only task to rip apart the context. And they keep doing it, until they are forced to hallucinate problems. And only then do I continue with the workflow.

If they are forced to hallucinate, you can actually use their weakness: they are trying to agree with you that there are problems in there, but they cannot find any.

Especially if you combine it with the /grill-me skill, you end up with a result where you as the human have no further comments or thoughts, not even the most minor thought. The LLM has tried ripping apart your thoughts as well, and sometimes roasted you for hours, and forced you to form your own thoughts.

There is even a way to use the hallucinating itself: at last year’s conference, Anselm Eickhoff described how you can let an LLM hallucinate the API or the UX it expects：https://www.youtube.com/watch?v=e3-yIWGNBLQ, before showing it the real thing. Whatever it guesses is probably what most humans would guess too. So instead of fighting the hallucination, you use it: as a cheap test of whether your design matches what people expect. I have built this into a skill as well , if you want to try it.

My intuition-probe skill: a blind agent commits the design it expects before seeing the real thing. Free to grab from the gist.

All of these patterns have one requirement, though: I need to be able to tell whether the result is any good. And the more LLMs I use, the more I end up in fields I do not know well. And then I need experts. Because I can only program things if I understand them. It is like delegating : I only delegate a task to another member of my team if I at least understand the basics and know what good is. Same for LLMs.

If I know something very well, I can quickly tell “good” and “absolute dogshit” apart. And if I know something not well, I use LLMs only to help me learn it. Because if I use them while I cannot yet distinguish good from dogshit, I will end up with full-blown slop production.

There are two ways to learn, based on whether the result can be clearly differentiated as good or bad. Good or bad as in: the code compiles or it does not, the test suite is green or it is not, the protocol decodes or it does not. Not as in “the code is good,” because code quality is a thing. In fields with such a clear check, you can point the LLM at it and learn together. One guy at the conference described how he reverse-engineered binaries and protocols using Opus 4.6, and the only thing he needed was basic knowledge of reverse engineering. Either his patched binary worked, or it bricked the device. It was clear whether the result was correct or not, so he could even find his own techniques along the way.

In fields where you have a lot of opinions, like programming, the LLM will just tell you what most people would want: the most popular technique, which is maybe not the best one for your case.

We had a team discussion once, where people were telling me code was AI slop, and that it was a general AI problem. When we went into it, it turned out they didn’t like TDD. But we had another one on the team who did a lot of TDD long before the age of LLMs. So suddenly, AI slop wasn’t about AI slop anymore. It was about humans having different opinions. And like I said, LLMs only amplify. With them, you can amplify your opinion. Here you need humans, to point you roughly in the right direction and give you good starting opinions, which you use until you are able to continue on your own.

I hope that you can trust me, and I fully understand if you don’t. The only way for you to really know is to engage with my content, but that takes a lot of time, so I understand if you don’t. But if you are still here at this point, you have already engaged with this text for quite a while. And maybe you already know that a lot of effort went into this article, and that it is not some obvious slop.

I am not alone with this dissonance.

Writing alone did not show me that. But while writing, I looked through the Discord of the conference, I asked people at the conference directly, and I went through the HN articles of the past weeks. That showed me: other people, describing the same dissonance. So maybe others can describe their experiences and learning paths as well, to clarify this fine line.