Find AI Information Through Builders, Not Just Influencers

When an AI topic becomes noisy, do not begin by following the loudest account. Use commentators and aggregators to discover questions, find builders or practitioners who have done relevant work, trace the material claim to primary evidence, and record the conditions that limit your conclusion.

“Builder” is a role in relation to a claim, not a popularity score. A researcher, maintainer, operator, educator, or domain practitioner may be a builder when their relevant work can be inspected or described. A confident personal brand is not enough.

The goal is not to consume more AI news. The goal is to create a small source map that helps you decide what is established, what is plausible, and what remains uncertain.

Give each source one job

Different sources answer different questions. A source can be useful without being able to support every claim you want to make.

An influencer, journalist, newsletter, or teacher may be excellent at discovery or interpretation. Do not dismiss a source because it is not primary. Assign it the role it can support, then move to stronger evidence when the decision matters.

Start with a bounded claim

“What is happening in AI?” is too broad to investigate. Rewrite the question as a claim with a subject, action, condition, and observable evidence.

Claim:
Subject:
Action or capability:
Condition:
Evidence that would support it:
Evidence that would limit or contradict it:
Decision this claim affects:

For a safe example, use a format claim rather than a performance claim:

The Agent Skills format uses a required SKILL.md file and can bundle optional scripts, references, and assets; compatible agents may load these pieces progressively rather than loading every resource at startup.

This is a bounded claim about a documented format and loading model. It is not a claim that every agent product supports the format identically, that every skill is reliable, or that skills improve a student’s learning.

A student claim: “AI refactoring made my program safer”

A student may encounter a post claiming that an AI coding assistant can refactor duplicated parsing code without changing behavior. That is more useful than “AI coding is getting better,” but it is still too broad. Rewrite it as a testable local claim:

Given this repository, this input fixture, and this test command, the assistant can remove one duplicated helper without changing the parser’s outputs or introducing a new dependency.

Now find sources with different jobs. A video or newsletter can reveal the claim. A builder’s public pull request or technical write-up can show what was changed and how it was tested. The project’s documentation and test suite are primary evidence about the stated interface and checks. Your own fixed fixture is independent evidence about whether the claim holds in your environment.

Record the boundary conditions: model and tool version, repository language, input cases, tests that were run, files the assistant was allowed to edit, and what “safer” means. A passing test suite may show that the fixtures still pass; it does not prove that the refactor is easier to maintain or correct for every unseen input. Inspect the diff and keep the original branch available before accepting the change.

This is the builder-first habit in miniature: follow the claim toward an artifact, then follow the artifact toward a check. The builder’s result helps you understand what happened. It does not turn a demonstration into a universal promise.

Find builders through artifacts

Look for relevant work before looking for a personality to follow. Search for:

• a repository with source files, history, issues, and a license;
• a technical report, paper, or experiment with a method and stated limits;
• release notes or documentation maintained by the team responsible for a tool;
• a deployed example with enough detail to understand the environment; or
• a reproducible demonstration that states its inputs, outputs, and failure cases.

For each possible builder, ask:

1. What did this person or team actually make, test, maintain, research, or operate?
2. How is that work connected to the claim I care about?
3. Can I inspect an artifact, method, version, or result?
4. Which conditions make the experience different from mine?
5. What incentives, selection effects, or missing information should I record?

Job titles and audience size are weak evidence. A maintainer’s change log may be relevant to implementation behavior. A researcher’s paper may be relevant to a measured result. A student’s careful reproduction may be relevant to one environment. None of these automatically supports a universal conclusion.

A worked source map: the Agent Skills example

Use three to six sources. The following map demonstrates the process for the bounded format claim above.

The map supports a narrow conclusion: the format and the current OpenAI documentation describe skills as structured directories with a required instruction file and optional resources, and they describe a progressive loading model. It does not establish that every compatible agent discovers, activates, or executes every skill the same way.

That distinction is the point of the exercise. A builder-maintained source is more useful than a summary because you can inspect the artifact and its history. It is still evidence with a scope.

Trace one material claim

Do not collect links without recording how each link changes your understanding. Trace the claim in this order:

1. Discover the question. Use a search result, newsletter, post, lecture, or conversation to identify a concrete claim worth checking.
2. Find relevant firsthand work. Locate the team, maintainer, researcher, operator, or practitioner whose artifact or method is connected to the claim.
3. Open the primary material. Read the specification, documentation, code, experiment, paper, or release note rather than relying on the summary.
4. Check the conditions. Note the version, platform, inputs, sample, time period, permissions, and success criteria.
5. Look for a boundary. Ask what would make the claim false, incomplete, or inapplicable to your situation.
6. Write the conclusion. Choose a bounded label and state what remains unresolved.

Use this claim-tracing record:

Material claim:
Why it matters:
Discovery source and role:
Builder or practitioner and relevant work:
Primary evidence:
Conditions and version:
What the evidence supports:
What it does not establish:
Conclusion: supported within scope / corrected / uncertain / not established
Next verification step:

If the claim affects health, safety, finances, law, security, academic standing, or another high-consequence decision, use domain-appropriate authoritative sources and qualified human review. A source map helps organize the work; it does not lower the standard of evidence.

Use personal taste to choose questions, not conclusions

Taste matters because attention is limited. You may prefer a particular builder’s explanations, notice a tool that matches your projects, or decide that a new capability is worth investigating. That is a reasonable way to choose a question.

Keep taste separate from evidence:

I want to investigate this because:
The relevant firsthand work is:
The primary evidence says:
My current conclusion is limited to:
I would change my mind if:

This prevents “I like this person” from becoming “this claim is true.” It also prevents the opposite mistake: dismissing a useful source because the author is not your preferred personality. Inspect the work and assign the source a role.

Common source traps

• Popularity as expertise. Audience size measures attention, not relevance to your claim.
• Official documentation as proof of outcomes. Documentation can establish what a team supports or intends. It does not by itself prove reliability, educational value, or universal performance.
• One successful demonstration as a general rule. A builder’s result may depend on a particular dataset, prompt, model, version, team, or budget.
• Aggregation without traceability. A summary that names no sources is a lead, not evidence.
• Survivorship bias. Public examples often show the projects that worked or were worth sharing.
• Source accumulation without a decision. More links do not automatically produce a better conclusion. Stop when the next source is unlikely to change the decision or when the claim must be tested directly.
• Private-data investigation. Do not upload restricted, graded, confidential, or unpublished material merely to investigate a trend or test a capability.

Do this now

Choose one bounded claim about an AI capability you may use this month. Create a three-row source map with one discovery or interpreter source, one relevant builder or practitioner source, and one primary source. Write one sentence about what your evidence does not establish.

Log what you learned

• What bounded claim did you investigate, and what decision could it affect?
• Which source was for discovery, which source showed relevant firsthand work, and which source served as primary evidence?
• What conditions, versions, incentives, or selection effects limited the conclusion?
• Did you conclude supported within scope, corrected, uncertain, or not established?
• What would you check next if the decision became more consequential?

Further reading

• Agent Skills specification
• Build skills with ChatGPT and Codex
• Agent Skills specification and documentation repository
• AI Can Be Confident and Wrong
• Test an AI-Generated Claim with the Scientific Method