dpc - ai

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

LLMs getting good at finding issues

#</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>


BubbleWrap your dev env and agents
2026-03-25T00:00:00+00:00
OK, so the world is collapsing, everything is getting hacked,
all dependencies are probably stealing keys and mining crypto,
slop is everywhere, and I'm part of the problem.</p>
So what do I do? I'm going to isolate!</a></p>
I had this in mind for a long while, but only recently
LLM agents became good enough that I actually find it
really useful to let them go without babysitting every
command they are trying to run.</p>
So the goals are:</p>

protect my systems from the slopus,</li>
protect my systems from malicious dependencies (at least somewhat),</li>
retain the usual UX.</li>
</ul>
Because of the last point, I am not going to be doing
separate user account, or a separate VM, or play with dockers.</p>
What I'm going to do is to use the BubbleWrap</a>,
to remount only parts of host system and home directory, and most
of them in read-only mode. This way my tooling
and general DX remains almost exactly the same,
but if the Slopus has an episode of psychosis,
or pulls in a cryptomining malware, there is
only so much damage that it can do.</p>
So the core of this system is the isolate</code> script:</p>
#!/usr/bin/env bash</span></span>
</span>
set</span> -euo</span> pipefail</span></span>
</span>
# Skip re-isolating if already inside an isolated environment</span></span>
if</span> [[</span> -n</span> "</span>${</span>ISOLATE_ENV</span>:-}</span>"</span> ]];</span> then</span></span>
	>&2</span> echo</span> "warning: already isolated"</span></span>
	exec</span> "</span>$</span>@"</span></span>
fi</span></span>
</span>
tiocsti_path</span>=</span>"/proc/sys/dev/tty/legacy_tiocsti"</span></span>
if</span> [</span> ! -f</span> "</span>$tiocsti_path</span>"</span> ]</span> ||</span> [</span> "$(</span>cat</span> "</span>$tiocsti_path</span>")"</span> !=</span> "0"</span> ];</span> then</span></span>
	>&2</span> echo</span> "warning: TIOCSTI not disabled"</span></span>
fi</span></span>
</span>
args</span>=</span>()</span></span>
</span>
args</span>+=</span>(</span></span>
	--dev-bind /dev /dev</span> \</span></span>
	--proc /proc</span> \</span></span>
	--tmpfs /tmp</span> \</span></span>
	--tmpfs /run</span> \</span></span>
 	--setenv PROMPT_ENV_INDICATOR "isolated"</span> \</span></span>
 	--setenv ISOLATE_ENV "$(</span>pwd</span>)"</span></span>
)</span></span>
</span>
for</span> p</span> in</span> \</span></span>
	/bin</span> \</span></span>
	/usr/bin</span> \</span></span>
	/etc</span> \</span></span>
	/nix</span> \</span></span>
	/run/current-system</span> \</span></span>
	"</span>$HOME</span>/bin"</span> \</span></span>
	"</span>$HOME</span>/.config"</span> \</span></span>
	"</span>$HOME</span>/nix/dot"</span> \</span></span>
	"</span>$HOME</span>/.gitconfig"</span> \</span></span>
	"</span>$HOME</span>/.nix-profile"</span> \</span></span>
	"</span>$HOME</span>/.local/share/direnv/allow/"</span> \</span></span>
	;</span> do</span></span>
	args</span>+=</span>(</span>--ro-bind "</span>$p</span>" "</span>$p</span>"</span>)</span></span>
done</span></span>
</span>
for</span> p</span> in</span> \</span></span>
	"</span>$HOME</span>/.cargo"</span> \</span></span>
	"</span>$HOME</span>/.claude"</span> \</span></span>
	"</span>$HOME</span>/.claude.json"</span> \</span></span>
	"</span>$HOME</span>/nix/dot/.claude"</span> \</span></span>
	"</span>$XDG_RUNTIME_DIR</span>/gnupg/S.gpg-agent"</span> \</span></span>
	"$(</span>pwd</span>)"</span>\</span></span>
	;</span> do</span></span>
	args</span>+=</span>(</span>--bind "</span>$p</span>" "</span>$p</span>"</span>)</span></span>
