> Index of everything AyHire publishes for agents: https://ayhire.com/llms.txt # AI fluency interview: check their GitHub first https://ayhire.com/blog/ai-fluency-interview-github · 22 October 2026 · 12 min read · Nawneet Kumar > Google reportedly requires AI fluency. Before the AI fluency interview, check their GitHub: where agent use shows, what proves nothing, what shows skill. Google now requires AI fluency for every software engineering job, a Google spokesperson confirmed to Business Insider, as TechTimes reported on 22 October. Anthropic's own hiring data, published on 16 October, shows its hiring managers now comment on technical candidates' track record with AI tools three times as often as in 2024. Much of the evidence for an AI fluency interview is already in an engineer's public commits and pull requests. Here is where to look. Most advice on how to assess AI fluency is an interview rubric. That is useful, but it starts after you have spent the interview time. This post shows where AI use shows up in public work, why its absence proves nothing, how to read skill from pull requests, and how to write AI fluency down as a criterion for a role. ## What changed in 2026? In 2026, Google, Anthropic and Dice all reported employers asking for AI fluency, each with a caveat that belongs next to it: two reports this week, and one number from the summer. - **Google.** TechTimes, citing internal documents Business Insider reported on 20 October, says AI fluency is now required for all software engineering jobs. Google has been revising its interviews through 2026. In one experimental format, the **code comprehension interview**, candidates may use Gemini to read, debug and improve existing code, and they are scored on prompt engineering, output validation and debugging. The caveat: these formats "remain in the pilot phase", Google hasn't said they will become standard, and it hasn't announced plans to drop conventional coding interviews. The Gemini round itself isn't new: in May, Moneywise, also citing Business Insider, reported that Google planned to pilot it from the second half of 2026 for some junior and mid-level roles in parts of the US. - **Anthropic.** Anthropic coded the hiring managers' scorecards for thousands of people it has hired since 2024. In 2024, managers noted a candidate's track record with AI tools in around 5% of assessments for technical roles; by 2026 that rate had tripled. In its words, "the clearest change is increased emphasis on whether candidates have demonstrated creative use of AI tools", and for technical candidates the biggest increases were in comments on autonomy and judgement. The caveat is Anthropic's own: many of its employment practices "cannot be replicated across the economy". - **Dice, via CIO.** Citing Dice's July 2026 jobs report, CIO says 75% of US technology openings required AI fluency in June, up 178% year over year. That covers all tech openings, not only engineering, and it counts what job ads ask for, not how anyone checks it. ## What does AI fluency mean when you're hiring? "Good with AI" is not something a reviewer can check. Break it into parts you can write down: 1. **Uses agents for real work.** Changes to projects that matter. 2. **Checks the output.** Reads the diff, runs the tests, catches what is wrong before it merges. Google calls this output validation. 3. **Debugs what the agent got wrong.** Finds the cause and fixes it, instead of asking again until something passes. 4. **Knows when not to use one.** Some changes are faster, or safer, done by hand. The first part often shows in public work. The second and third show there too, if you read past the commit count. The fourth is mostly for the interview. ## Where does AI use show in public work? AI use shows in public work in three places: co-author trailers and footers, agent bot accounts, and agent instruction files in a repo. ### Co-author trailers and footers A **trailer** is a line at the end of a commit message, like `Co-authored-by:`, that GitHub reads to credit more than one author. Some coding agents add one to every commit they make. Claude Code, by default, adds a `Co-Authored-By` trailer naming the model to each commit and a "Generated with Claude Code" line to each pull request description. Aider, by default, adds a `Co-authored-by: aider () ` trailer. With that turned off, it adds "(aider)" to the author's name instead. Other tools mark their work in other ways: Copilot's coding agent can be the commit's author itself, with the person who asked listed as co-author. Here is what those marks look like, and two searches to find them: ``` # A commit made with Claude Code (the default trailer) Co-Authored-By: Claude # A pull request description from Claude Code Generated with [Claude Code](https://claude.com/claude-code) # Aider's default: a co-author trailer naming the model Co-authored-by: aider () # Aider with the trailer turned off: a suffix on the author's name Author: Their Name (aider) # A commit by Copilot's coding agent, for a person Author: copilot-swe-agent[bot] <198982749+Copilot@users.noreply.github.com> Co-authored-by: their-username <...@users.noreply.github.com> # GitHub search, Commits tab: one person's agent commits author:USERNAME "co-authored-by: claude" repo:OWNER/REPO author:USERNAME co-authored-by ``` GitHub's commit search only looks at a repo's default branch, so work still on a branch won't show. Search for each tool by name: Copilot, Cursor, Codex, Gemini, Devin, Aider. ### Agent bot accounts When an agent works on its own, from an issue or a chat, the commit or pull request can be made by the agent's own account, like `copilot-swe-agent[bot]`, and the person appears as co-author, reviewer or the one who merged it. On those, the interesting part is what the person did: what they asked for, what they changed before merging, and what they sent back. ### Agent instruction files in a repo Many repos now hold a file that tells coding agents how to work in them: `AGENTS.md`, which agents.md calls "A simple, open format for guiding coding agents" and which Codex, Cursor, Gemini CLI, Aider and Copilot's coding agent read, or `CLAUDE.md` for Claude Code. A good one says how to build the project, run the tests and follow its style. A person who wrote one for a project they maintain has set agents up to do real work there, on purpose. Open the file and read it: a list of commands and checks says more than a line of preferences. ## Why does a clean history prove nothing? A clean history proves nothing because agent marks are easy to miss and easy to remove: - **They are a choice.** Claude Code's trailer is on by default, and one setting hides it. Aider's marks have flags to turn them off, `--no-attribute-co-authored-by` for its trailer. Each tool decides its own marks. - **Much AI use leaves no mark.** Autocomplete in an editor, a chat in a browser, code pasted from either. - **Commit messages can be edited.** Anyone can change a message before they push. - **Most work is private.** An engineer can use agents every day at work and have nothing public to show for it. So a history with no agent marks is unknown, not a no: ask about it on the call, as you would about any gap in public work. We make the same argument in [how AyHire decides who to talk to first](/blog/how-ayhire-decides): an unknown should earn nothing and cost nothing. The reverse holds too. A trailer on a typo fix shows little more than that someone had an agent open. ## How to read skill from pull requests A count of agent commits only tells you someone uses agents. To read skill, open the pull requests around those commits: - **The description says what the agent did and what was checked.** "Claude wrote the parser; I rewrote the error handling and added tests for empty input" is fluency. A pasted summary of the diff is not. - **Review comments get real answers.** Did they fix what reviewers raised, or push back with a reason? Did they catch problems in their own agent's work before a reviewer did? - **Tests land with the change.** An agent-made change with tests the person clearly read and extended says more than a large diff with none. - **What happened next.** A follow-up fix a week later can be good debugging. A revert, or a run of "fix regression from" commits, says the checking didn't happen. - **Work spread over many days.** A project built over weeks of commits shows iteration. A whole repo pushed in one afternoon, mostly by an agent, shows less than it looks. Our guide to [finding engineers on GitHub](/blog/find-engineers-on-github) has the search operators for pull requests and reviews, `is:pr is:merged author:USERNAME` and `reviewed-by:USERNAME`, if you want to read more than one repo's worth. ## How do you turn it into a criterion? Write AI fluency down for the role, in words a reviewer could check against public work. Here is an example for a made-up backend role on a payments team that ships most of its changes with coding agents: - **Must have: Works with coding agents and checks their output.** What good evidence looks like: merged pull requests made with an agent that include tests and say what was checked. - **Important: Debugs and fixes agent-made changes.** What good evidence looks like: follow-up commits or review replies that fix what an agent got wrong, with the reason. - **Nice to have: Sets up agents for a codebase.** What good evidence looks like: an AGENTS.md or CLAUDE.md with build, test and style steps in a repo they maintain. Think hard before you copy the first one as a must-have. Because a clean history proves nothing, a must-have about agent use will hold back strong people whose agent work is private. That team works mostly with agents, so the weight fits. For most roles, Important is the honest weight. Our guide on [writing hiring criteria](/guides/writing-criteria) covers how much each importance counts and how to word what good evidence looks like. ## What should you save for the AI fluency interview? Public work can't show private work, judgement under a deadline, or how someone decides an agent is the wrong tool. Those are for the call. Two ways to use the time well: - **Ask about one of their own public pull requests.** "Your agent wrote most of this. What did it get wrong, and how did you find out?" A fluent engineer has a specific answer. - **Run a Google-style exercise.** Give them existing code with a bug, let them use their own assistant, and watch how they check and debug what it gives them. That is close to what Google's pilot scores, and it tests the parts public work only hints at. ## Where AyHire helps AyHire's general scores come from [what it reads in an engineer's public GitHub](/blog/what-ayhire-reads-in-your-github). When it judges someone against a role, it also reads how they worked in a few repos. AyHire reads their newest 100 commits in their four most-starred repos of their own, and in up to three other repos the search found them through. It counts how many of those commits were made with an AI coding agent: from a co-author trailer or a "Generated with" line in the commit message, or an agent's account as committer. AyHire's judgement sees that number for each repo, next to their active days and a link to their commits, so a criterion about AI use can cite it. From Claude Code, Cursor or another agent, AyHire's `list_commits` tool marks each commit that was made with an agent. Its limits are the ones in this post: - It only catches the marks it knows. Aider's name suffix, used when its co-author trailer is turned off, isn't one. - It reads only commits the person authored, so work an agent's own account committed for them, like Copilot's coding agent with them as co-author, isn't in the count. - It can't see private work, and a count shows use only. - A count of 0 reaches AyHire's judgement as 0, with nothing marking it as unknown, so don't read it as a no. That is one more reason to weight an AI fluency criterion Important. You still read the pull requests behind the number. [Start a 14-day free trial](/pricing), no card needed, and add AI fluency to the criteria of a role you are hiring for. If you are an engineer, [check your own profile](/engineer) (free, no account needed) to see how your public work reads. ## Questions people ask ### How do you assess AI fluency in a software engineer? Look at public work first, then test it in the interview. In public work, agent trailers and bot accounts show use, while pull request descriptions, review replies, tests and follow-up fixes show whether they check what the agent wrote. In the interview, give them existing code and their own assistant, and watch how they check and debug the output. ### What are good AI fluency interview questions? Good AI fluency interview questions start from the candidate's own public work. Pick one of their pull requests made with an agent and ask what the agent got wrong and how they found out. Then give them existing code with a bug and their own assistant, and ask them to walk you through how they checked what it gave them, which is close to what Google's pilot code comprehension round scores. ### Does Google require AI fluency for engineers? Yes, as reported: TechTimes, citing Business Insider's 20 October report, says a Google spokesperson confirmed AI fluency is required for all software engineering jobs. The interview formats that test it, including a code comprehension round with Gemini, are still pilots. Google hasn't announced plans to drop conventional coding interviews. ### Can you tell if code was written with AI from GitHub? Sometimes. A commit can carry an agent's co-author trailer, a "Generated with" line, or an agent's bot account as its author, and you can search commit messages for them. Many tools and uses leave no mark, and marks can be turned off or edited out, so you can confirm AI use but never rule it out. ### Is using AI in commits a red flag? No. Google reportedly requires AI fluency for software engineers (TechTimes, citing Business Insider), and Anthropic's hiring managers comment on candidates' use of AI tools three times as often as in 2024. What matters is what happened around those commits: whether the pull request says what was checked, whether tests came with it, and whether the change held up. ### Should AI fluency be a must-have for juniors? Only if the job is mostly agent work. Many juniors use agents in ways that leave no public mark, so a must-have nobody can see will screen out people whose agent work is private. For most roles it fits better as Important, checked again in the interview. ### Do AI co-author trailers prove skill? No. A trailer shows a tool was used on that commit, and only when the person left it on. Skill shows in the review around the commit: what they checked, what they fixed, and whether the change was reverted later. *Sources: [TechTimes, citing Business Insider](https://www.techtimes.co.uk/google-ai-fluency-software-engineering-interviews-1809326) (22 October 2026), [Moneywise on Yahoo Finance](https://finance.yahoo.com/sectors/technology/articles/asking-kid-math-test-without-151500986.html) (14 May 2026), [Anthropic, Employment at Anthropic](https://www.anthropic.com/research/employment-at-anthropic) (16 October 2026), [CIO, IT jobs report](https://www.cio.com/article/4201347/information-technology-jobs-report.html) (page dated 16 October 2026; figure from its July 2026 section, citing Dice's July 2026 Jobs Report), [Claude Code settings reference](https://code.claude.com/docs/en/settings-reference), [Aider options reference](https://aider.chat/docs/config/options.html), [Aider git docs](https://aider.chat/docs/git.html), [a Copilot agent commit on discuss.python.org](https://discuss.python.org/t/cla-bot-and-ai-agents/106635) (22 March 2026), [agents.md](https://agents.md/), [GitHub commit search docs](https://docs.github.com/en/search-github/searching-on-github/searching-commits). All opened 22 October 2026.*