Posts | Shunyang Wang

How to Automate the Last Mile in the Lab

Sun, 07 Jun 2026 00:00:00 +0000

Orchestration, lab informatics systems such as LIMS and ELNs, liquid handlers, and robotic arms are hot topics in lab automation. Recent examples include Coscientist, which connected a large language model with laboratory tools, and A-Lab, which connected machine learning, robotics, and material characterization. OpenAI and Ginkgo Bioworks also recently used GPT-5 with a cloud lab to run closed-loop experiments for cell-free protein synthesis.

These systems can automate experiments and speed up the testing and validation of ideas. However, they can also be expensive and time-consuming to build. Today, they are often better at replacing repeated operations than replacing the daily scientific decisions made by scientists. Even in the OpenAI and Ginkgo study, human oversight was still needed for protocol improvements and reagent handling.

What is the last mile in the lab?

There are also bottlenecks where a small investment can save a lot of valuable scientists’ time, but a general solution may not fit. These projects may not support a new business by themselves. They often need highly specific optimization and close collaboration with scientists. I call this the last mile in lab automation: the small but essential steps between a working tool and an end-to-end scientific workflow.

For example, identifying the structures of impurities or drug metabolites often requires evidence from LC-MS, MS/MS, NMR, and other experiments. MS alone may not identify the exact position of a modification or distinguish isomers, so scientists need to cross-check different data and do a large amount of manual annotation (Prakash et al., 2007).

Another example is choosing liquid chromatography methods for purification. This can require method screening, analytical runs, and then preparative runs. Each round needs decisions and setup and can use a lot of samples, solvents, and other consumables. Published workflows also describe screening analytical conditions before scaling promising methods to preparative purification (Font et al., 2011). What if we can automate some of these experience- and knowledge-based decisions?

Why the last mile remains manual

These last-mile tasks often remain manual because the work is spread across different instruments, file formats, and software. The person who understands the scientific question may not own the instruments or the data systems. The workflow may also change from one project to another and still needs validation.

In the structure annotation example, evidence from different instruments needs to be connected before a scientist can make a decision. In the chromatography example, results from one screening run affect the setup of the next run. The difficult part is not always running the instrument. It is connecting the data, decisions, and next actions.

The last mile connects the scientific need, laboratory work, data, decisions, and the next experiment.

Find the real bottleneck

Finding the real bottleneck is why we automate the last mile. We are here to help scientists reduce the problems that take the most time and effort, not to force a top-down automation plan across the whole lab. This also gives us the advantage of working closely with scientists, understanding their real needs, and getting them fully involved in the project.

Learnings

Through my work, I have had the advantage of working closely with scientists from different parts of the drug discovery life cycle and with very different backgrounds. These are the lessons that I found general enough across projects.

You need to win the trust

We are in a new period of automation, and no one has all the answers. The old methods are already validated, robust, and familiar to scientists. We need to get scientists on board by winning their trust.

We should start small and always provide verifiable results. This does not mean that we cannot talk about the big picture, but we should plan in phases. When we reach each milestone, we gain more trust and move closer to the big picture. Do not think that starting small is a waste of talent. During this process, we can build the infrastructure, identify barriers, and change direction more easily. We can also show what we are capable of and where the limits of automation are. This will help with future collaborations.

Get a prototype as soon as possible

You and your collaborators may come from very different backgrounds. Sometimes, after a long discussion, both sides still understand the problem differently. It can feel like you are talking past each other. In this case, an early prototype can help communication.

Scientists may not be fully clear about what they need. A hands-on demo can help them clarify the request.
They will have a better understanding of the complexity.
A quick prototype can prevent you from building too much before collaborators ask to start over.

This is a bitter lesson I have learned more than once.

Save as much useful data as possible

As a machine learning scientist working in lab automation, one of my most common and time-consuming problems is data. Why do we not collect data intentionally while building new tools?

A mass spectrometry database built for spectral matching can also save method information and retention times, even if they are not needed at first. These data may later support retention time prediction, while the method information can help define how transferable a model is.

We should also help guide data collection and point out missing data that may be useful later. For example, if a model shows that changes in the environment over time are more important than a few separate readings, we can start collecting more time points for cell culture.

Separate models from complex tasks

I will discuss this more in another article. Briefly, we should build the system in modules and define the scope of the current model. What are its inputs and outputs? How does it fit into future steps? Saying no to a request because it is outside the current scope can make the discussion much easier.

Leave extendable plugins for the future

Based on the last lesson, we should also think about future extensions. This includes plugin design, database schemas, model transferability, and new modalities. For example, a workflow built for small molecules may reuse the same pipelines and experiment setup for peptides while changing the machine learning model in the backend.

Closing thoughts

