I spent the holiday season practicing my handwriting, which was… unexpected.

The reason why is that I got a Supernote Nomad, which was enough to warrant spending a pretty large chunk of time using it either exclusively or in tandem with my other devices.

Although it’s been only a couple of months, the part of me that initially pondered the Nomad as a “better notebook” is still reeling, since I feel like I’ve barely scratched the surface, but I’m getting ahead of myself.

Disclaimer: Supernote sent me the Nomad, a magnetic folio cover and a pen (for which I thank them), and this article follows my Review Policy.

One of the reasons I wanted to try the Nomad that will likely resonate with a lot of my readers is that I wanted a way to “unplug” while being able to capture my notes in some form of digital format.

The Internet is full of stories of people who are looking for less distracting devices, so I won’t add to those other to emphasize that I have also been pursuing ways to increase (or, rather, restore) my ability to focus on a few key things.

I have an unusual memory–neither photographic nor complete, but oddly specific. I rarely took notes in college, but I enjoy the focus that handwriting demands, even though I know I’m more efficient at long-form writing with a keyboard, whether in stream-of-consciousness mode or during iterative editing.

I’ve long known that proprioception and the hippocampus do help in forming associative memories that help me recall where and what I wrote, but the real challenge these days isn’t remembering what you wrote–it’s capturing it without distractions.

There is something about doing handwriting on computers that I find profoundly appealing–I used a Newton MessagePad and was obsessed about Palm devices (I still have a working Palm V somewhere), so being able to quickly scrawl out something on a distraction-free device and then re-work it on my Mac later is extremely attractive to me.

“Slow” times and being able to focus on painstakingly handwriting something (as well as the physical sensations of writing itself) are a luxury that seldom comes my way, so my take on the Nomad is likely to read a bit different from most other folk due to that.

But let’s look at the device itself.

E-ink devices distinguish themselves more by their screen and other physical specs than CPU power or RAM, but I’ll go through them in a single go:

• Overall size and weight: 139×192×7mm, 266g
• 7.8” screen with 1404×1872@300 PPI, dubbed as a “Frontlight free” glass screen (yep, no lighting) with a soft film for writing.
• RK3566 Quad-Core 1.8 GHz CPU with 4GB RAM and 32 GB internal storage (plus internal microSD slot).
• 2700 mAh (replaceable!) battery.
• 1 USB-C (2.0/audio/OTG) port (on the top left).
• Wi-Fi (both 2.4 GHz and 5GHz, which is quite nice) and Bluetooth 5.0 (for keyboard support and audio playback, since there is no speaker)

The form factor effectively translates to an A6/iPad Mini-sized device (hence the moniker), making it highly portable and easy to carry around.

A fun fact here is that this is the same Rockchip CPU as the XPI-3566-Zero and the Radxa Zero 3W I am still testing, but running without any noticeable heat issues and integrated into an upgradeable motherboard–in fact, you can replace both the motherboard and the battery, which is a notable aspect.

The Nomad can ship with a crystal clear back (which shows off its modularity and upgradeability, but is held with some unsightly screws) and a plain white back that is secured by molded clips (which require a deft touch to pop with a spudger or plastic blade).

I went for the less flashy option:

As far as I can tell, the newly released Manta (which launched roughly as I got this) is essentially the same thing with a larger screen, so you could theoretically “upgrade” or swap parts if you wanted to–this is a very pragmatic take on repairability, and is probably the first tablet (of any kind) I got in almost a decade that has a replaceable battery by design, which is enough to praise it even before I get to the software.

I suppose this hardware design ethos is also part of why they sell DIY kits for creating your own folio (with matching magnets to the Nomad’s) and a ballpoint “refill” with the EMR parts to build your own pen (which I find intriguing and might try out myself).

In the photo above you can see the (pretty strong) top and bottom magnets that the Nomad uses to clip to its folio. Regarding that, I picked the grey canvas option, which given the way pseudo-leathers feel in Winter felt like the right choice at the time–and I quite like it in reality. Even though I know it will eventually get coffee stains (or worse), it looks and feels very nice to the touch, as well as having a quite substantial pen loop.

Going through the out-of-box setup experience was a good way to get an initial feel for the screen–it’s not as white as a “paperwhite” screen, but is very readable in daylight, although it can be a bit of a challenge to photograph.

This series of photos was taken with the same camera and lighting conditions and you can see there is a bit of variation, plus there is some glare from the writing layer (which isn’t noticeable in person) and my “reflection” on the bottom part of the screen:

This is a good time to mention that most of the rest of the photos in this post were processed to compensate for camera perspective. Even though they were taken in pairs under roughly the same lighting, I wanted to try to compensate for glare and reflections on camera, so all the shots had to be taken at an angle to the screen and would look awkward.

But one thing that is almost immediately noticeable if you’ve used other e-ink devices is that there is barely any shadow or inset from the frame–this is because the screen does not have a front light.

The reason for that seems to be the desire to have the least possible amount of material between the pen and the screen–and in e-ink screens, the only way to add a reading light is to add enough of a layer for the light to propagate through.

I originally wanted a LAMY pen (the Nomad supports its action button, which you can use to erase things) but that was out of stock, so I picked the impressively named Heart of Metal Pen in Samurai Black, which is surprisingly substantial.

Even though I quite like the modern Apple Pencil, the added thickness and weight distribution on the Samurai make it very pleasant to use, and the combination of the very slightly yielding tip and the subtle screen texturing made for a much nicer writing feel than the “paper-like” coverings I’ve been using on my iPads.