done</span></span>
</span>
if</span> [[</span> -n</span> "</span>${</span>NIRI_SOCKET</span>:-}</span>"</span> && -S</span> "</span>$NIRI_SOCKET</span>"</span> ]];</span> then</span></span>
	args</span>+=</span>(</span>--bind "</span>$NIRI_SOCKET</span>" "</span>$NIRI_SOCKET</span>"</span>)</span></span>
	args</span>+=</span>(</span>--setenv NIRI_SOCKET "</span>$NIRI_SOCKET</span>"</span>)</span></span>
fi</span></span>
</span>
args</span>+=</span>(</span></span>
 	--dir "</span>$HOME</span>/.gnupg"</span> \</span></span>
 	--chmod</span> 0700</span> "</span>$HOME</span>/.gnupg"</span> \</span></span>
)</span></span>
</span>
# Source extra config (e.g. set by auto-isolate) to allow</span></span>
# project-specific additions to args</span></span>
if</span> [[</span> -n</span> "</span>${</span>ISOLATE_EXTRA_CONFIG</span>:-}</span>"</span> && -f</span> "</span>$ISOLATE_EXTRA_CONFIG</span>"</span> ]];</span> then</span></span>
	source</span> "</span>$ISOLATE_EXTRA_CONFIG</span>"</span></span>
	# Hide the config file inside the sandbox by overlaying /dev/null</span></span>
	args</span>+=</span>(</span>--ro-bind /dev/null "</span>$ISOLATE_EXTRA_CONFIG</span>"</span>)</span></span>
fi</span></span>
</span>
exec</span> bwrap</span> \</span></span>
	"</span>${</span>args</span>[</span>@</span>]</span>}</span>"</span> \</span></span>
	"</span>$</span>@"</span></span></code></pre>
I'm not going to spend time explaining every detail here,
please read the Bubblewrap docs, or ask your local LLM.</p>
But if you, dear reader, are planning to do the same/similar thing,
you'll probably want to go over each path and consider
implications. E.g. I'm using a fancy Yubikey SSH/GPG setup</a>
and I need to touch the hardware yubikey every time I ssh
somewhere. Because of that I'm not afraid of mounting the ssh/gpg
socket into the isolated environment.</p>
Anyway, in a nutshell: isolate</code> will run a given command
in an environment where almost only the current working directory
is writable, and rest are only the bare minimum parts needed
to get things working, mostly in read-only mode. Kind-a, mostly.
The goal here is a good enough security and robustness without
sacrificing almost any DX.</p>
Thanks to using Nix, the first thing I'm going to use this isolate</code>
script to wrap Slopus. That guy should never get a full
access to anything important directly.</p>
Inside my system's flake.nix</code> in the main overlay I have something like this:</p>
            claude-code</span> =</span></span>
              let</span></span>
                orig</span> =</span> pkgs-unstable</span>.</span>claude-code</span>;</span></span>
              in</span></span>
              final</span>.</span>writeShellScriptBin</span> "claude" ''</span></span>
                exec env CARGO_TERM_QUIET=true PATH="</span>${</span>final</span>.</span>not-git</span>}</span>/bin:$PATH" </span>${</span>./dot/bin/isolate</span>} ${</span>orig</span>}</span>/bin/claude "$@"</span></span>
              ''</span>;</span></span></code></pre>
