You suck at DFIR if you’re vibe-coding forensic apps.

I’m talking about the DFIR equivalent of the examiner who clicks a button, gets an answer, and has no idea what happened underneath.

I agree that AI is a development tool. Using AI to write code does not make something vibe-coded. A programmer who knows what the code is doing, reviews it, changes it, tests it, validates it, and can maintain it is not vibe-coding simply because an AI wrote some or even most of the lines. That is AI-assisted programming.

The problem starts when the person building the software does not really know what is happening underneath the interface and keeps prompting until the thing appears to work.

That should sound familiar to anyone in digital forensics because we already have the exact same problem with forensic tools. There are examiners who know how to run tools and examiners who know what the tools are doing.

–The tool monkey*: Can create a case, ingest an image, select artifacts, build a timeline, bookmark evidence, export a report, and get through an examination without ever looking very far beneath the GUI.

–The practitioner: Wants to know where the value came from, what structure was parsed, what created the artifact, how the timestamp was stored, how the tool interpreted it, what conditions could cause the parser to fail, and what the artifact proves.

Both people may press the same button and get the same answer. But only one knows why and that person is far more likely to recognize when the output does not make sense.

We have spent decades warning examiners about this. Do not blindly trust your tools. Be able to explain what happened between the raw evidence and the result on your screen. If you cannot do that, then you are just operating software.

Now take that exact same standard and apply it to AI-generated forensic software.

If you tell an AI to build a parser, run what it gives you, paste the error back, ask it to fix the error, run it again, ask it to add a database, ask for a timeline, ask for a GUI, ask for filters, ask for a report, and keep going until the application looks right, you may end up with something impressive. It may process data and look better than software that took a company six months to build.

But if you do not understand what the code is doing, you are standing in the same place as the examiner who knows how to click the artifact button but cannot explain the artifact.

You are a tool operator asking a tool to write code you don’t understand.

This is where the word “vibe coding” matters. It should not mean “AI touched the source code.”  At the rate things are going, almost every developer will have AI touching source code somewhere. Vibe coding is when the GUI looks right, therefore the logic must be right. The parser returns the values you expected, therefore the parser must be correct.

That is a crazy standard for any software. For forensic software, it is reckless.

A vibe-coded program crashing might be the least dangerous thing it can do. When an application crashes, everybody knows there is a problem. The dangerous failure is when it runs exactly as designed and gives you a wrong answer that you can’t tell is wrong.

If the software’s progress bar hits 100%, creates pretty charts, and writes a “clean” report, slips by everyone including the decision-makers, we have a problem. The software does not need to throw an error and that should bother anyone working in DFIR.

We are entering a period where practically anyone can create forensic-looking software that produces forensic-looking results, and the technical barrier that once separated an idea from a working application has dropped through the floor.

That is not entirely bad. In fact, a lot of it is good.

Experienced examiners have had useful tool ideas for years but lacked the programming skills to build them. AI changes that. Now they can prototype narrow tools, automate tedious work, and turn an idea into something usable without first spending months learning to code. I want to see more of that.

But lowering the barrier also lowers the gate for everyone.

Someone with little programming knowledge or little forensic knowledge (or lacking both!) can now build a forensic application that looks legit. That is new.

I am stunned at the number of “forensic” apps I am seeing online, in my email, on Github where there is not a named person to be found. If I cannot identify who built it, what their background is, or who will stand behind it when something goes wrong, I am not touching it.

If a legitimate developer uses AI to assist, I don’t care whether AI wrote 10% or 90% of the code. If the developer understands it, reviews it, tests it, validates it, and can maintain it, that is AI-assisted programming. That is my line.” And it is exactly the same line we should already be drawing with forensic examiners.

I don’t care whether an examiner uses EnCase, X-Ways, AXIOM, Cellebrite, a Python script, or a hex editor. The tool does not determine whether the examiner knows digital forensics. What matters is whether the examiner understands the evidence, understands what the tool did to the evidence, understands the limitations of the result, and can defend the conclusion.

A vibe-coded parser cannot survive a Daubert challenge or a competent cross-examination because the creator cannot explain how the data was manipulated.

Why should the person building the forensic tool get a lower standard than the person using it? If anything, the standard should be higher.

Most importantly, you need to know when the application is wrong. That is the question I would ask anyone putting a new forensic tool in front of me. When your tool produces a believable answer that is wrong, how will you know?

If you built something you do not understand and then pointed it at evidence, we already have a name for that kind of examiner: button pusher.

Don’t be a button-pushing, vibe-coding monkey.

*Offended? Let me refer you to the Infinite Monkey Theorem. The Infinite Monkey Theorem says that given infinite time, a monkey randomly hitting keys on a typewriter will almost surely eventually produce Shakespeare.

That doesn’t make the monkey a writer. Pushing buttons doesn’t make you a DFIR practitioner. And prompting until something works does not make you a software engineer.