dpc

AI, Tau, and Software Architecture

2026-07-24T00:00:00+00:00

I recently joined a podcast to talk about my shift from AI skeptic to what I jokingly call “AI psychosis mode.” We discussed building Tau</a>, treating coding agents as powerful tools that demand equally serious safety measures, and why good software architecture matters even more when AI can produce code so quickly.</p>

We also touched on boutique software: small, focused tools shaped around their users rather than the broadest possible market.</p> </iframe>

He Went to the Slop Side

2026-07-22T00:00:00+00:00

The Slop Side of Code is a pathway to many abilities some consider to be… unnatural.</p> </blockquote>
Not much we can do now. Should have stopped or warned him while it was still early. It started so innocently. He was only doing Slop recreationally, in small doses</a>. He thought he could stop at any time... just review every change and you're safe, right? Yeah, right. Now he's gone, and this post is probably AI-generated.</p>
Stop crying. Here, have some em dashes to wipe your tears with: —, —, —.</p>
I will tell you why. He told me. The Slop made him feel young again. Like he was a noob and didn't know what he was doing at all</em>. Everything felt so new again—full of questions, challenges, and possibilities. And he just couldn't resist the power. To command these... golems—or clankers, as he called them—was to have a personal army at his disposal. I know—unnatural, foul creatures they are. But he said he took a liking to them... He found them... delightful—hah!—and funny. They were funny when they were impressive, and they were funny when they failed spectacularly. Their unpredictability was an irresistible counterpoint to the hard, cold determinism of everything he was used to.</p>
And now he has his own harness to command them</a> and methods to control and bind them</a>, and he is using his newly acquired powers to rapidly deepen his integration with them</a>.</p>
So that's why I'm here. To warn you that he went Full Slop. And I don't think he is ever coming back. He swears he's fine and has never been better, but I think his demise is certain. It's just a matter of time.</p>

LLM Reviews in cargo-crev

2026-04-12T00:00:00+00:00