This makes Slopus always start in an isolated environment,
so I can't forget about it. I also replace git</code> with a wrapper
reminding Slopus that we're using Jujutsu, and make cargo build</code> less
noisy by default to (maybe) save some tokens.</p>
Then I want to automate entering isolated environment
in every project I'm working on.</p>
For that I have auto-isolate</code>:</p>
#!/usr/bin/env bash</span></span>
</span>
set</span> -euo</span> pipefail</span></span>
</span>
if</span> [[</span> ! -x</span> "</span>$HOME</span>/bin/isolate"</span> ]];</span> then</span></span>
	>&2</span> echo</span> "warning: </span>$HOME</span>/bin/isolate not found, skipping isolation"</span></span>
	exec</span> "</span>$</span>@"</span></span>
fi</span></span>
</span>
dir</span>=</span>"$(</span>pwd</span>)"</span></span>
while</span> true</span>;</span> do</span></span>
	if</span> [[</span> -f</span> "</span>$dir</span>/.isolate"</span> ]];</span> then</span></span>
		exec</span> env ISOLATE_EXTRA_CONFIG="</span>$dir</span>/.isolate"</span> $HOME</span>/bin/isolate "</span>$</span>@"</span></span>
	fi</span></span>
	if</span> [[</span> "</span>$dir</span>"</span> ==</span> "/"</span> ]];</span> then</span></span>
		break</span></span>
	fi</span></span>
	dir</span>=</span>"$(</span>dirname</span> "</span>$dir</span>")"</span></span>
done</span></span>
</span>
exec</span> "</span>$</span>@"</span></span></code></pre>
auto-isolate</code> will automatically call isolate</code> for a given
command if it can find .isolate</code> in current working dir
or any ancestor dir.</p>
One could wire it in a shell startup file, but since I have
a whole system for working in the CLI heavily rooted in tmux,
I am going to put it in ~/.config/tmux/tmux.conf</code> like this:</p>
set-option -g default-command "$HOME/bin/auto-isolate ${SHELL}"</span></span>
# in case I want to actually do something outside of the isolated env constrains</span></span>
bind E new-window "${SHELL}"</span></span></code></pre>
This way every time I'm starting a new pane in tmux,
it will trigger auto-isolate</code>. Now I touch ~/lab/.isolate</code> and
since all my dev projects are always inside ~/lab</code> I pretty much
can't ever forget to isolate</code> my projects.</p>
If you haven't noticed before, the isolate</code> script supports ISOLATE_EXTRA_CONFIG</code>
which allows adding project-specific modifications to the isolated
environment. E.g. for a little GUI project I'm working on, I had to
create following .isolate</code> file:</p>
if</span> [[</span> -n</span> "</span>$WAYLAND_DISPLAY</span>"</span> ]];</span> then</span></span>
    args</span>+=</span>(</span>--ro-bind "</span>$XDG_RUNTIME_DIR</span>/</span>$WAYLAND_DISPLAY</span>" "</span>$XDG_RUNTIME_DIR</span>/</span>$WAYLAND_DISPLAY</span>"</span>)</span></span>
fi</span></span>
</span>
args</span>+=</span>(</span></span>
	--bind /dev/dri/ /dev/dri/</span> \</span></span>
	--bind /dev/shm /dev/shm</span> \</span></span>
	--bind /tmp/.X11-unix/ /tmp/.X11-unix/</span> \</span></span>
	--bind /run/opengl-driver/lib/ /run/opengl-driver/lib/</span></span>
)</span></span></code></pre>
so it can show me the UI, when I run cargo r</code>.</p>


