How I use AI in smart contract audits (2026)
Background
From 2023 to 2025 I competed in 57 audit competitions, finished top 3 in 30 of them, won 21, and earned $627k in prizes. Along the way I submitted 109 highs and 156 mediums, 53 of which nobody else found. Outside of contests I have led 86 private audits, ran the security department at Three Sigma, and I am a founding member of Blackthorn.
None of that came from a trick. It came from one method I repeat on every codebase, and it is deliberately boring. I read the code line by line and go deep into every function, not skimming for patterns. While reading I build a mental model of what the protocol is trying to be, so that later I can tell when the code stops agreeing with it. I write the tests the team did not write, because the gaps in a test suite are usually the gaps in their thinking too. I fuzz the invariants that look tricky, since those are the ones where my head is the least reliable. At the end I do a full QA pass over everything I wrote and everything I assumed, checking it still makes sense now that I understand the system better than I did on day one.
That is the whole thing. Coverage is not a talent, it is a habit, and it is the habit that produced every number above.
2025
Plenty of people were already using LLMs by then. They were not good enough. The output was too unreliable to put your name on. Coverage was shallow, so you still had to read everything yourself. Findings looked plausible and fell apart the moment you traced them through the code. The write ups were robotic in a way any judge could spot from the first paragraph. Tests compiled and proved nothing.
The real cost was not that it was wrong. It was that checking whether it was wrong took longer than doing the work yourself. So most serious auditors used it for boilerplate and ignored it for everything else, correctly.
2026
That changed. Models are now good enough to move the needle on coverage, speed and precision in a real review. Here is exactly how I use them.
Running open source skills. I run public auditing skills, such as pashov's, several times during an audit, since these tools are not deterministic, trying to get the most out of them. Any auditor who is serious should be running these on every engagement. They flag real findings for free, no reason to skip them. However, I make sure to analyze them at the end of the audit, so they don't bias my judgement.
POCs and tests. This used to be the tedious part. Learning a foreign test setup, its fixtures, its deployment helpers, its quirks, just to prove one line of reasoning. Now that is close to free. The catch is that you have to read what it produced. A test that exercises a mock and not the real integration proves that the mock behaves the way the model imagined it, which is worth nothing to anyone. Check the addresses, check the call path, check that the assertion would actually fail if you reverted the bug.
Writing findings. AI is now good enough to write clear findings, but make sure to give it some directions first, otherwise it may be vague or just sloppy. Make a paragraph description of the finding with the most important context and add it some guidelines to write all findings. When the finding is on the complex side, you might still have to write it manually, since the "short" description becomes so long, might as well write it.
What this actually changes
It does not make me faster. I want to be precise about that, because the pitch you hear everywhere is speed and the pitch is wrong. I still read every line. What it does is take the low value hours out of the review, the boilerplate tests and hand them back to me as hours I can spend in the deepest and nastiest parts of the codebase. That is where the findings nobody else has are, and that is why it supercharges an auditor rather than replacing one.
What I do not use it for
Coverage is the first thing people assume it fixes, and it is the thing it is worst at. Run the same tool twice over the same code and you get two different sets of findings. A clean pass is not evidence that the file is clean, it is evidence that this run did not surface anything, and those are not the same claim. If you are treating a quiet report as coverage, you have bought nothing.
It gets impact wrong, routinely and in both directions. Severity is an economic judgment: who loses what, under which preconditions, whether the loss compounds, and whether anyone can be made whole afterwards. A model reads the shape and guesses the number. It will hand you a High that is really an informational, which costs you time, and a Low that is really a High, which costs you the finding.
And it misses context, because most of the context is not in the repository. The invariant lives in the client's docs, or in one sentence someone wrote in a Discord thread, or in how the contracts will actually be deployed and who will actually hold the keys. A reviewer who has not sat in those conversations cannot weigh what breaking that invariant is worth, and the model has not sat in any of them.
The pattern underneath all three is the same one, and it is worth stating plainly because it decides what a review is worth paying for. Coverage of AI tooling is unreliable, but known bug patterns are commoditizing fast, and they should. Anyone can run the public skills over a repo now, and anyone who does not is leaving free findings on the table.
What has not commoditized, and is not close, is novel business logic and cross contract economic reasoning: the bug that only exists because these two contracts were composed in this specific way, under this fee structure, with this liquidation path, and where the loss lands on a cohort nobody thought to name. That still comes from a person who has built the model of the protocol in their head and can hold it there while they walk the sequences.
That is the part you are hiring. The tooling makes the commodity half cheap, which is exactly why the other half is where the review lives.
Why the hype sounds convincing
Ask yourself how often you have pointed a model at a field you do not know well and come away thinking you could probably do that job now. I have done it. It reads as competent, and it reads that way precisely because I have no training in that field, so the places where it is thin are the places I am not equipped to see. The output looks like expertise because my ability to check it is the thing that is missing.
Now turn it around and read it on your own subject, where you catch the errors in the first paragraph. That gap has a name. Michael Crichton called it the Gell-Mann amnesia effect: you read the newspaper article about the thing you actually know, you see that it is wrong in almost every detail, and then you turn the page and read the next article as though it were reliable. Most of what is being said right now about AI replacing auditors is being said by people on the second page.
The second half of it is less comfortable to write down. Judging whether a finding is good takes the same skill as producing one. Someone who cannot write a valid high severity finding also cannot reliably tell a real one from a plausible looking paragraph that falls apart on the third read. That is the Dunning Kruger effect in its precise form, which is not the pop version about confident fools, but the narrower and much better evidenced claim underneath it: the competence you need to do the work is the same competence you need to evaluate the work. Remove the ability to evaluate and everything that resembles work becomes indistinguishable from work.
Put the two together and you get the shape of the current discourse. The loudest predictions that AI will replace auditors come from the people least equipped to judge whether it has, and for many of them the prediction is accurate. If the model genuinely outperforms you, then "this replaces auditors" is a correct observation about the wrong subject.
The mistake to avoid
Do not ask the model how something works and accept the answer. Ever. Not up for debate. It will explain a function to you fluently and confidently and be wrong about the one detail the bug lives in, and once that explanation is in your head you will read the rest of the file through it. Verify every claim against the code, including the ones that sound obviously right. Nothing here replaces your critical thinking, and the moment it does, you are not auditing, you are proofreading a machine.
So that is 2026. Use it to clear the tedious work, and to buy back the hours you should be spending in the hard parts. Then go read the code.