Why the "AI" Badge Doesn't Matter and How to Restore Trust in Our Code

Hello, DEV community! 👋

This is my first post here. I've been reading articles on this platform for a while, but a recent article by @pascal_cescato_692b7a8a20 - "The "AI" Badge Doesn't Measure What You Think It Does" - finally pushed me to join the conversation.

It touches on a topic that's been on my mind for a while: the "AI-generated" badge, which is being actively pushed across media platforms, doesn't actually tell us anything useful.

Whose thought is it anyway?

As Pascal brilliantly breaks down, we constantly conflate three fundamentally different ways of working:

• Assisted. When the idea, structure, and artificial decisions belong entirely to the human. A model is used to rephrase, translate, fix regex, or pressure-test arguments.
• Generated. A human gives a prompt, but the model produces the actual thought and text.
• Produced. Automated pipelines generating content at an industrial scale without human oversight.

A binary badge (or statistical watermark) treats all three identically. An engineer who spends hours architecting a system, writing core logic, and using LLM to polish a comment or write boilerplate get shoved into the same bucket as an automated spam farm.
The real line of ownership isn't drawn by how much a model intervened, but by who kept their hand on the decisions. Who designed the solution? Who discarded the bad outputs? Who took responsibility for the final architecture?

---

Proof of work instead of broken labels

Detectors and badges look at the final shape of a file and guess its origin. But as Pascal proved by running his 2021 pre-LLM article through ZeroGPT (getting scores ranging from 97% to 8.6%), detectors merely chase stylistic neutrality, not actual origin.

We are seeing the exact same flaw happening in programming. Today, there are various code analyzers and enterprise tools designed to detect "AI-generated code". While writing software is fundamentally different from writing prose, the detection methodologies share the exact same underlying bias.

Just as text detectors flag well-structured, pedagogical paragraphs as "AI," code detectors often flag clean, canonical, and boilerplate code. If an engineer writes a textbook algorithm, strictly follows naming conventions, or implements standard design patterns, they risk being falsely flagged. The detector mistakes professional standardization for machine generation. It judges the final shape without knowing the process.

This exact problem led me to create dev-ledger - an open-source VS Code extension designed as a conceptual evolution of time-trackers like WakaTime.

But unlike traditional trackers that send your activity to a third-party server, dev-ledger is 100% local-first. All data collection and behavioral analysis happen directly on your machine - no APIs, no telemetry, no cloud. To guarantee the authenticity of your timeline, it secures your local event log with a cryptographic hash chain. It gives you a mathematically tamper-proof "Proof of Work" that you fully control, without sacrificing your privacy.

Instead of slapping a meaningless "100% Human" or "AI Generated" badge on a project, this approach shifts the focus back to transparency. By unobtrusively recording keystrokes, active editing time, and structural modifications, it documents the actual process - the iterations, the refactoring, and the human effort behind a codebase. It then converts this data into automated reports and visual SVGs for your README.md, backed by an integrity hash.

When someone looks at a repository equipped with this kind of timeline, they don't have to blindly trust a flawed detector or guess the code's origin based on its "final shape." They can actually see the chain of decisions and the problem-solving process that went into building it.
We probably can't stop platforms from implementing broken AI detectors or pushing binary badges. But as engineers, we can choose to shift the conversation back to what actually matters: the depth of our thought and the transparency of our work.

If you share this philosophy and want to secure the integrity of your own coding sessions, you can check out the source code and try the extension here:
👉 github.com/whaiman/dev-ledger

(Feedback, GitHub stars, and PRs are deeply appreciated!)

---

What Metrics Cannot Fix

Building a cryptographic ledger for development activity solves the technical problem of proving effort, but it doesn't fix the social one.
Having a verified hash chain won't stop a cynical reviewer on Reddit or Hacker News from glancing at a clean, well-structured repository and dismissing it as "LLM slop." Just as in writing, the technical demonstration and the social judgment are two completely different things. Often, the reflexive rejection of code as "AI-generated" has nothing to do with the code itself - it’s just a blunt reaction to the anxiety of our industry's current transition.

If badges can't measure origin, and enterprise code detectors can't measure thought, then the question in modern software engineering isn't "who typed this line?" but "who holds the steering wheel?"

Software architecture is fundamentally about making trade-offs, not just generating syntax. An LLM might help write a boilerplate function or figure out a tricky regex, but it doesn't conceptualize a local-first system. It doesn’t weigh the security implications of a cryptographic hash chain against a centralized database. The engineering intent - the real heavy lifting - remains entirely human.

When we reduce a developer's contribution to a binary label, we erase the unseen hours spent designing data models, debugging AI hallucinations, and rejecting bad abstractions. We erase the actual engineering.

