“AI programmers” are appearing more and more often in CVs, profiles and covering letters. For technical recruiters and engineering leads, the main question is therefore not whether someone uses AI, but how to recognise genuine work of their own in a work sample or repository. People searching for “ai programmers” usually want to understand exactly that: how to distinguish substance from presentation alone.
Repositories are often more informative here than claims in a CV or a formal credential on its own. They make working methods, changes, security standards and technical care visible. This article provides a practical review framework for that:
- authorship and working patterns
- security posture and test coverage
- technical context and a reasoned overall verdict with confidence score
This is not about condemning the use of AI across the board, but about whether the work shown is understandable, independent and relevant to a role. If you want to explore the Proof Engine methodology in more depth, you will find the technical framework there.
Why “AI programmers” is not enough as a signal on its own
The term “AI programmers” is too imprecise to use as a selection criterion. It can mean anything: sensible support with research, testing or refactoring, as well as work that depends heavily on external templates, generators or outside contributions. For recruitment and technical assessment, that is too broad to draw conclusions about actual ability to do the work.
That is exactly why self-descriptions, portfolio texts and CV claims are only of limited use unless they are backed up by reliable evidence. A clearly written overview may suggest competence, but it does not yet prove how someone breaks problems down, introduces changes or takes responsibility in code. If you want to assess portfolios more effectively, you should look for evidenced code in the portfolio.
The same mistaken assumptions often arise with repositories:
- lots of code must automatically mean lots of achievement
- a polished result must automatically have been created independently
- current tools must already be a sign of ownership
In practice, however, what matters is less the end state than how it came about. Code becomes meaningful where small, traceable steps are visible: decisions, corrections, iterations, follow-up work after problems and repeated intervention in relevant places. To assess responsibility, reviews, tests and possible external contributions, it also helps to read about genuine responsibility in code, good reviews, unit tests as a work sample and third-party code.
The basic principle is therefore simple: what should be assessed is not the claim about someone’s ability, but verifiable traces of work in Git. That is also the difference between formal classification and an actual work sample, much like formal credentials without evidence of work.
Which traces in Git repositories point to genuine individual work
A Git repository does not just show source code. It also shows how the work came into being: commit history, author information, depth of changes, review traces, tests and technical development over time. These are precisely the traces that are often more useful to recruiters and engineering leads than a finished snapshot.
Traceable individual work usually becomes visible where contributions form a consistent pattern. This includes, for example:
- recurring author patterns rather than unclear or changing attribution
- incremental development in smaller, understandable changes
- adjustments across several related files with a clear business or technical connection
- recognisable follow-up work after review, feedback, bugs or subsequent issues
It is sensible to be cautious with so-called code dumps. When large amounts of code suddenly appear, the end state may be visible, but the path by which it was produced is much harder to follow. That also reduces the value of the repository as evidence of how much the person actually contributed, understood and carried forward.
It is also important not just that code exists, but whether changes have an effect in the project context. This kind of impact signal is more likely to appear where contributions change relevant parts of a system, move problems forward in a measurable way or make the consequences of technical decisions visible. Ownership therefore rarely depends on a single line. What matters is whether someone repeatedly intervenes at important points, takes responsibility across several changes and carries the technical consequences.
Reviews and testing work also provide strong indications. Good reviews show how carefully someone assesses risks, clarity and maintainability. Tests make it visible whether changes are safeguarded and whether technical decisions are not only implemented but also made verifiable.
If you want to assess these signals more systematically, you will find more detailed criteria in the articles on genuine responsibility in code, good reviews and unit tests as a work sample.
How Acquispect assesses repositories instead of CVs
Acquispect starts from a different point than traditional pre-selection based on CVs, profile text or self-presentation. Instead of collecting claims, the approach audits a developer’s Git repository. Candidates can access this via the free repo audit for developers; companies use verification as needed via the page for companies. The basic principle remains simple: what is assessed is not promises, but verifiable traces of real work.
The Proof Engine works in three stages.
- Stage A: Ghostwriter Detector
This stage analyses the
.githistory forensically. It checks who authored commits, whether code was created incrementally or dumped in blocks, and what impact signal can be derived from the changes in the project context. - Stage B: Safety Check This is about risk and technical care. The review covers leaked secrets, known vulnerabilities in dependencies, test coverage and the tech stack.
- Stage C: AI Expert Panel Five AI expert personas – Tech Lead, Security, Performance, Architect and Craftsman – assess the results together and arrive at a consensus verdict with confidence score.
For hiring teams, Stage A is particularly practical because it changes the key question. Instead of wondering whether a profile sounds convincing, you can check whether work contributions and development patterns in the repository are traceable. This distinction is especially important for repositories with a lot of visible output: the focus is not on the amount of code, but on how it was created and whether authorship and impact can be recognised.
Stage B adds a second perspective that is often underestimated. A repository is not just a work sample, but also an indication of how someone handles risk, maintainability and quality. Leaked secrets, vulnerable dependencies, missing test coverage or an unclear technical context therefore also say something about the way the work has been done.
The verdict from Stage C is explicitly not an absolute claim to truth. It is a reasoned result with a confidence score. This also includes an audit log, so that the judgement does not remain a black box but becomes understandable.
For companies, the model is pay per verify with no subscription: developers are audited free of charge, and verification only happens if a company actually wants to check the credential.
What companies actually see – and what they do not
The result of a repo audit is issued as a W3C Verifiable Credential with did:web. It is stored in the developer’s wallet. This means the evidence does not sit with the company as a permanent collection of raw data, but with the person whose work was audited.
For hiring teams, this point matters because it creates a different verification process. A company verifies the credential only if it actually wants to see the evidence. In that verification, the verdict appears with a confidence score – not the entire repository and not the raw review data as the standard view.
That does not mean the judgement stands in isolation. The credential includes a complete audit log explaining how the result was reached. Teams can therefore read the reasoning without having to reduce every review to a full independent analysis of all repository data.
In practice, this creates a signal between two extremes:
- more substance than a purely self-written profile
- less raw data than a complete manual repository review
- a more structured judgement than isolated individual indicators
This format is particularly helpful with “AI programmers” profiles because it translates authorship, security posture and technical care into an understandable result that can be verified selectively.
How to use the approach effectively in your selection process
A repo audit is most useful as an additional review component, not as an isolated single-point decision. It complements interviews, the specific role context and technical discussions rather than replacing them. That turns one signal into a reliable part of a broader assessment.
The approach is particularly useful where profiles rely heavily on projects, open source, side projects or individual technical contribution. In such cases, a structured audit helps you classify the work shown more clearly instead of assessing self-presentation alone.
The process can also be useful for applications with rather brief or generic documents. Where CVs, covering letters and short profiles reveal little about real delivery capability, the repository often provides the more meaningful traces.
In practical terms, it also fits different entry points:
- developers can be audited free of charge
- companies pay per verification
- there is no subscription model
To assess portfolios and work samples, it is also helpful to consider evidenced code and possible third-party contributions separately. Especially with “AI programmers” profiles, this gives a clearer view of what was actually shown, owned and technically safeguarded.
Frequently asked questions about AI programmers and repositories
How can I tell whether the code shown by an AI programmer really comes from that person?
Not from the label “AI programmer”, but from reliable traces of how the work came about. What matters is whether authorship and working patterns can be traced in the repository. In particular, look for:
- consistent author information
- incremental changes rather than sudden large blocks of code
- a recognisable connection between problem, change and follow-up work
- repeated intervention in relevant areas
These are exactly the points Acquispect looks at in Stage A of the Proof Engine: the Ghostwriter Detector analyses the .git history forensically and checks authorship, code dumps and an impact signal.
Is AI assistance in programming automatically a negative signal in the hiring process?
No. Using AI is not automatically a problem. What matters is whether the work shown is traceable, independent and useful for the role. A good result may have been produced with assistance and still demonstrate technical care, responsibility and understanding. It becomes critical where only a finished output is visible, but there is little sign of how decisions were made, mistakes corrected or risks safeguarded.
What does Git history reveal about individual contribution that a CV cannot show?
A CV usually describes results or career stages. Git history shows the path to them. Among other things, it makes visible:
- how changes came about
- whether contributions were developed iteratively
- whether there was a response to feedback, bugs or subsequent issues
- how deeply someone intervenes in the project context
This makes individual contribution more concretely verifiable than pure self-reporting.
Why should I also look at secrets, dependencies and test coverage in a work sample?
Because a work sample does not just show whether someone can write code, but also how carefully they deal with quality and risk. Leaked secrets, known vulnerabilities in dependencies or missing test coverage are indicators of technical practice, not just style. In Acquispect, Stage B performs exactly this review: secret scanning, known vulnerabilities in dependencies, test coverage and tech stack. That complements the question of authorship with the question of how responsibly the work shown was implemented.
Conclusion: assess AI programmers by evidenced work
“AI programmers” is too vague as a label. As long as it remains unclear who actually built, carried forward and technically safeguarded which changes, the term adds little to an assessment.
Classification becomes more reliable when you look at verifiable signals:
- traces of work in the repository
- security characteristics and test context
- a traceable verdict with confidence score
This shifts the focus away from claims about ability and onto evidenced work, visible responsibility and the quality of the technical practice on show.