Skip to content

Blog

Dated, opinionated writing: field reports from building and running things, and notes on tooling that will look different in a year.

This is deliberately separate from the Engineering Notes. Those are evergreen references, maintained in place as understanding improves. Posts here are snapshots — they carry a date and a version stamp because they describe a moving target, and they are left standing rather than quietly updated.

Posts are filed under the same topic vocabulary as the rest of the site.

From Computer Vision to Remote Sensing: A 2026 Model Landscape

A concise map of tasks, architectures, and models — and how the CV world's ideas carry over (and don't) to remote sensing. Written as a jumping-off point for deeper research, not a tutorial.

A snapshot of the 2026 landscape. Model names in this space turn over within a year; the structural arguments (band mismatch, label scarcity, why U-Net persists) should outlast them.

Most computer-vision advice assumes a three-band photograph. Satellite imagery rarely is one: Sentinel-2 records 13 bands, SAR has no optical channel at all, and hyperspectral sensors record hundreds. That single mismatch explains most of where remote sensing follows mainstream CV and where it quietly goes its own way.

This post maps the two worlds side by side: the core CV tasks and their go-to models, why the standard pipeline breaks on satellite data, why a 2015 architecture is still the remote-sensing default, and where geospatial foundation models and precomputed embeddings now fit.

Claude Code Across a Laptop and an HPC Cluster

What travels, what doesn't, and how to build permissions you can actually trust.

Verified against Claude Code v2.1.222, August 2026. Permission and sandbox behaviour changes fast; check the version before trusting the specifics.

Our group's compute loop looks like this. Write and test code on a laptop, where iteration is cheap. Push to the cluster through GitHub or rsync. Run there, because that is where the cores, the memory, and the multi-terabyte project storage live. Then stay on the cluster to diagnose: read the logs, inspect the outputs, work out why run 14 disagrees with run 13.

Claude Code is useful at both ends of that loop, and the diagnosis end is where it earns the most. But when you install it on the cluster it arrives knowing nothing. No project context, no permission guardrails, none of the accumulated understanding from months of sessions on the laptop.

This is not a bug, and the fix is not to copy your home directory across. The fix is to understand that Claude Code keeps state in three separate systems, each with a different answer to the question does this cross machine boundaries?

Get it wrong and you either work blind on the cluster, or, worse, run an agent there with no guardrails on hardware you share with everyone else at your institution.