Top 10 AI builders to follow on X for practical systems work

A practical reading guide with original resources, technical prerequisites and a reason to choose each person.

Jacob Top Møller17 October 20268 min read

If you are building an AI application, or working with the people who are, different questions need different sources. Understanding a model, investigating a poor answer and maintaining the software around it each require their own work.

These ten people publish original code, technical explanations or accounts of systems they have built. The selection looks for a concrete resource you can open, a useful systems question and a contribution that adds something to the other choices. The order follows areas of work; it is an editorial selection, not a measured global ranking.

Their X profiles are linked alongside the longer resources. Begin with the material that addresses your problem. Some of it assumes programming knowledge, and running a project can require paid model access even when its documentation and code are openly readable.

1. Andrej Karpathy: understand what the model is doing

Andrej Karpathy on X is a starting point for model mechanics. His Neural Networks: Zero to Hero series develops neural networks in code, beginning with backpropagation and moving into language modelling. The early material assumes some Python and basic calculus, so allow time for study if those are unfamiliar.

Work through the code when you want to follow a technical explanation in more depth or understand how a small model is trained. For a business owner working with developers, the general-audience videos linked from his homepage provide a gentler entry point. The technical series is a substantial learning commitment.

2. Simon Willison: inspect and experiment with model use

Simon Willison on X publishes practical tools and detailed notes about language models. His LLM project is a command-line tool and Python library. It can run prompts, store prompts and responses in SQLite, work with embeddings and extract structured content. Its documentation gives a developer concrete operations to inspect.

This suits a team moving from an interesting response to an experiment it can examine again. Take a small task with inputs you are allowed to use, keep the input and inspect the output. A technically comfortable reader can use the documentation to explore that work. Storing a response gives you a record; deciding whether it meets the task still needs attention.

3. Chip Huyen: connect AI engineering with the product

Chip Huyen on X writes about bringing AI into production. Her generative AI application pitfalls include choosing generative AI where it is unnecessary, confusing a product problem with an AI problem and starting with too much complexity. Her examples make product design and the user's workflow part of the engineering discussion.

If a promising prototype has left you unsure what to build next, ask which difficulty belongs to the model and which belongs to the way the product fits the user's work. A different interface, clearer task or simpler approach may be worth investigating. Compare her engineering observations with your situation before turning them into a project decision. They do not establish the commercial return of your own application.

4. Hamel Husain: learn from failures in an AI system

Hamel Husain on X focuses on debugging, analysing and measuring AI systems. His AI Evals guide addresses error analysis, data collection, human review and the use of language models as judges. It also considers how product managers, engineers and people with domain knowledge can contribute.

Bring examples of a task the system handles poorly and ask someone who understands the work to explain what went wrong. The guide helps frame questions about examining those failures and deciding what to measure. This is detailed practitioner material. Some sections will be more useful alongside a developer who can inspect the implementation, while a person who knows the task can help judge the answers.

5. Jason Liu: investigate retrieval and the answer around it

Jason Liu on X shares work on AI systems and software. His Systematically Improving Your RAG article is based on a conversation with Hamel Husain. It provides a runbook for retrieval-augmented generation, where an application retrieves information to help produce an answer. It discusses test questions, retrieval baselines and feedback that can help a team investigate the system.

For an assistant answering from company documents, finding an appropriate source and producing a useful answer are separate things to examine. Someone responsible for the documents can help define realistic questions, while a developer investigates retrieval. Use this resource when that is the problem in front of you. Its scope is narrower than general AI adoption advice, and the examples do not predict results for your own documents.

6. Jeremy Howard: keep learning and maintaining the software

Jeremy Howard on X connects practical learning with building software. In Build to Last, he discusses understanding code and preserving software craft while using AI. The piece includes an interview with Chris Lattner and a discussion of the Solveit workspace. Read the author's argument, the interview and the product discussion with those different sources in mind.

Someone will need to diagnose failures and change the application as it grows. Consider what that person needs to understand about the code now, including code produced with an agent. Howard's perspective is particularly relevant to people who are building software and want to keep learning through the work. It is a learning and engineering argument, rather than evidence of a particular cost or productivity result for your business.

7. Harrison Chase: decide how an agent is allowed to work

Harrison Chase on X is useful when you need to design the flow around an agent. In 3 Years of Graph Engineering with LangGraph, coauthored with Sydney Runkle, he explains nodes, transitions and shared state. A step can be ordinary code, a model call or an agent with its own loop. The article also explains where a fixed graph can be too restrictive.

Use the distinction to draw your application before choosing a framework. Which steps must happen in a known order? Where can the model choose the next action? Where should execution pause for a person? A document search may have a predictable sequence, while an open research task may need a more flexible loop. This is an architecture discussion from the people building LangGraph, with a clear product viewpoint. It gives you design questions to test against your workflow, rather than an independent comparison of every framework.

8. Lilian Weng: understand the system surrounding the model

Lilian Weng on X is a route into the research behind agent design. Her Harness Engineering for Self-Improvement survey examines the software surrounding a model: how it handles context, uses tools, retains state and evaluates its work. Her earlier LLM Powered Autonomous Agents gives a foundation in planning, memory and tool use.

The newer survey is worth reading when an agent loses track of a long task or a proposed self-improvement loop is difficult to assess. Follow the references behind the relevant design, and ask what the experiment actually measured. Weng discusses persistent files, explicit delegation and the danger of optimizing against an inadequate verifier. This is a technical literature map, so the experiments and benchmark results belong to their cited authors. The older agent survey is a useful starting point whose examples need to be read in their original date and context.

9. Shreya Shankar: turn document collections into a data workflow

Shreya Shankar on X adds a document-processing perspective. She is the first author of DocETL, a project for processing structured and unstructured collections with language models. Its documentation describes operations such as mapping over records, filtering them and reducing results, with Python and YAML examples. Her own site connects the project to her work.

Start here when the task is to extract or organize information across many documents. Describe the fields or categories you need, then examine a small set of outputs before increasing the workload. That is a different question from retrieving a passage to answer an individual query. DocETL also documents pipeline optimization, but choosing useful quality criteria still depends on the task. The quick start assumes technical setup and model-provider access; check the processing costs and error patterns on your own sample before treating it as a production pipeline.

10. Eugene Yan: inspect the decisions inside a built AI product

Eugene Yan on X publishes detailed accounts of AI systems and products. Building AI Reading Club explains his reading-assistant prototype, including how selected text and the current page provide context, when other book content is retrieved, and how features such as recaps and quizzes fit the interaction. The value is in the implementation decisions you can examine.

Read it when you want to see how an AI feature fits into something a person is already doing. What context is available at the moment they ask a question? When would retrieving more help, and when would it interrupt the experience? Yan also connects implementation choices in Patterns for Building LLM-based Systems & Products, including caching and defensive user experience. AI Reading Club is explicitly a prototype. Its design is a worked example to learn from, with no implied evidence that the same features will succeed in another product.

Choose a source alongside a piece of work

Pick the question that is holding up your current work and begin with the relevant open resource. Read enough to identify something you can investigate with your team: a model behaviour, a failed answer, a retrieval problem or a part of the code nobody can explain.

A useful next conversation might be with the person who knows the task, the developer building the application or the colleague who will maintain it. You can also talk with me about applying AI to your work.

Sources

Sources checked on 17 October 2026.