# .plan-26-14: Tracking AI screen time and escaping to pen and paper

*2026-04-05 — note*


## Integrating AI 'screen time' and tracking into my life

<figure class="image-right-float"><img src="/images/26n14-ss-2.webp" alt="Top reviews for Sinamon coffee near my old haunt the Ashby at Queens!" title="Top reviews for Sinamon coffee near my old haunt the Ashby at Queens!" loading="lazy" srcset="/images/26n14-ss-2.768.webp 768w, /images/26n14-ss-2.640.webp 640w, /images/26n14-ss-2.480.webp 480w, /images/26n14-ss-2.320.webp 320w, /images/26n14-ss-2.2560.webp 2560w, /images/26n14-ss-2.1920.webp 1920w, /images/26n14-ss-2.1600.webp 1600w, /images/26n14-ss-2.1440.webp 1440w, /images/26n14-ss-2.1280.webp 1280w, /images/26n14-ss-2.1024.webp 1024w"><figcaption>Top reviews for Sinamon coffee near my old haunt the Ashby at Queens!</figcaption></figure>
I've been in Belfast this week again and had a nice coffee chat with [Patrick Ferris](https://patrick.sirref.org) about
the value of building low-level systems code by hand, since it's the discovery
of accidental/hidden interfaces and hacks that makes this whole area so much fun.
Later that day I ran across the most [thoughtful post](https://bsky.app/profile/minaskar.bsky.social/post/3mibst6ojfc2s) on learning and AI I've
read yet:

>  I'm arguing that the way we use them matters more than whether we use them,
> and that the distinction between tool use and cognitive outsourcing is the
> single most important line in this entire conversation, and that almost
> nobody is drawing it clearly.
> 
>  Schwartz can use Claude to write a paper because Schwartz already knows the
> physics. His decades of experience are the immune system that catches
> Claude's hallucinations. **A first-year student using the same tool, on the
> same problem, with the same supervisor giving the same feedback, produces
> the same output with none of the understanding**.  The paper looks identical.
> The scientist doesn't.
> 
> <cite>\-- [The machines are fine. I'm worried about us](https://ergosphere.blog/posts/the-machines-are-fine/), Minas Karamanis, 2026</cite>

I have been feeling the effects of nonstop [agentic coding](https://anil.recoil.org/notes/aoah-2025) in December myself! The stuff I waved through a Claude session does have some utility, but I fear the second-order effects of using it on my own cognition are far more sinister and damaging. Marvin Hagemeister called this [DDoSing the human brain](https://marvinh.dev/blog/ddosing-the-human-brain/) as (human) thinking context is spent just trying to figure out and steer the flood of generated code rather than building steady understanding.
However, it doesn't make sense to wish coding agents away; instead I want to figure out how to firewall its use and adapt teaching techniques as quickly as possible to the new normal.

The first step is simply to _track_ my usage, so so I put together a proposal for [AI provenance disclosure](https://anil.recoil.org/notes/opam-ai-disclosure) for OCaml code. This is a voluntary, low-level mechanism that I think is an important discipline to adopt to give us the equivalent of "screen time" for our coding cognition. Early feedback on the [proposal](https://github.com/avsm/ocaml-ai-disclosure) and the [OCaml Discuss thread](https://discuss.ocaml.org/t/a-proposal-for-voluntary-ai-disclosure-in-ocaml-code/17950) has largely been around why I don't do something bigger (for all languages), but I'm very deliberately keeping it focused on the main tools I use and not broadening it so the point of being uselessly general. I'll round up the feedback later this week as more comes in after the Easter break.

### Desktop environments need to support flow states, not destroy it

<figure class="image-right-float"><img src="/images/26n14-ss-1.webp" alt="Bangor marina this week after Storm Dave whipped through NI was a peaceful place to relax!" title="Bangor marina this week after Storm Dave whipped through NI was a peaceful place to relax!" loading="lazy" srcset="/images/26n14-ss-1.768.webp 768w, /images/26n14-ss-1.640.webp 640w, /images/26n14-ss-1.480.webp 480w, /images/26n14-ss-1.3840.webp 3840w, /images/26n14-ss-1.320.webp 320w, /images/26n14-ss-1.2560.webp 2560w, /images/26n14-ss-1.1920.webp 1920w, /images/26n14-ss-1.1600.webp 1600w, /images/26n14-ss-1.1440.webp 1440w, /images/26n14-ss-1.1280.webp 1280w, /images/26n14-ss-1.1024.webp 1024w"><figcaption>Bangor marina this week after Storm Dave whipped through NI was a peaceful place to relax!</figcaption></figure>
I've also been noticing that my desktop environments do an increasingly terrible job
of preserving my focus flow state.  What I want from a desktop environment is
to be able to take a batch of tools like my browser, my terminal, and email
client, and then _narrow all of them around_ a specific task.

For example, if I'm doing paper reviews for a conference then I want browser
tabs around my HotCRP, a terminal to take notes in my vim, and an email client
with searches setup around that conference so I can find instructions from the
chairs or other matters. But right now every single application seems to
become general enough to the point where it's impossible to avoid a reminders
app telling me about weekly shopping or some pointless university admin.

<figure class="image-right-float"><img src="/images/pandemic-flow-1.webp" alt="This was my pandemic-era flow state" title="This was my pandemic-era flow state" loading="lazy" srcset="/images/pandemic-flow-1.768.webp 768w, /images/pandemic-flow-1.640.webp 640w, /images/pandemic-flow-1.480.webp 480w, /images/pandemic-flow-1.320.webp 320w, /images/pandemic-flow-1.1024.webp 1024w"><figcaption>This was my pandemic-era flow state</figcaption></figure>
As a result, when I do something that needs deep focus I *still* print them out
onto physical paper and review them the old-fashioned way with a pen. That
kind of sucks in 2026\!

It's not all doom and gloom though, as Adrian Sampson built [Analog Library](https://al.radbox.org/) as a distraction-free way of reading papers without the [AI gunk that pervades the ACM](https://anil.recoil.org/notes/acm-ai-recs) nowadays. [Kagi](https://kagi.com) is a search engine I pay for, and it supports a good degree of personalisation and filtering. For example I now use this tip from Adrian for all searches to the ACM DL to redirect to his site in the search results in instead:

> If you use Kagi as your search engine, add this rule to your redirects to
> rewrite result URLs to point to Analog Library:
> 
> `^https://dl.acm.org/doi/(abs/)?(.*)|https://al.radbox.org/doi/$2`

### iOS and how terrible it is for elderly relatives

While I'm ranting about desktop interfaces that fight you, I've also been
struggling with the terrible iOS interface while helping my elderly
parents recently. There are lots of issues around font sizing (try increasing
the default and see how badly the UI works on an iPhone).

But one iOS-ism in particular took the mickey this week. In the latest iOS 26.4 the autocorrect dictionary is allegedly improved, and my parents really need this as they often text in different languages and are getting increasingly confused by the poor old autocorrect. To take advantage of the new improvements, you need [manually reset the existing dictionaries first](https://www.cultofmac.com/how-to/reset-iphone-ipad-keyboard-dictionary). How hard could this be, right? In order to do this, you need to terrifyingly navigate into:

1. Settings (*Q: what are we setting here? But ok lets go*)
2. General (*Q: what does 'general' mean? Let's check all the more specific menus first to figure it out\!*)
3. Transfer or Reset (*Q: wait, I don't want to transfer my phone to anyone\!*)
4. Reset (*Q: oh jesus what's all this about preparing for a new iphone are we deleting all my data??*)
5. Reset Keyboard Dictionary (*Q: yay i avoided deleting all my data but there's no feedback this dictionary thing worked at all*)

<figure class="image-center"><img src="/images/reset-iphone.webp" alt="(image credit: Killian Bell / Cult of Mac)" title="(image credit: Killian Bell / Cult of Mac)" loading="lazy" srcset="/images/reset-iphone.768.webp 768w, /images/reset-iphone.640.webp 640w, /images/reset-iphone.480.webp 480w, /images/reset-iphone.320.webp 320w, /images/reset-iphone.2560.webp 2560w, /images/reset-iphone.1920.webp 1920w, /images/reset-iphone.1600.webp 1600w, /images/reset-iphone.1440.webp 1440w, /images/reset-iphone.1280.webp 1280w, /images/reset-iphone.1024.webp 1024w"><figcaption>(image credit: Killian Bell / Cult of Mac)</figcaption></figure>

While doing this reset, with a bigger font size it's almost impossible to not accidentally hit the 'reset entire iPhone and lose all your data' button instead.
[Thomas Leonard](https://github.com/https://roscidus.com) has been steadily [building OCaml libraries for Wayland and input](https://roscidus.com/blog/blog/2026/03/28/input-devices/) so I'm going to attempt a switch to a Linux desktop (again) as a good excuse to use his tools! It's interesting how good a Linux desktop is at font sizing in comparison to Apple these days as well. There are many, many weird things about 2026 so far, but I never expected it to be the year of 'Linux on the desktop'.

## TESSERA hacking on geotessera 0.8 and registries

I've rounded up a bunch of feedback/PRs and released [GeoTessera 0.8.0](https://github.com/ucam-eo/geotessera/releases/tag/v0.8.0), which pulls together the recent work on [Zarr v3 cloud-native stores](https://anil.recoil.org/notes/tessera-zarr-v3-layout) and the [geo-embeddings convention](https://anil.recoil.org/notes/tessera-embeddings-convention). [Jeff Albrecht](https://github.com/geospatial-jeff) merged my [PR to geoembeddings-conventions](https://github.com/geo-embeddings/embeddings-zarr-convention/pull/2) as well, so we're now compliant with other foundation models in this space.
There's also been more [multiscales activity](https://github.com/wietzesuijker/aef-multiscales) in the community around generating overview layers for the AEF mosaic Zarr store, which handles the tricky business of downsampling int8-encoded embeddings correctly.

Next week, I'm looking at spatial indexing for the TESSERA tiles since we now have multiple producers generating embeddings, and so the client library needs a shared spatial index to keep everything consistent. I'll almost certainly stick to a UTM based indexing, but I did find [A5](https://a5geo.org) to be quite cool as the first pentagonal equal-area indexing system for the globe that I've seen.

### Ceph expansion

[Mark Elvers](https://www.tunbury.org/) has also [expanded our local Ceph storage](https://www.tunbury.org/2026/03/27/ceph-expansion/) which was getting
very squeezed indeed with all the [tile generation we've been
doing](https://geotessera.org/blog/2026-03-30-training-and-inference-at-scale). We're
up to around 1.4PB raw now in total across our various hosts (not all on Ceph
yet), and the next step is to shift my home directories onto CephFS for
networked use to see how well it works interactively. The main challenge with
doing this storage migration has been making sure that we never only have one
copy of some data while migrating a large filesystem, which is always
nerve-wracking... but we've had no disasters yet\!

### Moving OCaml infra from Scaleway to Cambridge

Mark and I have also spent some time refreshing the OCaml CI pipeline and completing the [migration from Scaleway to Cambridge](https://www.tunbury.org/2026/04/01/from-scaleway-to-cambridge/). Our Cambridge VMs run on Xen with xapi, which feels pleasingly [full-circle](https://anil.recoil.org/papers/2010-icfp-xen).
Relatedly, I've also proposed [dropping some intermediate OCaml versions from CI](https://discuss.ocaml.org/t/dropping-some-intermediate-ocaml-versions-from-ci/17947) to reduce the testing matrix. This builds on the [earlier conversation](https://anil.recoil.org/notes/deprecating-ocaml-408) about deprecating OCaml 4.08 support.

## Fun links

### Recoil email self-hosting

I've been sorting out the [recoil.org self-hosting stack](https://anil.recoil.org/notes/decentralised-stack) again during the Easter break, as complaints about spam have become a family tradition to present to me during this time. I've been evaluating using the Stalwart Mail Server, as it now has [Bulwark](https://bulwarkmail.org/), an open-source webmail client that covers email, calendar, contacts, and also files over JMAP. There's also Plume, a [Swift-native JMAP email client](https://www.reddit.com/r/stalwartlabs/comments/1s1f5yw/plume_a_swift_native_jmap_email_client_now_in/) for macOS.

This is all making me think it's to dust off my [JMAP library](https://anil.recoil.org/notes/aoah-2025-17) and migrate properly from Dovecot/Postfix. The only thing making me nervous is Stalwart's "all in one" approach to mail storage as it locks it all up into a database. I've been running Postfix with maildir for a very, very long time and I'm not excited about giving up the simplicity of flat files on disk that I can rsync...

### Hardware performance counters for OxCaml

[Sadiq Jaffer](https://toao.com) has been hacking on integrating [hardware performance counters into OxCaml's Runtime Events](https://toao.com/blog/free-performance-counters-runtime-events) ([bsky](https://bsky.app/profile/did:plc:3lovwu4e3pkhxffeer3prugb/post/3miovqimqzk2a)). His prototype uses `rdpmc` on Linux which is a tiny 20-40 cycles per sample to capture perf counters at the start and end of every runtime events span. This means you can get per-GC-phase information in quite some detail and reveals fun phase information about the effectiveness of tricks like [prefetching](https://github.com/ocaml/ocaml/pull/10195).

I'm interested in having this run on Apple Silicon too (notwithstanding my intention to switch to Linux above!). @tmcgilchrist built [mperf](https://lambdafoo.com/posts/2026-03-25-mperf-hardware-counters-macos.html) as a `perf`\-like CLI for macOS. It uses Apple's [private kperf frameworks](https://gist.github.com/ibireme/173517c208c7dc333ba962c1f0d67d12). With Sadiq's runtime integration into we're getting close to hardware-level profiling of OCaml programs all the time in production, rather than doing special 'benchmarking runs'.

### Paper of the week

I had the pleasure of finally meeting [Laure Zanna](https://en.wikipedia.org/wiki/Laure_Zanna) this week to co-organise something together. Her paper on "[The causes of sea-level rise since 1900](https://www.nature.com/articles/s41586-020-2591-3)" is therefore my paper of the week as I learn more about weather forecasting and sea ice predictions to connect [our remote sensing work](https://anil.recoil.org/projects/rsn) to this important part of climate change and biodiversity research.

The paper tries to define a "budget" for global sea-level rise so that the sum of all contributing processes (ice-mass loss, thermal expansion, reservoir impoundment) reconcile with observational data. Ice-mass loss from glaciers has caused twice as much sea-level rise as thermal expansion since 1900. I'm very curious if this could be added to TESSERA [downstream tasks](https://anil.recoil.org/papers/2025-tessera-tasks) as we hit almost a decade of embeddings now.

### Coming up

I'm back to Cambridge next week for a few days, and then I'm off to IIT Madras to see my friend [KC Sivaramakrishnan](https://kcsrk.info) and attend the launch of the **[FP Launchpad](https://fplaunchpad.org/2026/03/30/fp-launchpad-kickoff.html)**. It's a cracking lineup of speakers who I am really excited about seeing after a few years, and of course do some tourism in Chennai (where I used to live in the early 90s and go to school in \[PSBB\](noticeable mismatch with the AOHs and range maps due to the different projections)\!
Synopsis: On cognitive DDoS and AI screen time for code, a proposal for voluntary disclosure in OCaml, iOS misery, releasing GeoTessera 0.8 and spatial indexing and the FP Launchpad launch at IIT Madras.
Words: 1872

## Related

- [A Proposal for Voluntary AI Disclosure in OCaml Code](https://anil.recoil.org/notes/opam-ai-disclosure) (note, 2026-04-03)
- [TESSERA now supports the Zarr geo-embeddings convention proposal](https://anil.recoil.org/notes/tessera-embeddings-convention) (note, 2026-03-27)
- [Streaming millions of TESSERA tiles over HTTP with Zarr v3](https://anil.recoil.org/notes/tessera-zarr-v3-layout) (note, 2026-03-14)
- [Applications of the TESSERA Geospatial Foundation Model to Diverse Environmental Mapping Tasks](https://anil.recoil.org/papers/2025-tessera-tasks) (paper, 2026-01-01)
- [2025 Advent of Agentic Humps: Building a useful O(x)Caml library every day](https://anil.recoil.org/notes/aoah-2025) (note, 2025-12-26)
- [Dear ACM, you're doing AI wrong but you can still get it right](https://anil.recoil.org/notes/acm-ai-recs) (note, 2025-12-22)
- [AoAH Day 17: OCaml JMAP to plaster my painful email papercuts](https://anil.recoil.org/notes/aoah-2025-17) (note, 2025-12-17)
- [Are you still using OCaml 4.08 or earlier? If so, we need to know](https://anil.recoil.org/notes/deprecating-ocaml-408) (note, 2025-03-05)
- [Remote Sensing of Nature](https://anil.recoil.org/projects/rsn) (project, 2023-01-01)
- [Decentralised tech on Recoil](https://anil.recoil.org/notes/decentralised-stack) (note, 2021-09-19)
- [Using functional programming within an industrial product group: perspectives and perceptions](https://anil.recoil.org/papers/2010-icfp-xen) (paper, 2010-09-01)

---
Canonical: https://anil.recoil.org/notes/2026w14
Type: note
Tags: ai, ocaml, oxcaml, tessera, selfhosting, infrastructure, spatial, policy, standards