Code analyzers and enterprise detectors will only ever scan the final repository. They parse the Abstract Syntax Tree (AST) looking for generic patterns, completely blind to the iterative struggle that brought that structure into existence. But true ownership of software isn't found in the finalized syntax. It lives in the problem-solving, the discarded ideas, and the chain of architectural choices that made that code necessary in the first place.

Comments

[Pascal CESCATO]

This is exactly the kind of evolution I hoped the article would trigger.

I really like the move from detection to recorded provenance — especially the local-first approach and the hash chain. That's already a fundamentally different proposition from an “AI-generated” badge.

There is one distinction I'd be curious to explore further, though: a cryptographically verified activity timeline can prove that a development process happened, but it can't necessarily prove where the decisions came from.

A developer could spend 20 minutes reviewing an AI-generated architecture, reject three alternatives, and accept the fourth. The ledger can prove the iterations happened; it can't prove who originated the architectural insight.

Which brings us back to the same problem at another level: we can prove the history of the artifact much more easily than we can prove the origin of the reasoning.

But that's still vastly more meaningful than trying to infer provenance from the final code.

And honestly, I didn't expect my little ZeroGPT experiment to turn into a discussion about cryptographic proof-of-work for software engineering. 😄

[Ekong Ikpe]

A person can legitimately develop software using:

voice input

eye tracking

accessibility switches

alternative input devices

dictation

automation

assistive technology

So a system that equates keystrokes → human effort → provenance is inherently exclusionary and technically weak.

More fundamentally, the physical act of typing isn't the engineering contribution.

The contribution can be the decisions, reasoning, testing, rejection of alternatives, architecture, and responsibility for the result.

If "Proof of work” depends on how you physically interact with the machine, it isn't really proof of engineering work.
& For the cryptography work, no knowledge is a waste. ✌️

[Pascal CESCATO]

Yes — and I think that distinction actually makes the idea stronger.

A ledger can provide evidence of a development process, but it shouldn't define “work” as physical keyboard activity. The moment we do that, we confuse the interface with the engineering.

What matters is the chain of decisions: architecture, experimentation, testing, rejection, trade-offs, and responsibility for the result. The input mechanism is just one possible way of expressing those decisions.

So I'd probably distinguish between proof of activity and proof of engineering provenance. The first can be cryptographically recorded. The second is much harder — but at least we're measuring something closer to what we actually care about.

And yes, no knowledge is wasted. Your cryptography work has already pushed the discussion one level further. ✌️

[Mudassir Khan]

the 'detector mistakes professional standardization for machine generation' line is the one worth sitting with. we got this false positive on a Next.js project — TypeScript generics with strict constraints, clean JSDoc, proper error boundaries, flagged by two enterprise tools. the engineer had to justify code that was correct precisely because it followed every best practice.

the assisted/generated/produced split is the right taxonomy. a binary badge can't encode 'human spent 4 hours reviewing and discarding AI outputs' vs 'prompted once and shipped.'

the proof of work timeline approach is interesting. curious whether it solves the persuasion problem or just moves it: you're now asking a reviewer to trust a local hash chain they can't independently verify. any plans for an attestation layer, or keeping it entirely local by design?

[Mridul Tiwari]

This is definitely something , I know this approach is not fully reliable but still its better than what is actually happening at these platforms. I myself was worried when most of my code base is flagged AI when the actual decision making was entirely mine from the beginning. This might be start of a very good conversation in the industry

[whaiman]

Thanks, Mridul!
Your experience is exactly why I built dev-ledger. Having your own architectural decisions dismissed just because a detector didn't like the syntax is incredibly frustrating. Glad to see this approach resonates with you.

[Elmar Chavez]

This idea is great. If there is something to show for the "process" and not just the final output, trust will go towards the good engineers. Finally, someone will actually see me struggle on naming my variables and rewriting my helper functions just because I don't think they fit in the architecture I initially set up for my project 🤣

[Kartik N V J K]

The point that detectors flag standardization as machine-authorship really lands, since a textbook algorithm and a spam farm can produce byte-identical output. What has worked for me is shifting the trust signal from origin to behavior: I score whether the code holds its invariants under adversarial inputs, because that catches the swallowed edge cases a badge never will. When you say "proof of work," do you mean commit and decision history, or something a reviewer can replay?

[xulingfeng]

🤣I've been there. Got flagged as AI on this platform once, and later turned it into a fictional story: QA engineer pulls 347 records, finds the system's effective accuracy is ~38%, it can't tell "written by AI" from "written like AI". Your line about judging the final shape without knowing the process is exactly what I saw.😂

[whaiman]

That QA story is painfully realistic! "Written by AI vs written like AI" is actually a brilliant way to summarize the fundamental flaw of all current detectors. Thanks for sharing this and for reading!