AI agents in
statistical genetics

Research code, explicit assumptions,
reproducible checks.

j / k to navigate   / for contents   n for notes

Tasks worth delegating

Evaluate the change with the same standards as any research code.

Model, agent, environment

Model

Generates responses from the supplied context.

Agent

Uses tools to inspect files, propose edits, and run permitted checks.

Environment

Controls file access, execution, network access, and credentials.

Review both the generated code and the actions the environment allows.

VS Code tool use

The research toolchain

Editor

Source files, diagnostics, diffs, and version control.

Agent client

Instructions, model choice, tool connections, and action approvals.

Compute

A documented R environment and the project’s approved execution location.

The selected client and account must fit the project’s data-access rules.

Copilot in a research workflow

• Context: point to the relevant implementation, tests, and package documentation.
• Scope: describe the change and its acceptance criteria.
• Tools: inspect enabled actions before allowing execution.
• Review: compare the diff and validate observable behavior.

Verify the controls available in your installed client and organization.

VS Code tool use

Project instructions

Record decisions the agent cannot reliably infer from the repository.

Example: .github/copilot-instructions.md

VS Code customization

A reusable context file

## Analysis contract
- State phenotype, ancestry, build, and effect allele.
- Preserve source data. Write to explicit derived paths.
- Check IDs, duplicates, missingness, and join cardinality.

## Implementation
- R is primary. Prefer data.table for large tables.
- Use loops when they improve clarity or performance.
- Record package versions and random seeds.

## Validation
- Start with synthetic data and a small test region.
- Report what was run and what remains unverified.

A reviewable workflow

1. InspectFind existing code, inputs, conventions, and prior results.
2. PlanSpecify the model, change, outputs, and acceptance checks.
3. ImplementKeep the change small enough to review.
4. ValidateInspect failures, diagnostics, and scientific invariants.
5. RecordSave the diff, command, environment, and limitations.

Permissions and checkpoints

Use enforceable controls and a defined task scope.

Code isolation with worktrees

# Development branch with its own checkout
git worktree add -b agent/variant-qc ../variant-qc

# Separate checkout of a committed analysis version
git worktree add --detach ../analysis-run HEAD

git -C ../analysis-run rev-parse HEAD

Use distinct output directories and keep the run checkout unchanged until jobs finish.

Git worktree manual

An analysis specification

Illustrative request

Adapt the existing gene-based rare-variant workflow for a specified phenotype and chr22 pilot. First confirm the genome build, genotype and annotation format, sample matching, null model, relatedness handling, and variant masks. Propose MAF/MAC and missingness checks. Stop before a full-cohort submission.

A method name and a list of covariates are only part of the specification.

STAARpipeline documentation

Model choice by acceptance criteria

Compare candidates on a representative task before expanding scope.

Data boundaries

Start with

Synthetic examples and a reviewed schema that contains no participant records.

Review

Prompts, terminal output, paths, logs, and tool responses before external transfer.

Confirm

The permitted data, destination, account, and execution environment.

Local execution can still call a remote model. Metadata may also be sensitive.

Validation before scale

Inputs

Unique IDs, sample counts, join cardinality, missingness, build, and allele orientation.

Computation

Synthetic fixtures, a small region, reference outputs, and failed edge cases.

Inference

Model diagnostics, multiplicity, LD/ancestry compatibility, and replication.

Association, colocalization, and experimental validation answer different questions.

Cost and usage

Copilot’s current individual billing uses AI credits, with consumption tied to model and token usage.

• Inspect the allowance and spending controls for the actual account.
• Supply focused context and reuse verified intermediate results.
• Bound long-running tasks with explicit completion criteria.

Check live billing documentation before budgeting a project.

GitHub individual billing

A small, inspectable R check

library(data.table)
ids <- c("s01", "s02", "s03")
pheno <- data.table(id = rev(ids), y = c(3, 2, 1))

stopifnot(!anyDuplicated(pheno$id))
stopifnot(setequal(pheno$id, ids))
aligned <- pheno[data.table(id = ids), on = "id"]
stopifnot(identical(aligned$id, ids))
stopifnot(identical(aligned$y, c(1, 2, 3)))

This synthetic fixture tests sample alignment. It does not validate an association model.

Bounded research automation

• One trigger: a scheduled check or a completed job.
• One input: an approved status file or endpoint.
• One output: a structured summary with provenance.
• One stop rule: completion, failure, or a resource limit.

Notifications should identify an actionable change and link to its evidence.

MCP connections

MCP standardizes how AI applications connect to tools and external systems.

A protocol connection does not establish source quality or data permission.

MCP introduction

A first task for the lab

1. Choose a bounded changeFor example, a sample-alignment check in one script.
2. Document the contractInputs, outputs, dependencies, and acceptance criteria.
3. Use synthetic fixturesInclude a passing case and a case that must fail.
4. Review and recordSave the diff and test results before broader execution.

Discussion

Which part of your workflow has
the clearest acceptance test?

Research workflow essay
Return to the terminal