There has been lots of chatting about software supply chain security recently, motivated by popular package exploits.</p>
Well, I have some relevant news: cargo-crev</a> now supports LLM-assisted code reviews. Go try it!</p>
Read on to get more information and background.</p>
History
#</a> </h2> Just a few weeks ago I was reading some articles about new LLM models finding non-trivial security issues, and Linux kernel and curl developers admitting that after a deluge of mostly worthless slop security reports they used to complain about, now they tend to receive actually worthwhile AI-assisted bug and security reports. It reminded me about cargo-crev</code> and I realized that AI can actually fill the gap that made me doubt it.</p> I'm not trying to overhype LLMs. But the fact is that they can do, and in high volume, what developers themselves have no time for: the 90/10 security scanning that was otherwise quite hard to automate.</p> An LLM can easily and reliably check if a code version published on https://crates.io matches the code published in git.</p> An LLM can easily scan build.rs</code> and the rest of the code and look if anything looks out of place.</p> It is actually very hard to hide key-stealing malware in a package that was supposed to format units, etc.</p> Especially in Rust, doing things that are wrong or out of place creates a lot of noise, making such code easy to notice, even by an LLM reviewer.</p> It might not be a silver bullet, but it is definitely better than doing nothing.</p> How to use it#</a> </h2> Note: In the initial release cargo-crev</code> supports only Claude Code agent. If you're interested in adding support for other coding agents, it should be relatively easy — most scaffolding is already there. Feel free to chat and create a PR.</p> Since version 0.27 cargo-crev</code> has a built-in review loop.</p> cargo crev ai review-loop --iterations 10</span></span></code></pre> which will start the agent 10 times, each time selecting and reviewing a single dependency.</p> The agent will produce&update a single shell script that can be used to conveniently review and sign all reviews.</p> While the above is meant as a standard mass-review flow, the core built-in agent review skill is available as an output of:</p> cargo crev ai skill review</span></span></code></pre> and it should be easy for anyone to modify it and/or build their own LLM-assisted workflows.</p> How it works#</a> </h2> The core change is that Crev's reviews now have fields to indicate that an LLM was used for the review</a>.</p> The rest is just relatively minor functionality to make producing LLM reviews convenient end to end.</p> For people skeptical of LLMs, options to ignore LLM-generated reviews have been and will be added where appropriate. You can just ignore the slop reviews if you don't trust them, fine with me.</p> How well</em> it works#</a> </h2> While working on this feature and testing it myself, I have produced quite a few LLM-assisted reviews</a>. Judge by yourself.</p> To me these meet the bar of being useful. And they turned some spare capacity from my Claude subscription into something that I otherwise would not be able to do myself.</p> Summary#</a> </h2> This is only an initial attempt at harnessing the AI in cargo-crev. There still might be lots of things to improve and extend, but we have to start somewhere.</p> If you like the idea and find it promising, I encourage you to try it out, give some feedback, and submit improvements.</p>
I don't want your PRs anymore 2026-04-06T00:00:00+00:00 I really appreciate that you're enjoying the software I'm maintaining and want to help. But we need to rethink this collaboration, because I feel like we're increasingly wasting each other's time.</p> Why I don't want to merge your PR#</a> </h3> Since I don't really know you, I always have to assume that you might be trying to sneak in something malicious along with your changes, which makes reviewing and merging them riskier than implementing them myself.</p> On top of that, there are a lot of personal and subjective aspects to code. You might have certain preferences about formatting, style, structure, dependencies, and approach, and I have mine.</p> Then we often need to synchronize with respect to review, CI runs, merge conflicts, etc.</p> And then there's this common back-and-forth round-trip between the contributor and maintainer, which is just delaying things.</p> Even before LLMs, writing the code was not the main bottleneck for me. But writing code did take time, so a solid, working, easy-to-review PR was often worth the small extra risk and inconvenience.</p> With LLMs becoming quite good at implementing things, that tradeoff is almost never true anymore.</p> While I still need to review LLM-generated code, I generally don't have to worry about it being malicious the way an unknown contributor's code could be. I've already codified a lot of my coding preferences and style guidelines for my LLM. And I can rapidly iterate at my own pace without having to synchronize with another human who might be in a different timezone.</p> For these reasons, it's just easier if I make the code changes myself (with the help of an LLM).</p> The nature of software development has shifted#</a> </h3> It's increasingly apparent that "the source code" is less "source" and more "code" — an intermediate formalized layer between ideas in the developer's head and instructions for the computer to execute. It's always been this way, but now, with the code itself being easier to generate automatically, it's just more visible.</p> There's a wide range of reactions to coding agents out there, from banning them to proclaiming that coding is dead and vibecoding is the future. Personally, as things are right now, I sit somewhere in the middle. I come up with the design, then let my agent do a lot of the actual writing, and then I review and refine the result.</p> I could get huge amounts of code written, but I'm bottlenecked on:</p> understanding — reading the existing code to be able to reason about it;</li> designing — coming up with the right changes and architecture;</li> reviewing — ensuring that the code is doing what I wanted.</li> </ul> The code in your PR doesn't help me much with any of these. So let's skip it — don't attempt to implement code changes with the goal of merging them into the codebase.</p> How can you help instead#</a> </h3> As the "writing the code" part is becoming less valuable, all other ways of helping maintainers become relatively higher value.</p> Give feedback#</a> </h4> As I'm busy implementing things, I often don't have much time to actually use them, or do good research on how to improve them.</p> Users telling me what works well and what could be improved can be very helpful.</p> Discuss ideas#</a> </h4> I don't know everything, and discussing things with other people with different experiences and perspectives can help me understand what I should be building and how.</p> Report and investigate bugs#</a> </h4> A good bug report is 3/4 of the bug itself being fixed.</p> If you spotted a problem, please describe it well, and even do the debugging to figure out how to reproduce it and where exactly the problem is.</p> Then discuss potential solutions.</p> Prototype changes#</a> </h4> Send me a reference PR and/or the prompt you used to produce it.</p> Yes, I know I just said that I don't want your PRs. So let me explain. With LLMs, it's easier for me to get my own LLM to make the change and then review it myself.</p> BUT — using code for illustrative purposes still makes sense. A quick glance at code implementing something can be helpful, even if I don't end up merging it.</p> And if you share the actual "source" (prompt) to produce the "code", I can reuse and refine it, saving time.</p> Review code and point out problems#</a> </h4> As I'm bottlenecked on reviews, an extra pair of eyes helps.</p> Fork the code and report back#</a> </h4> Don't be afraid of forking the code and changing it however you want.</p> Having to come up with designs supporting multiple use cases, forming consensus, debating best outcomes, looking for compromises, etc. is very time-consuming.</p> LLMs enable a great deal of software customizability. You can make the changes you want by yourself faster and easier than ever, and then rebase them (or not) on top of upstream at your own pace.</p> Just fork. Add support for your own use case, do things your way, ask neither for permission nor forgiveness.</p> As a maintainer, this saves me time too. And in the end, maybe both of us can learn something from your version taking its own route.</p>