The Toolkit

Coding agents do not replace the ordinary tools of computational work; they use them. The agent runs commands in a shell, records its work with Git, shares it through GitHub, and writes Python, Markdown, and LaTeX. You do not need to master these tools before starting, but you should know what each one is for, so you can follow what the agent does and judge whether it is doing the right thing.

This chapter is a bill of materials: what each tool is, why we use it, and where to learn more. It is not a tutorial.

Ask the agent to teach you.

Agents are patient, knowledgeable tutors for every tool here, and they can read this manual. Give the agent this page and ask about the tool you want to understand, for example: “Read https://dunnlab.org/dunnlab_code/toolkit.html, then explain what Git is and show me how I would use it in this project.” The agent then explains with the same framing as the manual, and can show you on your own files.

Principles behind the choices

Prefer industry-standard tools over domain-specific ones. This single principle is behind most of the choices below. It lets you draw on the enormous investment industry makes in data tooling, it gives you skills that are useful outside academia, and it means that when something breaks, someone has already written about it. It also matters for agents: they work best with tools that are widely used, because those are the tools they have seen most.

Work from the terminal. We run agents and most tools from the command line, even while editing in an editor. An agent can run a command, read its complete output, retry it, and record what happened. A workflow that depends on clicking through a graphical interface is much harder for an agent to operate on its own.

Keep work in plain text. Prefer text formats whenever they can represent the work adequately: Markdown or LaTeX rather than Word documents, CSV or TSV rather than Excel workbooks, and scripts or configuration files rather than settings stored inside an application. Plain text can be searched, compared line by line, tracked by Git, and read and edited directly by agents, and it stays readable as software changes. Use a binary format when its features are genuinely needed, but keep the source of record in text.

The optional dunnlab-coding-defaults skill encodes these preferences for Claude Code.

The shell and terminal

What it is. The shell is a program that runs commands you type: listing files, moving them, starting programs, and combining small programs into larger tasks. The terminal is the window the shell runs in. On macOS and Linux the shell is usually zsh or bash.

Why we use it. The shell is how agents act on your computer. Nearly every scientific tool can be run from it, commands can be saved in scripts and rerun exactly, and the same commands work on your laptop, a lab server, or a cluster. You will mostly read commands rather than write them, so the useful skill is being able to tell what a command will do before approving it.

Learn more: The Unix Shell from Software Carpentry.

Git

What it is. Git is a version-control system. It records the history of a project’s files as a series of snapshots called commits, each with a message explaining the change. A project tracked by Git is a repository. Git can also keep parallel lines of work, called branches, and merge them back together.

Why we use it. Git is how you can let an agent make changes without fear: any change can be inspected, compared with what came before, and undone. The commit history is also a record of how the project reached its current state, including the work you delegated to AI. Let the agent make a small commit after each verified step and write the message explaining why the change was made.

Git is designed for code and other small text files, not data. Do not store large data files or analysis results in a repository. GitHub blocks any single file over 100 MB, and a well-kept analysis repository is usually far smaller than that.

Learn more: Version Control with Git from Software Carpentry, and the free book Pro Git.

GitHub

What it is. GitHub hosts Git repositories online. Beyond storing a copy, it adds tools for working together: issues for tracking tasks, pull requests for proposing and reviewing changes, and actions that run checks such as tests automatically on every change.

Why we use it. GitHub is the backbone of how we share and coordinate work. Treat the repository as the project’s durable workspace: the plan is a file in it, code and documentation evolve beside it, issues record work not yet done, and commits record verified steps. People and agents then share the same history. Software Engineering describes how issues, branches, and releases fit together.

Install the GitHub CLI (gh) and authenticate it once with gh auth login. The agent can then create repositories, file and close issues, and open pull requests from the terminal. Authentication lets the agent act under your account, so do this only in an environment you trust.

Learn more: GitHub’s getting-started guide.

Visual Studio Code

What it is. Visual Studio Code (VS Code) is a free code editor. It shows a project’s files, highlights code, displays Git changes, and has a built-in terminal.

Why we use it. It puts the files, the terminal, and Git changes in one window, which makes it easy to watch and review what an agent is doing. Its extensions support every language here, and its Remote SSH extension edits files on another computer as if they were local. Both Claude Code and Codex integrate with it, but we still run agents in the terminal.

Learn more: VS Code documentation.

Python

What it is. Python is a general-purpose programming language, and our default for data analysis and scripting.

Why we use it. Python is one of the most widely used languages in the world, in industry as well as science. Its libraries cover data handling, statistics, machine learning, plotting, and bioinformatics, and Python skills transfer far beyond biology. Agents also write it especially well, because so much Python exists to learn from.

Its usual companions:

• conda or mamba install Python and other software into separate environments, so each project gets the versions it needs without interfering with others. Bioconda provides thousands of bioinformatics tools this way.
• Jupyter notebooks mix code, results, and notes in one document. They are good for exploration; reusable analysis usually moves into scripts or a workflow.
• Ruff formats and checks Python code. Software Engineering explains why that matters.

Learn more: the official Python tutorial, and the free Python Data Science Handbook.

R

What it is. R is a language built for statistics, widely used in biology.

Why we use it. R is the right choice when an analysis needs packages that exist only there, such as Seurat or much of Bioconductor, when it is what you know and it works, or when you join a team that has chosen it. Using R in those cases is a normal outcome, not a failure. Otherwise we prefer Python, because R is a niche language by comparison and its skills travel less far.

Learn more: the free book R for Data Science.

Rust

What it is. Rust is a programming language for fast, reliable software.

Why we use it. For tools where speed and memory use dominate, such as processing billions of sequencing reads, Rust runs far faster than Python. Its strict compiler catches many mistakes before the program ever runs, which suits agent-written code: much of the checking happens automatically. Most analyses never need it.

Learn more: The Rust Programming Language, the official free book.

Markdown

What it is. Markdown is a lightweight way to format plain text: # for headings, *asterisks* for emphasis, - for bullet lists. The file stays readable as plain text, and tools render it as formatted pages. This manual is written in Markdown.

Why we use it. Markdown is the format for everything in a project that is not code or a manuscript: README files, plans, notes, and agent instructions such as AGENTS.md. It is easy to write, easy for agents to read and edit, and displayed nicely on GitHub.

Learn more: GitHub’s guide to writing Markdown.

LaTeX

What it is. LaTeX is a typesetting system. You write plain text with commands such as \section{Methods} or \cite{dunn2008}, and LaTeX produces a professionally typeset PDF.

Why we use it. LaTeX produces the best-typeset documents for science, handles equations superbly, and is what many journals’ templates are built on. We rarely write it directly: Quarto uses LaTeX behind the scenes to make PDFs, and can keep the LaTeX source for journals that ask for it. Knowing a little LaTeX helps when adjusting a journal template or writing an equation.

Learn more: Overleaf’s LaTeX documentation.

Quarto

What it is. Quarto turns plain-text documents written in Markdown into PDF (through LaTeX), Word, and HTML. Documents can insert values and tables from files, and can also contain code that runs when the document is built.

Why we use it. Quarto is our format for manuscripts and reports. One plain-text source produces the PDF for journals and readers and the Word file for co-authors, Git tracks every change, and agents can edit it directly. Numbers, tables, and figures come straight from files the analysis generates, so the manuscript never contains results copied by hand. Quarto journal extensions provide many journals’ templates. Dunn Lab Practices describes how we use it.

Learn more: the Quarto guide.

Elsewhere in this manual

• SSH and tmux, for working on other computers and keeping sessions alive: Working Across Computers.
• Snakemake, for multi-step analyses: Software Engineering.