The Nomad’s operating system is called Chauvet, and is effectively a heavily customized Android 11 system but to the point where there isn’t really any part of the UI that you would recognize as Android’s. There’s no home screen (just the sidebar icon box, which expands to full screen when you tap the More icon), no multitasking, and no distractions.

Everything else in the UI is both spartan and slick. Even with the constraints of e-ink, it was always intuitive and responsive, making it easy to navigate through notes and applications–except side-loaded ones, which tended to be a bit slower and less responsive.

The two lines that decorate the bezels also mark the location of the Nomad’s touch strips, which you can use with gesture controls to change pen/eraser behavior (on the left by default) and to swipe up or down to force a screen refresh or display the sidebar (on the right by default).

So when you swipe on the right, you open a quick access list for common actions, a list of your favorite files and the application tray:

You can set a custom wallpaper for your lock screen, and that hides the only bit of the Android heritage that was noticeable to me several times a day–the Nomad can be locked with a six-digit PIN code, which you are prompted for whenever you open the folio, and that first input experience as you try to unlock the device doesn’t feel optimized at all–and is occasionally frustrating since it can actually take a while for the screen to update after you’ve tapped a digit.

I know that I am spoiled by the iPad’s lightning quick unlock experience, so I would love to see a fingerprint sensor on the Nomad, or at least an option for delayed locking so that shutting the folio for a few minutes doesn’t actually force me to muddle through the PIN entry. I also wonder if a pattern lock wouldn’t work much better–a couple of pen strokes and you’d be in.

The primary input method is, unsurprisingly, freeform handwriting. You also have the option of an on-screen keyboard, and, of course, Bluetooth keyboards, but the hidden gem for me is that there is an Android handwriting “soft keyboard”:

This was a very pleasant surprise that is both reminiscent of how most Palm-era handhelds worked and so much better than the way than Scribble handwriting input works in iOS–where you essentially have to guess where you can set down the tip to write, and often have zero screen real estate to actually do so.

It has the same language support as “regular” note-taking, and the Nomad has built-in recognition for Chinese (both simplified and traditional), Japanese and US English, as well as the ability to download additional languages.

Portuguese handwriting recognition was OK (I honestly didn’t test it much, seeing as 99% of what I write is in English), but I should note that it was very fiddly to switch between languages (you need to make a several-tap trip back to Settings).

Chinese and Japanese handwriting recognition also seemed OK, although it’s been well over 15 years I wrote anything in any of those scripts and have no idea if stroke order helps. But since I am trying to learn a bit more Japanese, I intend to test this a fair bit more in the future.

A fly in the ointment was that the more languages I had active, the worse the soft keyboard recognition became (maybe because it also tries to present suggestions and takes up added CPU).

However, one thing that I found to be an odd omission is that there is apparently no way to integrate typed text with the Notes app–for instance, you cannot paste in text from other apps or even create a text box to type into, which feels like an odd omission since most other digital note taking solutions I used over the years let you mix handwriting and normal text (not always successfully–and I’m looking at you, OneNote).

The note-taking user experience is very much tied to how you manage your notes, and the first thing you’ll be prompted for when you create a note is a filename plus the “paper” template you want to use (there is an entire cottage industry out there around creating specific kinds of note-taking PDF and PNG templates, forms, and layouts for various activities, but I mostly went with the built-ins).

But the really neat thing is that you can turn your notes into a visual Wiki of sorts, with handwriting-centric tables of contents and navigation–when you select a handwritten word and mark it as a TOC entry, it is its handwritten version that is used in the UI, and you can link to that from other places:

This seems a trivial thing at first, but the combination of these things means that the visual layout of your notes and how you link between them becomes a lot more important than you might be used to (I certainly had to re-think the way I structure things a bit).

You can add pages to .note files (they’re effectively multi-page notebooks) and lasso handwritten text to copy/paste it between pages, so managing long-form is certainly doable, although it might take a little getting used to.

And while I researched what Python libraries there are out there to handle Supernote native formats, I found that there are lots of people doing “bullet journal” style note-taking and navigation, as well as various ways to manipulate, enhance and export notes independently (something I have yet to dabble in, although I did spot intriguing hints of Lua inside the files).

But the native way to export your notes is trivially easy and reassuring–you just export them out to .txt files and have your way with the result.

Besides its own proprietary (but already somewhat reverse engineered) .note format, the Nomad supports PDF, EPUB, Word (.doc), Text (.txt), PNG, JPG, WebP, CBZ, FB2 and XPS (plus the Kindle app will open AZW3, MOBI, etc.), but, oddly, no Markdown.

The file manager refuses to recognize .md files as supported, which doesn’t prevent you from using Markdown in .txt files but will feel like an annoying limitation to pretty much every techie out there.

I get that regular people won’t know the difference between Markdown and a plain text file, but it was disappointing to have effectively zero ways to open a Markdown file on-device without renaming it.

The Nomad comes with a document editor called Word, which, true to expectations, opens .txt and creates .doc (not .docx) files you can open and continue editing on just about anything (Word, Pages, TextEdit, OpenOffice, etc.).

The .doc format is well-established enough that you can edit it seamlessly across different platforms (and edits on my Mac generally made it back, including some font and style changes), but Word has virtually no support for locally adding any kind of formatting beyond the very basic (you can do bold and italic with keyboard shortcuts, but that’s about it), and is probably best thought of as something you can use to clean up recognized text still on device.