The last mile may not look as exciting as a fully automated lab. However, these small and highly specific improvements can remove real bottlenecks from scientists’ daily work. Large companies and startups may first capture the low-hanging fruit and the most profitable parts of lab automation. The real challenge of last-mile automation starts after that. These problems are highly specific to each organization and depend heavily on internal collaboration and development. This is why the practical approach described above matters: start from scientists’ needs, keep the big picture in mind, and move toward it in small steps. Small results help build trust, prototypes help us learn, and useful data supports the next steps.

A Chemist's Notes on Agentic Coding using Claude

Mon, 25 May 2026 00:00:00 +0000

Six weeks of token usage, in numbers. I’m a slow adopter. This is what catching up looks like.

Where I started

I’m a computational chemist at a pharma. I write code, but I’m slow to pick up new tools. This time I want that to change.

The timeline:

GPT era (late 2022 – mid 2023): I thought it was an ads event. Overpresented, underdelivering.
Mid 2023: Tried coding with it. Copy-paste from chat to IDE, paste back, ran it. Treated it like a slightly faster Stack Overflow.
Mid 2024 – early 2025: Started using LLMs for information search instead of Google. The switch was about a year behind when I should have made it.
Through 2025: Started reviewing what it wrote, line by line. Caught some things, missed others. Trust grew slowly.
Spring 2026 (now): Letting an agent take over most of the code-writing for a dozen active projects. Reviewing diffs, not lines. Weekly load grew about 12× in five weeks.

This essay is what a slow adopter looks like when the thing finally clicks.

Why I care about token usage

It is obviously wrong to optimize for maximum tokens, but as a beginner I realized token use is a decent proxy for how familiar I am with the tool.

More tokens per task usually means fewer back-and-forth turns, more self-evaluation, and more iteration. It pushed me to think about better harnessing and how to interact with the agent like a code reviewer.

Through this journey, I learned how to set up tools, skills, and memories.

What the numbers say

Weekly volume, normalized to week 1 (laptop + cluster combined):

The eye goes to the spike on the right — week 5 was about 12× week 1. But the more interesting number is hidden in weeks 3 and 4: load stayed level while requests dropped (3,167 → 1,719). I wasn’t running more turns. I was running heavier ones.

86K → 216K is a 2.5× fold change in payload per call. Output tokens per call grew 1.5× over the same window (512 → 778). Much denser sessions.

What’s more, I slowly moved all work from my laptop to the cluster — long-running sessions under tmux or Zellij, with a sandbox where the agent could run autonomously without me re-approving every command.

Six weeks, six unlocks

W1 — 186M tokens · 2,164 requests

First cluster sessions. First three skill templates landed: experiment runs, cluster submission, PR descriptions. Earliest memory rules: file scope (don’t touch other users’ code), review-figures-before-commit. The unlock was vocabulary — naming the rules the agent would follow.

W2 — 544M tokens · 3,551 requests

First two project repos shipped. No new infrastructure — pure use of W1 scaffolding. 3× the token volume of W1; the unlock was just committing to real projects.

W3 — 382M tokens · 3,167 requests

“No login-node abuse” memory written after a long BFS scan slowed the host. Slurm cluster reference memory added.

W4 — 362M tokens · 1,719 requests

Heavy iteration on existing projects. Set up repos and READMEs so projects could reference each other.

W5 — 1,762M tokens · 8,168 requests

Six new project repos shipped first commits in five days. First skill promotions — a job-resume skill and a figure-review skill, both graduated from feedback memories that kept firing. First three hooks landed: a Stop-event lint, a Stop-event commit-recommend, and a PreToolUse pre-commit hook that blocks git commit when the staged diff touches numerical logic until the math is articulated in the message body. Multiagent workloads also drove the usage spike. The unlock was compounding — projects, skills, and hooks all landed the same week because the spine made each one cheap.

W6 — 1,094M tokens · 5,063 requests

Tightening week. Two new PreToolUse hooks finally landed: a Slurm-submission validator and a login-node-abuse blocker (promoted from the W3 memory to a skill). Four new diagnostic skills — status dashboards across projects, cluster shortcuts. Eleven new memory rules, most of them workflow tightenings after I ran the built-in /insights command.

Each week added something the next week built on. None of it was strategic — each piece came from a specific friction in the prior week that I got tired of.

What changed

In the order I learned them. Not all stuck the first time.

1. Build infrastructure before features

Weeks 1–2 were 80% project work. By week 5 it was the inverse — and that’s when output went up. Hooks, memories, skills, scaffolding compound. New projects start at week-5 productivity.

2. Solve permissions once

Every “do you want to run this?” is friction. The project’s permissions config ended up with 91 shell allowlist entries and 17 file-access entries. Plus a deny list covering 8 sibling user directories so I can’t edit colleagues’ code by accident. Most operations now run without a prompt. Sandbox or running in a container is a better option, but both are limited by available resources.

