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_cesca...
For further actions, you may consider blocking this person and/or reporting abuse
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. 😄
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. ✌️
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. ✌️
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?
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
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.
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 🤣
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?
🤣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.😂
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!