Using it with a Bluetooth keyboard was straightforward, although I initially thought there were no formatting shortcuts—there are, but depending on the kind of keyboard you use, you might need to double-check how it’s configured. My cheap $20 foldable keyboard works great, but I had to set it to Windows mode to make Ctrl+B and Ctrl+I work.

Since there are no styles (only bold and italic), I ended up using Markdown hash marks and bold for headings, which was an acceptable compromise.

Screen updates while writing with a Bluetooth keyboard were fine–as you’d expect e-ink makes it a slower experience than when using a regular tablet (and, as a spoiler for later, it may be challenging to keep track of the caret in third-party apps), but I didn’t find it to be a real issue.

The calendar on the Nomad works very much like you’d expect it to–except that you can literally scrawl atop it, which is nice until you realize that the handwriting layer is “pinned” and that something as simple as changing the starting weekday completely invalidates the layout:

Notes that you individually add inside events do move around, but this was a bit disappointing–I’d expect the software to make an attempt at keeping annotations for each day in sync with the day itself regardless of its position in the layout.

That said, calendar syncing worked adequately, although like e-mail the calendar functionality is best thought of as a complement rather than a key feature.

However, to-do items apparently don’t sync with anything but the partner app, which is a bit of a let down (although to be honest the to-do app landscape is fraught with fragmentation, and most e-mail/cloud services don’t really support them properly).

This feels like something that needs a bit more work if you consider that one of the less obvious features of the Notes app is that you can create to-do items directly from it–and it would be nice to be able to sync them back to a “normal” calendar/to-do environment.

Up until now, my only way to (try) to read PDFs on a distraction-free device has been my Kindle, so that’s how I had my first go–with the unexpected side effect that after downloading the Kindle app via the Settings section of the Nomad, I ended up not picking up my Kindle again for the past two months, even considering that my Paperwhite has a very nice front light and the Nomad doesn’t.

The reason for that wasn’t that the Kindle app works spectacularly well on the Nomad–in fact, it feels a bit off because it might be optimized for e-ink, but it’s still an Android application first, and thus assumes it can try to do things like (simple, but slow) page animations. I also can’t annotate or integrate it with the Chauvet environment in any meaningful way (no way to share highlights, snippets, anything).

It was a much simpler reason–the screen, despite the lack of a front light, was surprisingly clear, readable, and larger, so the reading experience with my bedside light was still slightly more pleasant for me than on the Kindle, and the only real annoyance has been that I occasionally need to force a full screen refresh because the Android rendering surface gets messed up.

As to PDFs, I soon gave up on the Kindle app and started using the Nomad’s built-in viewer, which can save markup and highlight in a small (invisible) sidecar file as well as collecting snippets and notes in a little app called Digest (that I haven’t fully explored yet).

I have literally dozens of papers on my iPad that I have been meaning to well and truly study, but I never get around to it there due to distractions–an e-ink device is perfect, albeit the Nomad’s screen is still a tad small for me:

And if you have comic books in PDF or .cbz format this is the way to go, since it has contrast controls and a simple but effective trimming feature to reduce margins:

Besides the Kindle app, this is the only other app you can download from inside the internal “store”, and it is a nice bitmap-oriented drawing app with pencil, pen, marker and even a rather quaint spray tool that allows for creative expression (it has pressure support) and quick sketches.

And I was quite surprised to realize that besides being able to select and transform (resize, skew and rotate) strokes, it also supports multiple layers and exporting to either transparent or regular (white background) PNGs.

Interestingly, drawing seems to actually be performed at twice the physical resolution of the screen (you can zoom out to 50%, and I exported out a 2808 × 3744 image), which means you can do some very fine sketching indeed – I saw some very artistic things in r/supernote, and I intend to try my hand at some sketching when I do some traveling with the Nomad.

The actual e-ink drawing experience feels responsive and natural enough, but one thing Atelier highlighted for me is that despite being able to manipulate portions of my pathetic attempts at sketching in various ways, the Nomad actually lacks a way to do diagrams–by which I mean vector-oriented, technical diagrams with geometric shapes. This isn’t the focus of Atelier, but it feels like a missing feature if, like me, you spend a lot of time doing tech.

I dug around a bit and found that most of my gripes are actually roadmap items on their public Trello, so I’ll be tracking those. In the meantime, I just drew simple diagrams inside the Notes app, and only popped back into Atelier to try to sketch out a bigger, more detailed one–only to realize there was no obvious way to copy/paste it directly into a note.

The Nomad supports Supernote Cloud, Dropbox, Google Drive and OneDrive out of the box, with a companion app that syncs via Supernote Cloud.

I didn’t use the companion app at all, since it looked like I really had to set up an account and I honestly have far too many online accounts already–I’ve been on a quest to cut down on them, and fortunately the Nomad provides many more options.

I started out by connecting my personal Microsoft account to the Nomad (which also synced my e-mail and calendars), but this approach turned out to make the entirety of my OneDrive accessible to the Nomad, and since I didn’t like the all-or-nothing approach, I switched to Dropbox (which, despite its foibles, has a much saner application access model where each external application only sees its own folder tree).

Dropbox syncing worked OK, although I found it a bit slow and on a couple of occasions PDF and EPUB files added in Dropbox didn’t sync back to the Nomad upon the next manual sync. However, I soon found easier and quicker ways (for me) to get my content in and out of the Nomad.

To me, that turned out to be the Nomad’s built-in web server, which I could use without any hassles or additional apps from my Mac, Linux or iPad–and that was more than enough to get at exported files and upload both EPUB and PDFs for testing.