Personal AI usage disclosure
2026-02-04T00:00:00+00:00
Personal AI usage disclosure#</a>
</h1>
Since people have strong opinions about it and in an effort to keep things honest, let me write it once here so I can link to it from relevant README files and be done with it:</p>
✨ I use LLMs when working on my projects.</strong> ✨</p>
If you have problems with it you have been informed. Keep reading if you would like to know more details and some of my opinions on the matter.</p>
My history of using LLMs#</a>
</h3>
I've been relatively slow to start using LLMs, since they didn't have good integrations with CLI text editors (in particular Helix) and command line usage so they did not fit my workflow (I live in tmux, running fish shell and helix). Sometime in very late 2024 I discovered Aider</a> and that's when I started actually using LLMs for programming. Few months later I switched to Claude Code, and have been using it as a primary LLM ever since. There have been many significant improvements in how LLMs do as coding assistants during 2025, and somewhere in the second half of 2025 I was actually satisfied with their robustness and quality of what they produced.</p>
How I use them#</a>
</h3>
Just to get it out of the way: I do not vibe-code</strong>. By vibe-coding I mean largely unsupervised usage and not paying too much attention to the code AI produces. I believe vibe-coding can maybe work for very simple CRUD web apps and simple software, but at least at the moment LLMs are nowhere near producing really quality code without supervision. It seems definitely possible to build complex LLM-based agent loops and systems, that cross-check, verify, etc. to increase how far vibe-coding can be employed, but as things are right now I find it complex, wasteful and not very interesting.</p>
The way I use LLMs is largely treating it as a very sophisticated auto-completion and refactoring engine. I give it relatively small scope tasks, I like to point it at existing code with similar patterns and design, to ensure it produces exactly what I have in mind. Even with such a methodical usage it's quite common for the LLM to produce substandard code, overcomplicate or even break some adjacent stuff. It's been getting significantly better over time, but I fully recognize coding agents are a bit spooky in how unpredictable they can be. That's why I do review code the LLM produces and spend significant amount of time post-processing, refactoring and cleaning it.</p>
All in all, despite all the drawbacks and shortcomings of LLMs, they are still the most significant improvement for my productivity as a developer I've ever experienced. I build better, more ambitious things faster, and the quality is significantly improved. E.g. my projects now have way more tests - because it's faster to create and maintain them, and frankly - the flakiness of LLMs requires it. My code has more and better comments, examples and auxiliary stuff like that. Just the other day, I asked the LLM to scan a certain security-sensitive code for all attack vectors it can think of and write a unit test for each of them, and indeed AI found an important case that I missed. I screwed up, I wrote that code by hand. AI saved my bacon this time, repaying for all the dozen times when it did something really dumb that I had to tell it to correct.</p>
How exactly I use AI agents will evolve over time and I might not remember to update this document.</p>
Political concerns#</a>
</h3>
I know. The electricity and water usage, the ingestion of GPL-licensed code, the jobs that will be replaced, social repercussions, economic inequality. Yeah, yeah, I hear ya.</p>
I just don't think hiding your head in the sand and just refusing to use LLMs or even any code that was modified by an LLM is going to help anyone. The march of technological progress is kind of inevitable due to competitive pressures.</p>
Every technology brings important downsides and costs for all the benefits it makes. Such is the nature of civilizational progress. I guess the best we can do is to use political will and wisdom to increase the benefits, and mitigate the costs. And we will likely fail again to do so for a long time. But we did stop adding lead to car fuel eventually at least.</p>
From all the ways I could think of AI-like technology could have been developed, we got quite lucky. The LLM companies really have little moat, are a subject to heavy market competition from the get go, and even determined individuals can run their own LLMs locally. Much better than a hypothetical scenario where a single big-corp discovery gives it a patent and exclusive secret AI tech leading to impossible market advantage and universal monopoly over the whole economy.</p>
Software collaboration dynamic concerns#</a>
</h3>
So anyone can be a coder now, and produce terrible buggy code at the pace of 40 junior developers. And they are all very happy to open a PR to your project.</p>
And now that everyone is LLMing, how do you keep up and ensure the quality doesn't suffer, and people don't waste each other's time with slop.</p>
There are no easy answers here. We will manage, and we will see.</p>
I think the dynamics of SWE collaboration will drastically change. I predict teams will get smaller, and more projects will be developed by individuals leveraging their productivity. But only time will tell.</p>
And LLM-based solutions are desperately needed to help with vetting, reviewing, testing, ensuring code quality, etc. There's definitely a lot of potential and work to be done.</p>