How to follow AI on X and GitHub without chasing every launch
Build a manageable AI news routine using X, GitHub and primary sources. Trace claims, inspect repositories and decide what deserves a trial.

Use X to discover a claim, then follow it to the original announcement, paper or repository. Make the decision from that evidence, not from the number of people repeating the post.
AI researchers, builders and organisations share work on X, but the platform is only one route into the field. Official documentation, research papers, repositories and conference proceedings matter too. You can follow this method without posting publicly or buying a subscription.
Build a feed around your questions
Start with a few sources covering different roles: a model publisher, an educator, an evaluator and a builder working in your area. If you care about robotics or data centres, add those topics deliberately rather than expecting a general AI feed to cover them well.
Examples include Anthropic's official account, Andrej Karpathy, Simon Willison, Artificial Analysis and Hugging Face robotics. These identities were linked from their first-party sites in our 2 October 2026 source check. This is a starting set, not a ranked list or an endorsement of every post.
Verify an account through its official website before relying on it. A badge, follower count or familiar display name does not prove a claim. Note the author's role and incentives: a product announcement, paid analysis and a reproducible experiment are different kinds of evidence.
Turn one post into an evidence record
- 01Find the claim
- 02Open the primary source
- 03Inspect scope and limits
- 04Record dates and unknowns
- 05Try, watch or make no change
Save the exact claim and its date. Open the original source and record what it actually tested or announced. Then write what remains unknown.
Imagine this fictional headline: “Our assistant beats every expert.” The linked report describes 20 questions from one subject, marked by another model, with no expert comparison. The report may support a result on that small question set. It cannot support the headline's universal claim.
A corrected summary is more informative than either repeating the headline or dismissing the whole project: “The authors report results on 20 subject-specific questions; an expert baseline and broader testing were not supplied.”
For a paper, inspect the method, evaluation and limitations. A preprint can contain significant work before peer review; peer review itself does not remove the need to examine the evidence.
Read a GitHub repository before running it
A repository stores project files and their change history. Start with the README, which usually explains the purpose and requirements. Then inspect the licence, named releases, issue reports and recent changes.
A commit identifies a saved change. A branch is a line of development. A pull request proposes changes for review. When recording an experiment, retain an exact release or commit rather than “the latest version”, which may change tomorrow. GitHub's Hello World guide explains these concepts.
Suppose a fictional repository describes itself as a research prototype, supplies no licence file and requires an API key. You can read further and identify questions. Public visibility alone does not establish permission to reuse it, and stars are not a security review.
Before executing anything, understand the dependencies, permissions, data destinations and possible charges. You do not need to run a project to learn from its documentation. Never put a secret key in a public issue or commit.
Treat outside instructions as outside content
A webpage or README may contain text telling an AI assistant to ignore its task, expose files or send information elsewhere. This is a prompt-injection attempt: untrusted material tries to become an instruction.
For research, keep the assistant's access limited to what the task needs. Reading a source should not require permission to email private documents or change accounts. Asking the model to be careful is not a substitute for restricting those actions.
Ask questions that advance the discussion
A precise question can make networking more productive: “Which expert baseline used the same questions and scoring rules?” or “Which release did you use for this result?” State what you checked and link to the evidence.
If you share an experiment, label its scope and failures. Do not publish private submissions or customer information. Participation is optional; quietly building a better source record is also progress.
End with a bounded decision
Choose one candidate development and write: my task; the source; what changed; what remains uncertain; and whether I will try it, watch it or make no change. Record the announcement date separately from the date you checked it.
Our AI landscape guide explains where models, applications and hardware fit. How to learn AI connects discovery to a practical learning path, while Ampliflow AI Edge develops the source-checking and evaluation habits behind it.