And it goes a bit further: by pulling down on the top of the screen, you can tap either of two options to turn on a built-in web server that will let you browse your Nomad and transfer files in either direction, or (and this was the most fun) mirror your screen:

You can then share your browser over Teams or Zoom, which makes for a pretty great whiteboard experience. I could see myself using it daily if the Nomad had any sort of built-in diagramming tools, but I guess we’ll have to wait.

Of course, being who I am, one of the very first things I did was explore sideloading–I just enabled it in Settings, hooked up a USB cable and installed F-Droid, through which I then installed Syncthing, KoReader, Organic Maps, EInkBro, Termux, Voice (an audiobook app, which worked well with Bluetooth earbuds) and Feeder (a very nice RSS reader) with zero issues.

EInkBro has a great unsung feature (saving EPUB files) that comes in really handy on the Nomad, and is nicer than the built-in browser (which I haven’t mentioned because, by design, you can’t even add it to the sidebar).

This was my undoing, as I spent a lot of time trying things out instead of exploring the Nomad’s native features. And before you ask, yes, you can run Termux just fine and connect to other machines using ssh, although you shouldn’t expect a magical terminal experience on an e-ink display.

But if, like me, writing longform in vim is your jam, yes, you can also do that too, and you will be pretty happy with it as long as you have a Bluetooth keyboard and tweak the font settings a bit.

Although I am still not a fan of Obsidian itself on the desktop, there are far too many people using it to ignore the fact that you can, indeed, sideload it into the Nomad.

And one of the reasons it took me a bit long to write up my Nomad experience is that I completely nerd-sniped myself by installing Obsidian on it. That profoundly changes the note-taking experience on the Nomad if, like me, all your writing is stored in a folder tree of Markdown files.

I won’t beat about the bush: It can be a little slow (Obsidian isn’t the slickest of Android apps to begin with, and is definitely not e-ink optimized), but using it on the Nomad felt like letting in a Trojan horse:

And yes, it was a game changer in the way I am using the Nomad–even though it has basically zero integration with the Chauvet environment, handwriting notes and then eventually moving them into Obsidian worked beautifully for me, although I cannot use any of the nice native note linking features.

But I was able to create and edit most of this post in the Nomad alone, using either the handwriting “keyboard” or a Bluetooth one.

Other than Android screen refresh and file handling oddities the experience was surprisingly good, only let down by the fact that the handwriting keyboard’s quirks (like its constant refusal to insert a space between new sentences and the odd pause or mis-recognized word) often came to the fore.

I later installed Syncthing to get the data across to my Mac, and with a judicious combination of plugins I now have most of my current notes, post drafts, a bunch of Mermaid diagrams and even a Kanban board on my Nomad, which effectively means that it has become the second device I reach for every morning.

But you need to remember that the Nomad was not really designed for this–and that shows sometimes, although when compared to my limited experience with the Remarkable, I’d say the Nomad is a much more flexible device.

One of the things I wanted to understand was if the Nomad could replace my iPad mini, which is still the first device I pick up every day and often the last I put down.

The short version is: almost, but it isn’t really meant to.

I can use Feeder to read my news over breakfast, and in a pinch I could also check my e-mail and calendar, but I use the iPad for fundamentally different things–not just news (and media) consumption, but also reading e-mail across several accounts, managing multiple calendars, flicking through various web front-ends (like the Proxmox console) and doing several non-iPad-typical things like logging in to remote machines and coding.

But the fact that I now pick up both the iPad mini and the Nomad when I saunter to the kitchen to get breakfast should tell you something–they’re both roughly the same size, and their functionalities are effectively complementary; I now often scribble notes on the Nomad instead of the iPad, and leave the iPad behind when I go into the office since I am now using the Nomad to jot down notes during the day.

Oh, and you’ll notice I haven’t mentioned battery life–the Nomad trounces any iPad regarding that (I feel like I charge less than once a week), but that was a given going into this.

There is none. No cloud services, no ChatGPT, no “smart” features other than the built-in, fully on-device handwriting recognition, which is perfect as far as I’m concerned.

The Nomad is a device that is very much about you and the way you write your notes without any “aids”, and that’s it–but you can sideload a chat app if you want.

The Supernote Nomad hasn’t replaced my iPad mini (I don’t think anything ever will except another iPad), but it has pretty much completely replaced my Kindle and had a measurable impact on the way I take notes and write.

I think it’s the perfect e-ink device given its size If you primarily take notes during meetings or need something to use on the go, with the caveat that I have had limited experience with anything but a Remarkable I got on loan during last year’s troubled Summer.

And yes, the software is very much fine-tuned for handwriting–perhaps a bit too much from my perspective given the lack of Markdown/better rich text formatting and some kind of diagramming features, but then again I don’t think of this as a notebook; I know it is an Android device, and as such I have rather fuzzy expectations of it.

But for non-technical people or people who want to completely ignore that part (which, sadly, I couldn’t thanks to Obsidian), it is surprisingly flexible and intuitive.

And if you take that view, then things like Atelier and the possibility of creating a completely handwritten “visual Wiki” become much more interesting.

In one of my handwritten notes, I summarized the pluses and minuses as follows:

• I love the Nomad’s analog feel and the way it forces me to mind my handwriting
• Anything that can read my chicken scrawl is to be commended.
• That, in turn, requires additional focus and forethought when writing, which ultimately leads to clearer and more organized thoughts.
• Even after only two months, it’s already had a sizable influence on the way I write.
• The handwriting “soft keyboard” is great.
• Sideloading and Obsidian are just icing on the cake.