3. Solve the boring plumbing

Set up the cluster submission path so a sandboxed compute environment could submit jobs without a shared filesystem. Remote VS Code pointed at GPU nodes. Job logs streamed back to my laptop without manual rsync. Each one removes ~5 minutes of friction × dozens of times per day.

4. Ask the agent to ask me questions

“Ask me three clarifying questions before you start.”

Highest-impact line I added to my prompts. Half the time the questions made me realize I didn’t know what I wanted.

5. Plan before execute

Plan mode. Reviewable artifact before any code is written. Saves the revert-and-retry cycle.

6. Write memories with reasoning, not just rules

Every memory file has a Why: line and a How to apply: line. The agent learns the rule’s boundary, not just the rule. Memories that say “do X” without saying why decay; memories that say “do X because Y last quarter” survive.

7. Promote memories to skills when they keep firing

A “resume the partial job, don’t re-run from scratch” memory became a /resume-job invocable skill after the same procedure ran three times. Memory layer compounds through promotion — not just by accumulation.

8. Let projects talk

One project consumes utility tools written in another. A third will feed its outputs back as priors into the first. The portfolio isn’t 12 independent projects — it’s a graph. Each project’s outputs become another’s inputs.

9. Multiagent for parallel branches

Background subagents for independent tasks (search this repo / draft this analysis / find this dataset). Subagent context shields the main session from large outputs. Three branches in flight without context contamination.

Unexpected side effects

Negative results published in the repo. A full fine-tune on a published embedding model lost to a simpler baseline. Logged as Exp X.YZ NEGATIVE, linked from the project’s manuscript. Failed runs that get committed become next quarter’s prior, not buried compute.
Pre-commit quality gates. A hook that blocks git commit when staged changes touch numerical logic, until I articulate the math in the commit body. Came after I caught the agent producing markdown with estimated numbers that the actual data later contradicted by 50–100% per day. Wrong numbers don’t fail tests; they just ship. Now they fail commits instead.
Tracking my own learning. This essay exists. Tracking it makes the meta-improvements visible — like load-per-call rising while request count fell. Only see it if you look.

Infrastructure inventory

As of May 2026:

25 memory files — autonomous-mode rules, cluster-resource defaults, scoring-API references
6 skills — domain-specific reasoning, cluster-submit, experiment-run, figure-review, resume-job, PR-description
3 hooks — numerical-review gate, cluster-job-ID capture, ruff lint
119 permission entries — 91 shell allowlist, 17 file-access, 11 deny rules (maybe there are smarter ways?)
36 documented patterns — from “Agent vs Pipeline” (#1) to “Memory→skill promotion” (#36)

The portfolio plateaued at 12 once the infrastructure stopped being the bottleneck. Growth now is depth-per-project — one of the agents going Phase 1 → 6b in three days is what depth growth looks like when the spine is in place.

Analogies from chemistry

Reaction rate isn’t throughput. More turns per hour doesn’t help if half are clarifying questions. Spec quality is the rate-limiting step. So I ask the agent to ask me questions instead of letting it guess.

Catalysts beat reagents. A small piece of well-placed infrastructure accelerates everything downstream. A hook that blocks numerical commits costs nothing and prevents an entire failure mode.

For a chemist starting today

One project. One CLAUDE.md. One AGENTS.md. Don’t scaffold for 12 on day one.
Wait until you’ve corrected the agent on the same thing three times before writing the first memory. Earlier than that and the rules don’t generalize.
Solve permissions early. Twenty allowlist entries on week one removes hundreds of prompts on week three.
Tell the agent to ask you clarifying questions when you’re vague.
Plan before execute.
Track your weekly load. Mine grew 12× in five weeks; without a routine pull on usage telemetry I wouldn’t have noticed.

What’s next

Now I can easily use up my weekly quota, so I need to think about token efficiency.

The thing that gets faster isn’t the adoption itself. It’s the time between seeing other people do it and deciding to actually try it.

Run a Free Local LLM and Share It with Your Family and Friends in 4 Hours

Wed, 29 Jan 2025 00:00:00 +0000

Introduction

The release of the distilled DeepSeek-R1 model has revolutionized the field. I decided to build one locally, and to my surprise, the process was smoother than I expected. With the knowledge I had, I was able to deploy the model and allow my family to access it through ZeroTier. This tutorial will guide you through setting up a local DeepSeek-R1 model using Open WebUI, ZeroTier, and Docker on Windows with an NVIDIA RTX 3090. (According to my tests, an AMD Ryzen 5900X can also support basic functions, albeit with a response time of several minutes.) By following these steps, you’ll be able to run DeepSeek-R1 locally and share it with your family and friends over the network.

Below is a comparison of DeepSeek-R1’s performance against other models in different benchmarks, highlighting its strengths in accuracy and efficiency:

With 24GB of memory, DeepSeek-R1:32B can achieve 90% of the performance of ChatGPT-O1. This makes it a powerful yet cost-effective alternative for local deployments, especially for users who need high accuracy but want to run models independently without relying on cloud-based solutions.

Prerequisites

Before proceeding, ensure you have the following:

A Windows machine (Windows 10/11 recommended) with an NVIDIA RTX 3090 (You can opt for a smaller model if you have limited GPU memory.)
Docker installed (Download Docker)
NVIDIA GPU drivers and CUDA installed (Download CUDA)
Docker CUDA Container (NVIDIA Docker CUDA)

Step 1: Install and Configure Open WebUI (1 hour)

Open WebUI is a user-friendly interface for interacting with local LLMs.

Run Open WebUI with Docker using GPU support:

docker run --user=0:0 \
--env=USE_CUDA_DOCKER=true --env=USE_CUDA_DOCKER_VER=cu121 \
--env=USE_EMBEDDING_MODEL_DOCKER=sentence-transformers/all-MiniLM-L6-v2 \
--volume=open-webui:/app/backend/data --network=bridge --workdir=/app/backend \
-p 3000:8080 --runtime=nvidia -d ghcr.io/open-webui/open-webui:cuda

Explanation of Main Parameters

--runtime=nvidia: Enables GPU acceleration for the container, allowing Open WebUI to leverage CUDA for faster performance.
-p 3000:8080: Maps port 8080 inside the container to 3000 on the host machine, allowing access via http://localhost:3000.
--volume=open-webui:/app/backend/data: Ensures persistent storage for Open WebUI’s data, preventing loss after container restarts.
--env=USE_CUDA_DOCKER=true: Configures the container to use CUDA, enabling GPU acceleration for AI model execution.
--env=USE_EMBEDDING_MODEL_DOCKER=sentence-transformers/all-MiniLM-L6-v2: Specifies the embedding model to be used within the container.
--network=bridge: Sets the container to use a bridge network mode, allowing it to communicate with other services inside the same Docker network.
-d: Runs the container in detached mode, so it continues running in the background.

Note: The --hostname parameter is optional and generally not required unless you need to set a specific hostname inside the container.

Step 2: Configure Open WebUI and Download the Model (1 hour)

Open your browser and access Open WebUI at http://localhost:3000.
Create and configure your login credentials.
Pull the DeepSeek-R1:32B model within Open WebUI.
Test the model locally and monitor your CPU/GPU usage to ensure optimal performance.

Step 3: Enable Remote Access with ZeroTier (40 minutes)

ZeroTier enables secure remote access to your local setup, allowing your family and friends to connect. The free version supports up to 50 connected devices, making it ideal for personal and small-scale use.

Download and install ZeroTier from ZeroTier’s website.
Create a ZeroTier account and set up a new network.
Join the network from your Windows machine:
```
zerotier-cli join <network_id>
```
Or, use the ZeroTier GUI to join the network, for both WebUI server and user computer. You need to repeat this every time having a new user device. (Mac, Windows, Pad, Phone…)
Authorize your device in the ZeroTier web console.
Retrieve your virtual IP address for remote access and share it with trusted users.
Configure managed routes to properly map the ports through ZeroTier for external access.

Step 4: Configure Windows Firewall for External Access (20 minutes)

To allow external access, configure the Windows firewall:

Open Windows Defender Firewall.
Navigate to Advanced Settings > Inbound Rules.
Create a new rule to allow inbound traffic on the required port (e.g., 3000).
Apply the rule and restart the system if needed.

Step 5: Enjoy Your Local LLM Server (30 minutes)

With Open WebUI set up and ZeroTier configured, your local LLM model is now accessible over the network. Access the server using your ZeroTier-assigned IP and the configured port:

http://<zerotier_ip>:3000

Share this link with trusted users to allow them access to your local LLM without exposing it to the public internet. Add them as new users if needed.

Troubleshooting and Optimization

Common Issues

Docker not starting: Ensure virtualization is enabled in BIOS.
ZeroTier not connecting: Check firewall settings and authorize the device.
Slow performance: Ensure CUDA is correctly installed and the GPU is being utilized.

Performance Tuning

Allocate more resources to Docker if needed.
Use a dedicated GPU like the RTX 3090 for faster inference.

Conclusion

You now have a fully functional local DeepSeek-R1 setup with Open WebUI, ZeroTier, and Docker on Windows. You can interact with the model via Open WebUI and even share it with your family and friends over the network using ZeroTier.

For further improvements, consider integrating additional plugins or experimenting with different model configurations. Happy coding!