Why "I wrote this" suddenly proves nothing
If you have ever shipped a feature with Claude or Cursor and then tried to describe your part in it honestly, you already feel the problem. You made a hundred decisions, rejected most of what the agent suggested, fixed the integration it could not see, and steered the whole thing. You also typed almost none of the final characters. So when someone asks "did you write this?", every available answer is either misleading or impossible to back up.
Quick Answer
You prove you wrote the code by showing provenance, not by saying so. The finished code looks identical whether you wrote it, drove an agent to write it, or pasted it wholesale, so the output settles nothing. What holds up is an audited trail of how the work happened over time: when it was built, in what order, with what thinking and iteration around it, traceable back to source. The strongest proof is not one artifact but a record, and the record has to come from somewhere that does not depend on trusting your word. Below: why "I built this" stopped working, the methods that actually prove authorship, and the ones that only look like they do.
This is new. For most of software's history, authorship was implied by output. If clean, working code existed with your name on the commits, you almost certainly wrote it, because writing it was the only way it could exist. That assumption quietly powered resumes, take-home tests, and GitHub profiles alike. In 2026 it is gone. An agent generates a plausible project, a tidy commit history, and a confident README in an afternoon, which means the existence of good code is no longer evidence that any particular person produced it.
The reflex is to reach for more of the old signals: a longer portfolio, more green squares, a more detailed resume. That is the wrong instinct, and it is worth naming why. Every one of those is a claim, and the thing that broke is precisely the trustworthiness of claims. You cannot fix a verification problem by asserting harder. The shift that matters is from claiming authorship to proving it, and proof has a specific shape.
What actually counts as proof of authorship
Real proof of authorship has properties that a snapshot of finished code never will. It is the difference between handing someone a polished result and letting them watch the work accumulate.
It is continuous rather than curated. A single impressive repo is a moment you chose to show. A record of work spread across weeks, with the false starts and the dead ends still visible, is much harder to fabricate convincingly, because consistency over time is its own signal. It is traceable, meaning a claim about building something connects back to the actual source and history instead of a screenshot. And in the AI era it has to be attributable, meaning it can speak to how much of the work was yours versus generated, which is the real question hiding inside "did you write this?".
This is the same distinction that separates a claim from real proof of what you shipped. Authorship is just the sharpest case of it, because AI made authorship the one credential that used to be automatic and is now the hardest to defend.
How to prove you wrote the code: the methods that work
There is no single magic artifact, so think in terms of building a record that a skeptic can follow. These methods stack, and the more of them you have, the less any one of them has to carry. Here is what genuinely moves the needle, roughly from weakest to strongest.
- Keep your real history, including the ugly parts. Squashing everything into one clean commit destroys the most convincing evidence you have. The messy middle, the commit where you reverted a bad approach, the three attempts at the same function, is exactly what an AI dump does not produce. In practice, a history that shows struggle reads as human in a way a perfect history never will.
- Be able to explain any decision in the codebase. This is the oldest test and still the best one in a live conversation. If you drove the work, you can say why the auth flow is structured the way it is and what you tried first. You will often find this is where pasted-without-understanding code falls apart instantly, no tooling required.
- Show the work around the code, not just the code. Issues you wrote, design notes, the pull request discussion, the bug you chased for two hours. Authorship lives in this connective tissue. Almost always, the person who actually built something leaves a trail of thinking next to it, and the person who did not, cannot reconstruct one.
- Capture the timeline as it happens, passively. This is the layer most developers skip, and it is the one that turns a story into evidence. A record of when the work happened, in what sessions, at what cadence, captured automatically rather than written down later, is hard to back-date and hard to fake. This is the part you cannot reconstruct after the fact, which is exactly why it is worth capturing while you build.
- Make AI involvement explicit instead of hiding it. Counterintuitively, the most credible developers in 2026 are not the ones claiming they wrote every line. They are the ones who can show what they delegated and what they drove. An honest attribution of "the agent scaffolded this, I architected and hardened it" is more believable, and more impressive, than a fragile pretense that no AI was involved. Proving the code is human-driven, not blindly AI-generated, is increasingly its own skill.
The first three you can do by hand today. The fourth is where most people need help, because no human reliably records their own timeline honestly, and reconstructing it later is the one thing that reads as fabricated.
The methods that look like proof but are not
Some of the usual advice actively backfires here, and it is worth being blunt about it.
A green-square contribution graph is the classic trap. It proves activity occurred, not that the activity was meaningful or that it was yours, and it is trivially paddable, which is why it functions as a claim wearing the costume of evidence. A scripted commit history can produce a beautiful graph in minutes. For the full mechanics of why the graph misleads, see why GitHub green squares do not prove the work and how to verify GitHub contributions.
Commit volume and diff size are the other trap, and AI broke them specifically. Lines changed no longer map to effort or authorship: an agent emits a thousand-line commit in seconds, while a one-line fix can follow an hour of reasoning you did entirely yourself. Anyone judging authorship by how much code moved is measuring the wrong thing, and anyone trying to prove it that way is building on sand. Raw git is a useful benchmark of what changed, but it is not, on its own, an honest clock or an authorship certificate.
A polished portfolio site has the same flaw as a resume: it shows a curated result and verifies nothing about who produced it or how. It is a fine introduction. It is not proof.
Where DevClocked fits
Full disclosure: I build DevClocked, so treat this as the founder telling you what it is for, not a neutral verdict. DevClocked exists to make the strongest layer of proof, the captured timeline and the attribution, something you do not have to manufacture by hand. It measures what you and your AI agents actually shipped, in terms of leverage and output rather than raw hours in an editor, and turns it into a profile that shows your real work over time, audited to source. The mechanism is a git baseline crossed with lightweight telemetry from an editor extension and an editor-agnostic CLI that also sees terminal and agent sessions like Claude Code, Cursor, and Codex, with a model learning the relationship between the two so the timeline is calibrated rather than guessed. That combination is what lets it speak to what was yours versus generated, which a contribution graph cannot. It is the record as the credential, and the underlying mechanism is explained here.
It would be dishonest to pretend you always need this. If you are in a live technical conversation and you genuinely drove the work, your own explanation of the decisions is the most convincing proof there is, and no tool beats it. If you have never shipped anything yet, there is nothing to audit and you are better off building first. A plain git history plus a clear head about your own code carries a lot of situations on its own. DevClocked earns its place when the work is real, the timeline matters, and you are tired of authorship being something you can only assert rather than show. For tracker-only needs without the proof layer, even a WakaTime alternative covers the basic stats; what it will not do is settle who actually drove the work.
Related Guides
- Prove what you shipped: the case for audited developer work: the broader claims-versus-proof argument this page sits inside.
- How to verify GitHub contributions: why graphs can lie and how to check the real record.
- Why GitHub green squares do not prove the work: the mechanics of the most common false signal.
- Strava for coding: the record as the credential, explained.