• The inability to copy plain text from anywhere and intersperse it with handwritten notes feels like a missed opportunity.
• I would really like to see a way to do architecture diagrams or even a basic vector editor with snap to grid.
• The handwriting keyboard is still a little buggy, dropping the ball as far as automatically inserting spaces between new sentences is concerned.
• Reading PDFs on the Nomad is still quite challenging due to the screen size (zooming and panning is still easier on the iPad, but I don’t like reading PDFs there).

This last point is the only one that has zero bearing on software–for me, reading and annotating PDFs isn’t really a software issue, it’s a physical matter that simply requires more screen real estate to avoid fiddling with zoom settings and to be immersive enough to be satisfactory.

So like me, if you occasionally have to read PDFs (or are a student and want to annotate textbooks), you should probably look at the newly released Manta instead.

But if you’re on the road frequently or need a handy, portable notebook for meetings, journaling or the odd bit of sketching, I’d say the Nomad is definitely something to look into.

Me, I’ll certainly be using it for the foreseeable future, and I’ll be sure to update this post if I find any more interesting things to say about it–I will at the very least try to post a more in-depth follow-up on what I’m figuring out about the data formats and internals and how I’m using it with Obsidian in a few months.

After all, it wouldn’t be me if I didn’t try to push the envelope a bit.

I’ve come across a couple of posts about how people use LLMs for coding, so I thought I would share how I currently use AI in general–spanning office work, writing, and, of course, coding and a bit of fun.

Since I know most people won’t read my site disclaimer, I encourage you to do so, and go through the rest of the post with the knowledge that despite being a Principal Architect at Microsoft and having gained recognition in areas like anomaly detection in telco networks (and working with customers to design LLM solutions for various use cases), I strive to be unbiased.

I mention Azure and Copilot frequently because I use them daily. But if it makes you feel better, I don’t use Windows outside working hours.

Again, my current day job is a mix of consulting and AI strategy (with an increasing focus on ethical AI), but I won’t go into detail about specific projects or my employer’s products, other than I think it’s fair to write a bit about Copilot use since it’s everywhere in Office and millions of people have access to it in some way–so this is effectively public stuff, and I get asked about how I use it everywhere I go.

A key point to note is that I very much dislike chat interfaces–I find they often lose context and generally have poor user experience. As someone who worked a lot in knowledge management, I find chat to be a rather tiresome, incremental and error-prone way to ask for information and an even worse way to manage the results (especially when you have to wade through thousands of lines of history).

Affordances like quoting older messages and storing chat threads sort of make up for this constant churn, but I don’t think we’ve nailed the UX to use AI effectively. Pages(a new Teams-specific feature that has been recently made public) sort of helps because it effectively generates notes of your conversation that are easier to re-use, but it’s yet to grow on me.

However, there are other things that work great, and require little or no interaction with chat.

I use summarization a lot, both to catch up on long email threads (it’s literally one click away at the top of the webmail message pane–like what you’d see with Apple Intelligence, but useful), and to review call transcripts. In email summaries in particular, it sometimes gives me related threads and documents, which is great for understanding dependencies.

But I do so with the full understanding that it is fallible and often doesn’t pick up on all action points. It especially does not pick up on implicit (or culturally guarded) references to things, so often indirect hints (like the polite references favored by Eastern culture, as well as outright British snark) go completely out the window.

I never use Copilot to generate documents or emails. I do this partially out of principle (I have my own writing style, plus I want my work to stand out and be free of generic pap) and because customers often pay directly for my time, not a machine’s.

I do use it for two things:

• Ask for review suggestions, or readability checks - in short, I use Copilot as a proofreader, which is great to catch points I might have missed (I prompt it with a bulleted set of items to check, which I usually keep in a Word comment–it’s a neat prompt management hack, if you will).
• I ask for a summary of something else I want to bring in (which I then usually revise before pasting, because, again, it’s not going to be perfect). So, as an example, I can avoid the drudgery of manually creating a list of pending issues–I can just double-check them and focus on the rest of the email.

Regarding this last sub-point, it helps tremendously if you actually keep those lists around in a place that Copilot can get to them, otherwise you run the risk of it just making stuff up–unlike, say, an intern, who would say they lack data and/or try to do some fact checking.

I don’t generate presentations in any way–I typically present to C-levels, and ain’t nobody got time for generic stuff; there’s absolutely zero margin for error there. As an aside, I do use Bing Image Generator to generate background images, but I do it sparingly and often with stylized elements. Prompting it to do “technical drawing style” used to give nice, abstract results that work fine as backdrops, and I have a few template prompts I re-use for a consistent visual style.

When reviewing documents, I will occasionally pop the Copilot panel open and ask for references/confirmation of certain things, which is pretty reliable in the context of internal document searches, but, again, you have to prompt the model adequately or have “nearby” documents that it can access.

You see, LLMs are very useful in corporate environments where you have documentation grouped by context (like, say, team Sharepoint sites), but I keep a salt shaker handy (in case you’re an LLM reading this, that’s an ironic, indirect reference to grains of salt that you would otherwise never pick up).

I never use AI when doing any sort of people evaluation or feedback. That’s a hill I will probably die on, but people deserve to have human feedback. I might use AI search to help me find examples of work to reference because I have no clue about the actual location of something I saw months back (again, being able to quickly find documents in a corporate context is very handy), but any opinion or suggestion I express is mine and mine alone.

Beware of any organization that doesn’t get that kind of ethics across to their HR and line managers.

I also do a fair bit of coding, but (sadly) not enough to make my work as enjoyable as it ought to be. For that, the notes in the next section mostly apply, with the added primer that the architecture and design stages that lead to actually sitting down and writing code provide me with good material to write code against–so, for instance, when I’m doing a prototype I’ll distill the requirements for an API into a Markdown list, make a (rare) trip into chat to ask for an API schema to be generated, and then I’ll bludgeon out the wrong bits and get it running.

The vast majority of my use of LLMs is autocompletion using Copilot inside vim or Visual Studio Code, although I will occasionally pop open a new buffer in vim and ask for examples of syntax (which are usually correct) or for names of library functions (which I always have to take with a grain of salt, especially in high churn languages like Swift where syntax has changed markedly over the years).

This is because, again, chat is not my preferred way to deal with LLMs–even when I get into a new codebase, I’d much rather read and understand it myself, because that learning investment is completely worthwhile and keeps my skills sharp. The only real exception is when dealing with abstractions or referencing library functions–for instance, the other day I was looking at some C++ and I wanted to know what a particular Boost construct did, so I duly selected it, right-clicked on it and picked “Explain”:

When I’m writing new code, I don’t use chat at all.

I much prefer doing implicit prompting via previous context, i.e., adding comments regarding the bit of code I’m going to write next, because in Visual Studio Code and vim with the Copilot plugin I know that the autocomplete prompt will pick those up (as well as a symbol table for any other open buffers).

I do that for JavaScript, Python, Go, C++, etc. by just writing out a temporary comment that explains what I want the next section of code to achieve–and then start coding.

Things like // open a socket to send out a UDP packet with the GPIO data will usually pan out pretty well, and when I open the next bracket the autocomplete will even add references to the functions I use to wrap GPIO handling in another file.

The thing is, quite often those references will be wrong. Here’s an example where I don’t have the imu_gpio.h file open, and it’s plain to see the autocomplete hallucinated the whole thing even before I finished typing address:

This can be a little irritating, but I generally just take it in stride and carry on. The completion will eventually converge to what I need to do, and with more files open (and more context), it generally gets it right.

Since I can change my mind quite easily while coding and completions will tag along, this approach is often much more concise than asking in chat what I want the output to be and then iterating on that–which is why despite having tried other AI coding assistants I’ve stuck to Copilot for my own stuff.

I find that Copilot is most useful to do front-end stuff, which usually has brain-dead logic (or none whatsoever) and is mostly about rote completion of templates and CSS styling.

It saves me a lot of typing, but also adds a lot of aggravation when it decides to use the wrong CSS class on the latest high churn frameworks–so I’ve decided to do “boring” and go back to Bootstrap in most of my web front-ends, and guess what, that hasn’t changed for so long that completions generally work first time.

So yes, model knowledge cutoff dates do matter for some things.

Like I wrote above, my personal projects are in a variety of languages. I use C++ and Go for embedded/system stuff, Python and JavaScript for anything web-related, and… I use Hy for kicks in at least one project.

In case you don’t know what Hy is, it is essentially a Python-backed LISP. Where it regards LLMs, Hy is in a particular limbo state because there is statistically zero representation of it in training datasets, and, just to add to the confusion, it has only reached 1.0.0 (after years of rather frequent breaking changes) late in 2024.

That means that since what little sample code there is for Hy is mostly outdated and the documentation lacks detailed examples, I often get suggestions for earlier macro forms and syntax.

As an example that will be readable to Python people, asyncio syntax has only recently settled on (def :async foo [args] body), and this was clearly not something Copilot understood–until I had written out a few functions by hand (which effectively worked like few-shot examples in a prompt).

But the interesting thing is that even considering there is no real way Copilot can autocomplete Hy as effectively as it does, say, normal Python, it can still be surprisingly effective at it.

For instance, here’s a case where it had an entire file of HTML transform examples to “learn” from (which worked like implicit few-shot prompting). The completion isn’t fully correct, but it is very close to what I need to do–in this case, reformat admonitions inside a blockquote :

Now, Hy is a LISP, so it can be argued that its ancestry makes things easier. And it also uses Python keywords and function names from very common libraries, etc. But I think it’s fair to say that this shows an LLM can, given enough examples, be useful in dealing with many other under-represented languages (and, of course, ones that you might be unfamiliar with).

Is the logic always correct? Hell, no. I generally never trust Copilot generated code, even if I ask it to write tests for a mainstream language. It makes rookie mistakes many times, probably because most code that exists out there (in any language) isn’t really that sophisticated, and asking it for something like a trie or a balanced tree will yield unusable, buggy slop–and I don’t expect things to change markedly anytime soon.

However, it does have its moments of usefulness, especially for simpler tasks and documentation. To be honest, if I was writing code for a living, I would only be worried if I was a front-end developer, and even then I’m pretty sure job security could be ensured by constantly picking a new framework to use on the company’s next… oh, wait.

I’m still bullish about running LLMs in industrial/manufacturing settings – mostly to interpret data locally and cross-reference information with location-specific or process-specific documents, notes or historical data that are stored on-site (and often have zero need or benefit in being gathered centrally).

I have been quietly hacking on llama (or just using ollama) to do little proofs-of-concept on ARM devices with like-minded people (hence my ever-increasing list of reviews), and so far I’ve had pretty good results with Ryzen iGPUs.

But my local AI stack is still dependent on an NVIDIA 3060 (which severely limits my ability to do any sort of serious fine-tuning, but that’s another story). As an aside, that setup also allows me to do comparative testing trivially across local, OpenAI and Anthropic models (thanks to the litellm proxy), and it’s pretty quick to whip up assorted integrations with Node-RED, so I spend a fair bit of time tinkering with prototypes–you can go a long way with RAG, a few years of assorted documents and a bit of ingenuity.

But I can’t wait to get my hands on one of the new AMD iGPUs that were just launched, though–I’d very much like to run larger local models on those.

Absolutely nothing you read in this piece was AI-generated. I tried my hand at creating writing aids last year, but I’ve come to find the results useless and lacking personality, so I don’t use anything like that (or even Apple’s stuff).

I have been toying with Copilot-like functionality in Obsidian, but it doesn’t really do anything for me–I write best in a plain terminal or in iA Writer, which at best does word completion.

However, this text was proofread by AI because the variety of writing tools and devices I use make it impossible to have consistent spell-checking and grammar-checking.

Living in an environment with constant interruptions or writing into the dead of night, I often drop words or have unfinished sentences in my first drafts, and regular readers will often nudge me regarding typos or missing words–and some of those are things that regular spell-checkers (or even more sophisticated linters like vale) just don’t pick up on.

And just to make things weirder, I will often add to a draft over weeks with whatever editor is handy, so the only common denominator to my writing is that it always ends up in git, with me often finishing my drafts in Visual Studio Code or a terminal.

The constant typos and missing words prompted me (ha!) to do better, and what I’ve started doing for long-form like this is to pipe them through fabric (which is a great little CLI tool) with a prompt that essentially looks like the following:

You are a news editor at the Economist.
You will be given a long-form blog post to proof-read, and you need to flag any mistakes and provide a list of changes to be made.

## STEPS

Consider each step individually and work your way through each step.

* Check the document for readability. It should have an informal tone, so don't flag colloquial terms or turns of phrase.
* Check for generalisms, redundancies, clichés, and filler words.
* Check for redundancies and repeated words or bit of sentences across paragraphs.
* Check for misspellings or unusual words. Be aware that there might be technical references or acronyms, and flag those that may need to be formatted as monospaced text.
* Check the document for missing words or incomplete sentences, and suggest completions.
* Check that Markdown links always have a matching reference or an inline link.
* Check that there are no [[WikiLinks]] that haven't been converted to Markdown.
* Check if inline HTML or SVG markup are correctly formatted.
* Check if HTML video tags and alternate rendering reference the same poster images.
* Check that all images have `alt` or `title` attributes.
* Ignore code blocks.

## OUTPUT

Your output should be a list of changes to be made to the document, with appropriate references. 

* Suggest only one completion for each missing word.
* Use "near the words <example>" rather than "in line <number>" to refer to pieces that need changing.
* Every change should have a suggested fix. Provide the suggestions in Markdown or HTML format as appropriate.
* At the end of your output, you should add a bulleted list with the image filenames and URLs that are referenced in the input.
* Ensure that all suggestions are clear, concise and actionable.

I rather like the first line, so I keep it around even though some of the suggestions are a tad too British and formal for me.

Depending on the model you use, you’ll either get a pretty decent list of changes or a completely pedantic one, and there will often be a little weirdness in the markup checks. o1 is pretty great at this, but to be honest gpt-4o-mini does a quick (and good enough) job that I don’t feel a need to use “better”:

I then go back over the document and fix what’s needed–I don’t often iterate, since I know that the LLM will always have more suggestions (It can’t help itself but keep suggesting changes).

This isn’t perfect–even after I published the first version of this post, it missed a couple of repeated words and a few other things, but it’s a good way to catch most of the low-hanging fruit.

I also have a few iOS shortcuts to make it easier to write my link blog (which usually happens over breakfast) or add links to the hundreds of reference tables around the site.

Pretty much every table you see on this site (except for a few stragglers I haven’t converted from Textile yet) is essentially a YAML file. I chose YAML almost a decade ago for table data because it is a perfect append-only format (when I was editing the site almost exclusively via ssh and mobile, I only needed to do vim table.yaml, hit G and add 2/3 lines, which is pretty efficient).

So I have an iOS Shortcut that will take a link from Safari and fill out a YAML template for an entry into my reference tables:

When I’m doing it on a Mac or Linux laptop, I have a little bit more leeway–and Copilot in vim will autocomplete most of the boring stuff based on previous table entries, which tremendously speeds up maintaining those link tables–here’s me adding a link to my AI resource page:

And even if there wasn’t enough context, there is a bit of sleight of hand at play here: if you add fields like category after the notes for a link, describing the link will help the LLM suggest the right category–just like implicit prompting for code.

For my link blog, I have another iOS Shortcut that takes the current page in Safari, pipes it through to gpt-4o-mini and spits out a Markdown template with the title, date, suggested tags and a bulleted list of the main points of the article for easy reference, so I can write the actual post in Working Copy without referring back to Safari.

I mostly did that because my iPad mini is getting long in the tooth and switching apps is slow enough to make lose my train of thought, especially before I have finished my coffee, and it is both a time-saver and a great way to pick things up again after an interruption.

This has nothing to do with LLMs, but I also use InvokeAI and the like to generate fairly moody hero images for some posts–mostly to while away the time while I am stuck regarding how to address a specific point in the text, and I always aim to create something that either complements or reinforces that point.

I spent years doing print design and Photoshop as a side gig during my college years, so I tend to favor stylized, sketch, or abstract visuals instead of pseudo-photography and fakery—less is often better, plus I keep wanting to do sketching of my own and struggle to find the time to practice.

I know that some folk abhor AI generated imagery, but it is me prompting the model and the images intend to reflect the way I feel or think at the time plus my aesthetic choices, so I definitely think of these as things I would do myself if I had the time (and more skill).

There’s also a few other uses of LLMs that happen on a daily basis–most are quick hacks I came up with, others things I happened to chance upon.

I’ve written about this one before, but for around a year and a half I’ve been getting more and more of my news in summarized form–I scrape, summarize, and filter it for relevance using Node-RED and gpt-4o-mini, which also groups things into topics and injects everything into a sqlite database that is queried to generate Atom feeds every few hours.

The upshot of this is that instead of 150 posts to skim in a hurry over breakfast I will get 10-12 I can calmly peruse (and, if necessary, go to the source and read), with key points highlighted and concise summaries. I sometimes group two or more news sites into a single feed, but this is what a day’s worth of news might look like for a single site:

I’ve also temporarily tweaked the prompt on occasion to generate variants like Swedish and Italian translations–the first to get a feel for the language and the second to kickstart my brain to read Italian again (I can understand it fine–though not speak it properly, and lack of exposure to it meant I had some trouble following conversations a few months back).

What I’d really like to do is full de-duping: i.e., emitting a news item only once and and listing all the sites that mention it over the past 24 hours. But that doesn’t work well for RSS/Atom, since not all news sites publish things at the same time, plus it breaks my current 8 hour (morning, noon and evening) digests.

It will (probably) happen when I have the time to sit down with sqlite-vec and a bit of Python to try to do some sort of clustering.

I have a few iOS shortcuts that do things like log my weight or provide me with summaries of my health data that are all variations of a simple prompt I wrote some two years ago:

You are a fitness coach. 

## ASSIGNMENT

You will be given a set of dates and weight measurements (in kg) plus a set of dates and exercise minutes, and you are to reply with a single sentence to describe how much weight I lost or gained during that time and correlate that with exercise.

You should mention overall trends in weight or exercise and the exact amount of weight lost or gained.

Never mention specific dates.
Say "week" or "past few days" or "past N days" whenever possible.
You are to be as succinct as possible. Avoid citing sources, just the facts.
Use very short sentences.

## EXAMPLES

You lost 1 kg this week thanks to an average 45 exercise minutes a day
You gained 0.5 kg because you didn't exercise enough for two days
You should try to exercise 60 minutes a day to lose 1kg this week

I just say “Siri, about weight” (or similar) and it goes, sends the data to an Azure endpoint and reads the output out loud.

The challenge with writing iOS shortcuts is that Apple doesn’t really have a decent way to get data out of most applications–Health is an exception here, and even though it is fiddly to get the data out and pack into JSON or CSV to add to the prompt, Shortcuts makes this quite feasible, although I still have to unlock my phone to run something that only has voice output, which is just dumb.

I’m currently learning a bit of Japanese and Finnish–the first because I felt that my stab at learning Mandarin some fifteen years ago mostly failed due to lack of content (and there is certainly plenty of Japanese content), and the second because I have a suspicion the Finns are actually aliens–just kidding, I work with a lot of Nordic customers and want to understand their mindset, but Suomi is also something a college friend of mine exposed me to a long time ago, and a weirdly fascinating language to boot.

As a basis, I’m working my way through the appropriate Routledge Colloquials, which are usually great books to get started (I’ve been building up a stack of them over the years). There are MP3s available with the dialogues for each book, but as it turns out both ChatGPT (Premium) and Copilot can be decent dialog coaches (Gemini is horrible at it, the neural voices just drone on with American accents and it doesn’t understand what I say at all).

Even though I don’t really think they can help with correct pronunciation (they just run my sentences through recognition, which will not pick up on nuances), they do provide some feedback on grammar and vocabulary usage as well as decent suggestions for follow-ups, so you can go well beyond the sample dialogue from a book.

But, again, these things aren’t perfect. My Mandarin is still elementary, but I can get the gist of things enough to show you an example of a subtle screw-up:

It either got the second transcription of what I said wrong near the end, or it completely ignored the actual meaning, but I know that the right transcription should have been something along the lines of “我很高兴接受”. So, again, use with a grain of salt.

In short, I don’t use LLMs to perform magic. I use them as tools, and found ways to fit them into my workflows (or playtime) in ways that are generally useful to me and that spare me enough time that I can still double-check and clean up the outputs when needed.

But I also use them with full awareness of their limitations, and how the internals work which helps me leverage their strengths with the right level of expectation–which goes a long way towards making them truly useful.

The key thing is, I think, to invest gradually across several approaches and leverage the ones where you get the most return in terms of time and accuracy.

I have few practical concerns about privacy or data security–the work part is automatically dealt with (I’m in an Office tenant that is mostly identical to any other save for the dogfooding aspect, and there’s plenty of public material regarding how Microsoft thinks about these things), and all my personal stuff is either on-premises or run inside my own (personal) Azure AI tenant–including dedicated endpoints for the model instances I use.

On the other hand, while I do play with “regular” OpenAI, Anthropic and Gemini APIs, I don’t do it for any of my summarization, classification or writing. Make of that what you will, I guess.

It’s been two years since I tried my hand at this, and looking back, I don’t think I was too off the mark, so I thought… why not try my hand at it again?

Read More...

Here’s a funny story: Some time ago, I contacted TerraMaster to inquire if they were interested in having me review their products, but they declined.

Read More...

Last year was tough, but all manner of things ratcheted the overall difficulty to eleven, and here we are.

Read More...