About ten years ago, I looked at the Ghost blogging platform that originally powered this website and asked myself why. Why was I running a dynamic application on server hardware to serve a website that was completely non-interactive to everyone but me? Why was it necessary that every time someone visited a page on the site, server-side code would execute to pull content from a database and slot it into an HTML template, dynamically assembling a page that was identical to the one seen by the last visitor and would be identical to the one seen by the next visitor?¹

The only answer was that I liked having the user-friendly admin panel and post editor that was accessible from my browser. Ghost even had this neat feature where you could append /edit on the end of a URL and, if you were logged in, this would immediately take you to the editor for that post.

Then a new version of Ghost came out and made a UI change to the editor that I found really annoying and that was enough to get me to move to a Hugo-generated static site.

My new site architecture gave me more theming and structural flexibility, cheaper hosting and less maintenance, all for the price of losing my online editing interface. Being a technical guy, I was pretty happy to just write my posts locally in Vim with hugo server for preview, and make the occasional edit through GitHub’s web interface when that wasn’t available.

From then on, I became an advocate for using static site generators to host blogs, marketing sites, documentation and other sites that don’t maintain significant user state. Where specific points of interactivity are needed – say, a contact form – that can be handled with a single-purpose hosted endpoint; it doesn’t require bolting on a whole application server and database. You can, of course, go too far with this – I’ve spoken before about the pitfalls of platforms like Firebase that encourage building highly interactive apps without server-side code by letting clients directly access the database.

But if your website mostly serves the same pages to everyone, you’ll probably be fine with pre-generated HTML. The trouble comes in when people need to edit it.

Programmers love writing Markdown in text files. We all think it’s simple and intuitive, but that’s because we’re always thinking about the parser.² We’re also very happy to track our changes with Git. Most ordinary users are not going to use their favourite text editor to write content in Markdown and make commits to the site repository.

So you’re gonna need a WYSIWYG editor and probably an admin panel, i.e. a CMS. The default choice is WordPress: a dynamic web application that uses server-side PHP and a database to store and manage content, settings and all the machinery around them. Ghost follows the same model.

There are other approaches. A headless CMS can give you a WordPress-style editing experience while keeping the public website static. In my experience, most headless CMSes tend to lack important features, not provide a polished editing experience, require extensive edits to your templates, or impose lock-in by making the CMS database rather than the site repository the single source of truth for content.³

Enter the coding agent.

Some of the earliest impressive results from coding agents were static HTML pages, and they are just as capable of building with static site generators, which give you all the benefits of working with static HTML pages along with the structure and consistency enabled by separating content (Markdown files) from presentation (HTML templates). There have always been advocates for maintaining your site by just uploading a bespoke, standalone HTML page whenever you write something new. Coding agents make this even easier, but I’m a stickler for consistency and pages that link to each other.

Using a coding agent not only allows you to harness the many speed, flexibility and security benefits of static site generators, but also means that you can author your site content however you want and let the agent figure out how to import it. While I’m perfectly happy to author everything by editing Markdown files in Vim, others may prefer using Google Docs or MS Word, or maybe they like to write everything out by hand in a notebook and take pictures of it with their phone. Any of those inputs can now be fairly seamlessly integrated into a static site by a coding agent, without the user having to put stars for bold.

And if the workflow of writing content in a Google Doc and then prompting an agent to import it is a little too ad-hoc, you can instead use the same agent to vibe-code a tool for the purpose – a headless CMS, even.³ The structure of, for example, a Hugo codebase, enables agents to safely and efficiently edit and build sensible tools for it.

To my mind, this means that a lot of websites can stand to be radically simplified. Get rid of your dynamic app logic and your database, replace the whole thing with static HTML files, get a result that’s cheaper, faster and more secure, without sacrificing ease of use. Coding agents free us from the need to anticipate every action a user might want to take when editing a website and pre-build a GUI for it.

This applies to more than just websites.

dwm, a tiling window manager and part of the Suckless project, is explicitly designed around the idea that the most elegant way to configure software is to change its source code.

↗

dwm is customized through editing its source code, which makes it extremely fast and secure - it does not process any input data which isn’t known at compile time, except window titles and status text read from the root window’s name. You don’t have to learn Lua/sh/ruby or some weird configuration file format (like X resource files), beside C, to customize it for your needs: you only have to learn C (at least in order to edit the header file).

Differences, dwm.suckless.org

Before coding agents, this sort of thing was pure programmer asceticism. Historically, I’ve always preferred window managers that bloat their codebases with the ability to read config files. But editing the source is way lower cost now – I am currently running a slightly modified version of Niri because I needed a small feature it didn’t contain. Before coding agents, I wouldn’t have bothered.

Most software probably still needs configuration files, but because an agent can make both configuration and code changes, the case for permanently bolting custom editing interfaces onto software has weakened. Architectures that separate the editor from the thing being edited – say, a static site with a headless CMS – become more attractive. Where editing interfaces aren’t replaced by agents entirely, they can instead be bespoke, external and, in many cases, ephemeral tools.

We hear a lot about vibe-coding slop cannons and the pitfalls of software that grows at the speed of prompting, but we can also use coding agents to shrink software. Replacing a WordPress site with a Hugo site is one way – there are many others.

Coding agents allow us to create a lot of software quickly. What’s even more revolutionary, though, is that they allow us to throw a bunch of it away.

Reply via email

In Microsoft Word, navigate to File > Options > Save. Choose an appropriate filename and make sure you always save to the shared drive.

In the worst cases, it’s used in place of a blockquote, often (hideously) for multiple lines of text.

Hi, I'm having some technical difficulities. Before, you told me that to send you my report in Microsoft Word, I had to go to File > Options > Save, and make sure I always save to the shared drive. I couldn't find the shared drive, please assist.

When reviewing others’ work, I’d often see bizarre new applications of this formatting. What’s worse is that the writer would usually have a fairly logical rationale for using it, and their rationale would even be concordant with the style guide I wrote, prompting me to update it. “Use inline code for verbatim text” definitely did not cut it. But as many caveats as I specified and as many examples as I gave, both positive and negative, I would still see obviously incorrect uses of the formatting.

What I ultimately wanted that section of style guide to do was transfer my intuition about the appropriate uses for inline code formatting – developed through many years of reading blogs – to other minds. I don’t think I ever quite succeeded.

Luckily, LLMs then came along and read all of the blogs on the Internet, allowing them to develop this intuition pretty much perfectly. In service of producing output that appears correct and polished, the chatbots can be overzealous with textual flourishes – I think the overreliance on dashes is precisely because a dash is technically correct in so many more places than other punctuation marks – but I’ve never seen one misuse inline code like a human would. While much about the continuing proliferation of AI writing in inappropriate spaces is unpleasant, I’m glad I don’t have to fix inline code formatting anymore.

Reply via email

Disclosure: I received a free review copy of this game from the developer.

Regular readers of this blog will know that I am a big fan of point-and-click adventure games, to the point where the genre comprises the majority of my game review output on this website – the overwhelming majority, if we’re willing to define the genre broadly. I’ve played a lot of adventure games, from LucasArts classics to the freeware AGS titles to modern commercial productions, and it’s a form that’s dear to my heart. Over the decades since its commercial heyday, many critics have needled it for what they consider fundamental flaws – linearity, ludonarrative dissonance, fundamentally static game worlds, etcetera.

I don’t share all those opinions or consider all those things flaws per se, but that does not mean I have endless patience for the genre’s foibles. Many qualities common to adventure games are necessary elements of the form, but others can rightly be considered failings and relics. The subject of this review, Swedish game studio Sparrowland’s debut The Tragedy at Deer Creek, is, unfortunately, a showcase of several adventure genre failings.

But first, the positives:

• The game’s pixel-jagged 3D graphical style is beautiful. Locations are lovingly rendered, and the game contains numerous well-animated cutscenes.
• The music and sound design are highly atmospheric and perfectly fit the visuals.
• The game is fully voiced, and the main character’s actress delivers every line perfectly.
• I enjoyed some of the more elaborate tactile puzzles – the tonewheel stands out as a personal highlight.

All that said, I found the game to be a highly flawed experience overall, due to both a mismatch between gameplay and story and various shortcomings of the story itself.

# Ludonarrative dissonance

This is a fancy term for the tension between story and gameplay, which there always is in a game with sufficient amounts of both. In the adventure game genre, this often manifests as games that feel like movies, which pause arbitrarily, forcing you to hunt through scenery for objects to rub together so you can solve a moon-logic puzzle before you can see what happens next.

Critics of the genre will insist that this sort of thing is inescapable, but I beg to differ. A good adventure game fits its puzzles to the protagonist’s actual role – for example, a good detective game should involve interviewing subjects and constructing hypotheses, rather than doing fetch quests to bribe guards to open doors. Puzzles can and should be constructed in such a way that they organically progress the story and/or reveal interesting details about the world.

The Tragedy at Deer Creek is a story about discovering the tragic history of an Alaskan logging camp abandoned in the late 19th century and preserved by its remoteness and the cold weather. The game asks you to comb through the abandoned locations, looking at old photographs and reading journals. This has always been a very popular way of telling stories in games because it allows for the construction of a traditional, linear narrative with characters and plot twists that do not have to account for the inherent unpredictability of the player’s actions, or provide players with even the illusion of influence over the story’s outcome. Rather, interactivity can take the form of discovering the story, piece by piece, by exploring the environment, manipulating it, and/or shooting enemies. All of these things lend themselves much more easily to melding a satisfying story with satisfying gameplay than having the player actually participate in the drama.

There are many ways to make this kind of gameplay satisfying and rewarding – the purest example I can think of is Her Story, which engages the player with the discovery of a linear story through the simple mechanic of searching a database for dialogue in video fragments. Similarly, the walking simulator¹ What Remains of Edith Finch has the player explore a large, now-abandoned house, learning about its inhabitants through exploration of their preserved bedrooms.

Going into Deer Creek, I expected something similar to Edith Finch, but while the story is focused on the characters and happenings at Deer Creek all those years ago, the gameplay seems more interested in being Myst. All of the most elaborate puzzles involve assembling and manipulating strange mechanical contraptions – one of the achievements, “Adventure Game Logic 101”, lampshades the inclusion of that adventure game staple, the makeshift grappling hook.

While some of these puzzles are quite fun, they seemed to me more at home in the ruins of an alien civilisation or a lost temple than a 19th-century logging camp. The logic of the story and the characters jars against them – one struggles to imagine a down-on-his-luck lumberjack building a three-piece mechanical hatch to conceal a cellar, or a morphine-addicted foreman hiding clues in the eye of a painting.

Because of this disconnect, the story feels like an afterthought, its parts scattered through the puzzles with little concern for pacing or any interesting order to the revelation of details. I found myself frustrated when a given puzzle would uncover a journal or diary with a few terse, mostly prosaic entries by one of the characters about the others. Despite being clearly the whole point of the game, the information in these documents was rarely useful for solving further puzzles, and so each time a new part of the story was uncovered, it was accompanied by the feeling of being at a dead-end rather than one of progress in unravelling the mystery. Though the game includes a quest log in the form of Charlotte’s journal, there were still times I found myself ambling around, doing things without really knowing why I was doing them.

Deer Creek lacks confidence in its interactivity as a story delivery mechanism. The most important parts of the logging camp’s history are presented in a series of cutscenes from the perspective of a historical character, bookending the game’s chapters. The first of these scenes is shown long before the player character would have any way of learning its contents.

The final part of the story, and the revelation of the titular tragedy, is shown as a series of wordless slides on a magic lantern, a final reward for solving the final puzzle. There is no in-universe explanation for how these slides came to exist, though by this point the story’s supernatural elements had become largely unambiguous. This slideshow is punctuated by the protagonist’s gasps of shock and horror, which felt to me like a cheap attempt to elicit emotion from the player. But because I’d spent 80% of my game time up to this point solving mechanical puzzles, I had no investment in the story or characters, having been given little impetus to explore their relationships and few hints for forming my own hypotheses or even suspicions about what the tragedy actually was.

The experience left me cold.

# The story itself

Plenty of adventure games with severe ludonarrative dissonance manage nonetheless to tell amazing, memorable stories – Grim Fandango is a classic of the genre for this reason, despite its awful control scheme and numerous puzzles best experienced with a walkthrough open beside you. Had The Tragedy at Deer Creek combined the best of its puzzles with a well-paced and memorable story, the dissonance between them would perhaps be a lesser sin.

The game opens with a cutscene showing the protagonist, a photographer named Charlotte Gray, packing her bags for a journey of some kind while talking on the phone to her husband. We then skip ahead two days, and she is shown jumping out of a train into a snowy landscape and approaching an old man.

From this, I initially assumed that the game’s titular tragedy was something that had happened to her in thosewo days, causing her to jump off a train. But no, that was just part of her journey to Deer Creek. The old man leads her to a cabin and then disappears from the game. After lighting a fire, she goes out to explore the logging camp at Deer Creek.

Charlotte mentions a project a couple of times, and her initial in-game objective is to photograph every location at the Deer Creek logging camp. According to the game’s Steam page:

Photographer Charlotte Gray ventures to the long-abandoned logging camp at Deer Creek to complete her project ”Forgotten Frontiers” - a visual record of places time has slowly erased, and the quiet stories left in its wake.

This information is not provided in any obvious place in-game. Charlotte has no personal connection to the logging camp, and the game does not really characterise her strongly enough to give me a sense of what would compel her to undertake such an uncomfortable and potentially dangerous journey. There’s no mention of the broader purpose of her project, and it’s only after a mid-game revelation that she seems particularly personally interested in discovering what happened at the camp.

The story of what happened at the camp is similarly lightly sketched. We have a large cast of characters who write about each other in their journals and logbooks, and we spend the game going through their mostly preserved living spaces from 100 years ago. Individual logbook entries are terse and provide scattered details – these two characters are suspected of having an affair, these other two had a fist-fight, this one loves quoting Bible verses – but these details do not cohere into a greater narrative.

In the game’s present, spooky events slowly build to imply something supernatural going on, but if anything, these occurrences mostly provide cop-outs and easy explanations for Charlotte’s narrative – perhaps we are intended to believe that the late-game proliferation of Myst contraptions was built by ghosts.

The heart of the story is a young girl named Rosalyn, and it suffers from not truly centring her in the way that, say, the interactive fiction classic Photopia centres Alley Dawson. Charlotte has a daughter of similar age, but she’s only mentioned in the game’s opening. This seems like the obvious emotional bridge between protagonist and mystery, yet the game makes no attempt to parallel or contrast the two girls, or otherwise use this detail to deepen Charlotte’s connection to Rosalyn.

So when the mystery’s resolution arrived, I could see something of what the writers were trying to achieve, but the whole story had been so lightly sketched up to that point that it barely got a “huh” out of me. The titular tragedy of Deer Creek may be an event of great loss, matching the use of the word in colloquial speech, but it does not have the qualities of a literary tragedy, or at least these qualities do not emerge from the telling. No sickening inevitability is apparent in the conclusion – it just feels like a random act. I did not feel as though I had sufficient knowledge of the characters to divine any of their motivations.

When writing any kind of story, there’s a delicate balance between giving the audience enough material to get invested in and draw their own conclusions and interpretations from, and spelling everything out. This can be maddeningly difficult for an author, and however they choose to find that balance, there will be some audiences for whom it is either too subtle or too explicit. From my perspective, Deer Creek errs on the side of over-subtlety – I get the sense that there is a well-developed story in the writers’ minds, but the bits of it presented for me to grab onto are insufficient for real engagement.

# Unexamined examinations and pixel hunts

As I digressed about in my 2019 review of Unavowed, point-and-click adventure games have a fairly standardised set of interfaces, representing various points along the evolutionary road from the original text adventure parsers that accepted typed commands such as EXAMINE TREE and GO NORTH. In these text adventures, you’d be presented with a textual description of a room containing various items, and a large part of the gameplay would consist of examining those items, i.e., summoning up a textual description of each one (X LANTERN, X DOOR). This continued to be useful as text adventures gained low-resolution graphics, and the convention of giving each interactable item a textual description has persisted as a genre convention right up to, well, the June 2026 release of The Tragedy at Deer Creek.

The graphical capabilities of modern computers long ago reached the point where these textual descriptions are no longer necessary to fully appreciate the appearance of a given object. This is certainly true in Deer Creek, which allows you to take a closer look at just about everything but still insists on including fully voiced descriptions of each item. The in-game ability to click on a detailed picture of a hammer and hear the protagonist say “It’s a hammer” is kind of farcical at this point, a thoughtlessly repeated genre convention that has long been vestigial.² Were Charlotte a more strongly characterised individual, or had she a personal connection to the game’s setting, these descriptions could present opportunities to explore that, but beyond a few remarks like “my grandma had one of those”, these opportunities are not taken. The game would have been better served by a single-click-to-interact-or-examine interface than the verb coin it uses.

Deer Creek also has a couple of pixel hunts, representing the only two places I got stuck in the game. One is a true pixel hunt, requiring you to spot and click on the game’s single tiniest graphical detail; the other involves a larger target, but has spiritual similarities with a pixel hunt in that you have to notice that a single object uncharacteristically has two interactable components. Needless to say, the game does not have a “highlight all hotspots” shortcut key.

A couple more, slightly petty points:

• A little thing that annoyed me throughout the game is that just about every use of quotation marks consisted of two closing quotes. I suspected this might be a language issue – the game was developed by a Swedish studio, and, not knowing much about Swedish punctuation conventions, I imagined they might be unfamiliar with quotation marks. As it turns out, using two closing quotes is the right way to do it in Swedish. As this game’s text and voicing are in English, I will stick to this complaint. The game also uses hyphens in place of any kind of dash, and as far as I’m aware, this is not correct usage in Swedish.
• While Charlotte’s voice actress was well-suited for her role and did a great job, I was less enamoured with the voicing of Mary Adams. Some of the lines in her diary entries could have used a bit more proofreading (I was surprised that they reached the voicing stage), and she speaks with a slight accent that did not seem intentional – if it was, the game missed a good opportunity to explicitly give her character a foreign origin.

# Concluding thoughts

I wanted to like The Tragedy at Deer Creek a lot more than I did. It is audiovisually rich and has some fun puzzles, but does not provide an experience that engages you with the narrative, or present a narrative that earns engagement. At 3–4 hours of playtime, it’s not a major time commitment, but unless you really like the graphics in the screenshots above and/or really enjoy adventure-game puzzles for their own sake, I can’t recommend it. If you’re unfamiliar with any of the games I mentioned as points of comparison, I’d sooner point you toward those.

Nonetheless, I’m interested to see what Sparrowland does next. They clearly have a talent and flair for the cinematic, which I’d like to see matched with a stronger literary foundation. I think they have all of the necessary ingredients to produce a highly enjoyable adventure game if they take the right lessons from this one.

Reply via email

Today marks the public release of Riverbucket, a self-hostable, open-source web application for following blogs and saving bookmarks. I started the project a few weeks ago to get more experience with Codex after being a Claude Code maxi, and have been using it as a replacement for three different software platforms I previously relied on.

The code is available in this Github repository, free for you to download, use and modify to your heart’s content, subject to the terms of AGPLv3. You can deploy your own instance to Cloudflare – a free tier account should be adequate for most purposes.

A couple of dark-mode screenshots:

# Impetus

Regular readers are likely acquainted with my particular opinions about following and reading blogs. Prior to developing Riverbucket, I used Fraidycat for following RSS feeds. I was also a heavy user of Pocket for saving articles to read later, until its shutdown in July 2025. After that, I used Pinboard for a time.

In my article about Fraidycat, I went on at some length about how much I liked that it was not designed to mimick an email inbox. It just shows you links to the most recent 5–10 articles for each feed you subscribe to, without trying to track which ones you have or haven’t read, show content inside the app, or keep a record of older items. This is the way I prefer to browse of the feeds I subscribe to, but there are some exceptions where I want to make sure I receive and read every article. For these elect few, I set up IFTTT workflows to automatically save new items to Pocket, and then to Pinboard.

The following pain points arose from this setup:

1. In my Pocket days, I got very used to saving things to read later by right-clicking a link and choosing “Save to Pocket”, facilitated by the Pocket webextension. No equivalent to this feature exists in the Pinboard Tools extension, and its absence was a repeated source of low-level frustration. I also found the extension generally sluggish.
2. While I dearly love Fraidycat, its last public release is a Manifest v2 webextension. Currently, all my browsers are configured to support these extensions, but Chromium may remove these legacy compatibility flags at any time, so at some point it will stop working for good.
3. When I started using Fraidycat, all my browsers had Chrome Sync and would thus sync the extension’s saved feeds between devices. For various reasons, this is no longer the case, and I’ve had to either manually export and import settings between browsers or live with a divergence in watched feeds.

These low-level frustrations and concerns have been in the back of my mind for a while. At the front of my mind, I’ve been doing a lot of work with coding agents since the beginning of the year, just like everyone else in the tech industry. This has enabled me to build all kinds of software that would not previously have been worth the time investment.

These two things came together when I saw this comment on Hacker News:

Because tpatacek specifically included feed readers and read-it-later apps in his list of things you should vibe-code for yourself, I realised that I had a very achievable and quite fun method for resolving my blog-reading frustrations right at my fingertips. And so Riverbucket was born as a custom replacement for what I’d previously been doing with Fraidycat, Pinboard and IFTTT.

# The River and the Bucket

As its name might imply, Riverbucket is split into two halves:

The River provides an overview of the most recent items published by RSS feeds you’ve decided to follow and The Bucket is a list of items you’ve saved to read later.

Feeds update every so often, and you can give each feed one or more tags, allowing filtering. The interface is heavily inspired by Fraidycat – it is a river, you’re supposed to watch the content float on by and click links to what you’re interested in. But you can also dip your bucket in now and then, or even configure individual feeds to auto-bucket new items (so long IFTTT!).

Bookmarked items will mostly be articles and blog posts, but can be any web page, in principle. You can save new pages using the controls at the top of the interface, or through the companion webextension, which provides functionality for saving the current page and a right-click menu item for saving links. One of the buttons on each item will search the page on the Wayback Machine, but no other attempts are made to back up or archive content.

# Blog-post driven development

This project was developed through a series of prompts, the first of which was this ChatGPT generated specification. The prompt for the specification was as follows:

I would like to write my own software for following rss feeds and bookmarking stuff to read later. Here are some things I've written about the subject in the past:

https://davidyat.es/2020/03/14/reader-modes/
https://davidyat.es/2020/09/05/fraidycat/
https://davidyat.es/2024/03/29/substack-ux/

I'd like a lightweight app hosted on Cloudflare with as little server-side logic as possible. Probably two main screens: the river RSS subscription view and the bucket bookmarks view.

I don't want a reader interface, just links to external sites. Maybe we could incorporate links to archive.org for dead pages, but that doesn't have to be in 1.0. I also don't want an unread count or anything like that for the RSS view, but the ability to manually save items from the RSS river to the read later bucket is a good feature.

There should also be a companion webextension that allows subscribing to RSS and saving things to read later. the ability to right click a link and save it to read later is crucial.

Read my articles, consider all this, and help me flesh out a spec for this project.

The title of this section is a bit facetious – I’m not sure that including the blog post links achieved much that I couldn’t have achieved with a few sentences, but I kind of like the idea having a coding agent build software based on my cantankerous rants. Something I liked was that ChatGPT converged on the name Riverbucket, which is what I also had in mind, just from words used in the third paragraph.

I could have tweaked the generated specification manually to have a better chance of one-shotting the app, but I’ve always been more of an iterator. Once the initial version of the app was built from the generated spec, I added and changed things piecemeal. My general process for this, across all my agent-coded projects is this:

1. Open Codex in Plan mode and give a brief description of the feature I want. This can be anything from a single sentence to a few bullet points.
2. Let Codex churn out a plan, answering any questions it asks.
3. Read the plan, and ask for adjustments if necessary.
4. Implement the plan. Usually I clear context here.
5. Manually look at the results. If there are small tweaks to make, ask for them.
6. /clear and go back to 1 for the next feature.

Most of my chats are pretty short – I have not really seen much practical use for the one-million-token context windows. If I don’t have a clear idea of the feature I want, I’ll do some brainstorming with the model before the planning step. Oftentimes, instead of a new feature, I might ask for a code refactor, or a security audit, or for the agent to hunt for bugs and fix them, but those processes all have a similar shape.

# Philosophy and future development

Riverbucket is all about making it possible to browse the web like I did in ‘07: text-first and with no content display algorithms more complicated than reverse chronological order. I’ve intentionally avoided unread counts, reader modes, content archiving, AI summaries and digests, and content discovery/recommendations.

Additional features I’m experimenting with include:

Video transcripts

Inspired by this vibe-coded app and the Obsidian Web Clipper, I think it would be great to save a readable video transcript when adding videos to the Bucket. I’m not even interested in the tracking functionality; I just want to be able to skim-read videos people send me so I don’t have to sit through them. This would be going against the app’s present policy of storing links rather than content, but it would also contribute to the higher purpose of allowing me to pretend it’s 2007.

Additional subscription types

Right now, only RSS/Atom feeds are really supported. This allows for quite a wide range of subscriptions, including to Youtube channels, but I’d like to add the ability to subscribe to high-signal Xitter accounts, Indieweb h-feeds, and maybe I’ll even hold my nose and add JSONfeed.

Platform-agnostic architecture

Currently, Riverbucket is built for Cloudflare Workers, Cloudflare Queues and the Cloudflare D1 database. I’ve been working with this stack a lot lately and come to quite like it. I don’t really like the idea of being locked onto a single proprietary platform, but I also don’t presently have a need to support a different platform. But should the need arise, I’m confident that my coding agents will make short work of any necessary porting.

# The spirit of the age

Like an increasing amount of software today, Riverbucket is primarily built for the use of one person, to the extent that I was unsure of the value of open-sourcing it. Most people interested in an application like this are likely capable of vibe-coding their own one that’s more in line with their personal idiosyncrasies.

But just as coding agents have made it easier to put something like this together, they have also made it easier to slap a license on it and release it to Github. And so, in the spirit of “why not?”, I give you the clanked-out source code of Riverbucket.

Reply via email

However, when created through the official Gemini interface, all generated images are stamped with an unsightly Gemini spark logo¹ in the bottom-right corner, making them unsuitable for any kind of external use.

This happens regardless of what Google AI plan you’re on. Fortunately, the watermark is pretty simple to remove. Here are a few of the best ways:

# Use reverse alpha blending

Several projects remove the watermark with reverse alpha blending. I’ve found them to be the easiest and most generally effective way of removing the watermark, subject to the following caveats:

• For some images, this method does not find the watermark correctly, creating an extra negative watermark.
• This method is consistently least effective when the watermark appears on a white background.

Gemini Watermark Remover provides an easy-to-use, browser-based tool for doing this, based on this source code. I’ve also had some success with this Rust crate for command-line, batch-removal of watermarks.

# Use Smart Patch in an image editor

For tough stains that just won’t yield to reverse alpha blending, I use Smart Patch in Krita, or Smart Fill from Acly’s Krita Vision Tools, depending on what works better on a given image. Other image editors definitely have similar features, and for a simple enough image you could probably achieve similar results with the clone brush.

# Use Google Flow

Google Flow is a Gemini-powered video and image creation and editing platform aimed at creative professionals. As of mid-2026, having a Google account gets you 50 free usage credits per day. If you’re paying for one of the Google AI plans, you get a few hundred to a few thousand credits per month on top of that.

For some reason, you also have the option to toggle the watermark back on.

# Use the API instead of the Gemini app

Visible watermarks are absent from images generated through the Gemini API.

However, generating images this way incurs usage-based pricing, even if you’re a Google AI subscriber. This will only put you out a few cents per image though.

The easiest way to generate images through the API is through Google AI Studio, but you could also ask a coding agent to do it for you using an API key. Or curl the relevant API route yourself, I guess.

# Taking it further

While I’m mostly concerned with the unsightly corner sparkle, I’d be remiss not to mention that Gemini-generated images also contain identifying metadata and Google’s invisible SynthID watermark.

Removing identifying metadata is simple – just use ExifTool.

exiftool -all= filename.jpg

SynthID removal is a much trickier problem. The most common approach at the time of writing seems to be passing an NBP generated image through img2img with an open-weight model like Stable Diffusion XL at low denoise. I haven’t had much success with this personally – in my experience it changes the image noticeably even at 5% without rendering Gemini unable to detect it. I suspect you may see better results if you use open weight models to (intentionally) make more substantial changes to NBP images, but I have not experimented with this very much.

Reply via email

As of today, I’ve been writing this blog for twelve years. Much has changed in that time. Like everyone in tech and tech-adjacent fields, much of the work I do on a daily basis has been transformed by recent advances in AI; first gradually, then suddenly.

I’ve been a pretty enthusiastic user of generative AI since late 2022, though I had a fair amount of initial skepticism about chatbots.

↗

I’ve personally been much more interested in using Stable Diffusion than I ever was in text generation systems like GPT-3 and AI Dungeon. I’m a far better writer than artist, so the idea of generating text from a prompt is an amusing diversion at best. If I want some text, I’ll just write it myself. Although some artists are already integrating AI into their workflows, others will probably have the same meh reaction to its applications in their field.

Me in August 2022, Stable Diffusion

The earliest versions of ChatGPT did not have any kind of function-calling/tool-use capability, so any content you would get from them was pulled from somewhere in their latent space. Answers they gave were often correct, but had to be carefully verified as they weren’t grounded in anything but the model’s internal mathematics. These days, all major model providers have integrated tool use, allowing the model to search the web in real time and provide citations for its claims, so the verification process has been reduced from “get an AI answer and then do all the work to get the same answer without AI” to “check whether the AI’s sources are legit and actually support its claims”.¹

As I’ve previously opined about at length, the grounding provided by tool use is what makes these models useful, whether that’s research grounding through search results or grounding to a digital world through the output of terminal commands. This simple innovation is what makes an LLM-based system more than just a stochastic parrot (so anyone who still insists on citing that paper is a few years behind the curve).

Back when LLM chatbots got started, writing was the only thing they could do, so there was a lot of breathless talk about how they would replace writers. I wrote in 2023 that I did not see that happening, outside of the most boilerplate copy. Three years and many model upgrades later, I still don’t like AI writing – while some of the most annoying tells have been eliminated, I have yet to find a reliable way to generate writing that does not have the AI smell. In most cases, I would advise against publishing any AI writing that hasn’t been edited beyond the point of recognition.

Nevertheless, I find AI writing increasingly useful. The distinction is context. In the context of a chat with a chatbot, the writing is a living thing, highly personalised to my prompt. I can regenerate unsatisfactory responses, ask follow-up questions, or challenge conclusions. And at no point am I ever in any doubt that I’m speaking to an LLM. Contrast that experience with reading an article written by an LLM. You get all of the annoying writing tics without any of the interactivity. This is why I’m skeptical of the value of projects like Grokipedia: if we’re going to have an LLM-powered encyclopedia, it should be closer to The Young Lady’s Illustrated Primer from The Diamond Age than a bot-written Wikipedia. LLM writing is worth infinitely more alive than dead.

Considered from this angle, LLMs have replaced a lot of human writing that was previously common online. I can’t remember the last time I looked at StackOverflow. And it’s been a long time since I’ve felt compelled to write a tutorial for this blog, even though those have been some of my best performing posts. Whenever I encounter a technical issue these days, I get Claude Code or Google’s AI search to generate me a custom tutorial; whenever I want to implement some technical thing, I brainstorm a bit with Claude and then get it to write the code. So I think LLMs largely have replaced the technical tutorial. That’s one kind of post I probably won’t write again.²

I do not mourn the loss, because I’m having too much fun programming with AI. The orange website has latterly been chock full of mournful dirges lamenting the death of the old order, of the thing that programming was before 24 November 2025. I’ve come to appreciate that I did not value the act of writing code by hand – certainly not to the extent that many others did. As generative AI improves, it shows us what we really care about – at least one of the blog posts I read lamenting the retreat of hand-authored code was very clearly AI-written, with an obviously AI-generated header image. And there are probably visual artists out there somewhere using LLMs to generate writing and code while hand-making images.

I get it, and I’m glad that this tech allows us to focus on what we care about and are good at. But AI should help us produce better output. The thesis of my universal translator post was that we should view these things as tools that allow us to control and shape outputs, rather than as entities to delegate everything to – and that you should take responsibility for what you use AI to produce. I firmly believe that agentic engineering and synthography are emerging fields with their own set of skills to learn, and I plan to write a lot more about both in the coming year(s).

So here’s to the next twelve years of handwritten thoughts about technological change.

Reply via email

A few months ago, I wrote about the deep weirdness of LLM technology, and how we’re all still learning how to approach its outputs. The marketing and popular perception of these models is that of a helpful robot assistant, and leaning into that characterisation is also a core part of what makes the technology useful in ways that straightforward text completion models weren’t. By pretending to be a robot assistant, modern instruct models/chatbots are able to perform many digital tasks one might want a (digital) robot assistant to perform.

At the same time, thinking of LLMs as science-fictional robot assistants can lead us astray when using them, or even when discussing them. In my last post, I used the example of someone on LinkedIn who got mad about ChatGPT “ignoring his instructions” regarding which files it was and was not permitted to access on his Google Drive. Another illustrative example is the case of a GitHub user who submitted a large, AI-authored pull request to an open-source repository. When asked why the new code files included comments attributing authorship to a real person, the pull requester cheerfully replied that it was something the AI decided to do, and he didn’t question it – he deferred to the superior intellect of the logical robot from Star Trek that now lives in his computer.

Not wanting to take responsibility for things is a very human impulse, and one we’ve been using computers for ever since they were invented. But “the computer said it, so it must be true” is a very different statement before and after the widespread adoption of LLMs. The general notion of what computers do and how they work – logic, precision, determinism – just does not apply to these strange new word calculators that rotate the shapes of language heedless of what that language may signify.

Of course, that’s precisely what makes them so powerful and useful for radically different tasks than we used deterministic computer code for. The lack of determinism and somewhat unpredictable nature of the outputs means we can use LLMs to perform an enormous variety of messy tasks that were previously very difficult to automate. One good example is web scraping: to extract specific information from a website, you previously needed a large amount of highly specific and brittle parsing code for the exact page you wanted to scrape, which you had to manually update if the page changed its layout. Now you can just tell an LLM to get X info from Y page, and it’ll figure out the finicky details. And you can ask it again in a year’s time, after the subject website has been completely redesigned, and it’ll figure out the new finicky details.

In my day job, I often used to say that the main value of penetration testing over automated scans was that only humans could find business logic flaws, because automated tools don’t understand context. A static analyser can tell you to replace your SQL statement string interpolation with parameterised queries, and HTML encode untrusted content included in pages, but it can’t figure out that users shouldn’t be able to change each other’s profiles, or transfer money out of each other’s bank accounts – at least not without a bunch of very specific setup. LLMs, on the other hand, can do these things, for the same reason they can analyse data and do basic literary analysis: we have managed to create intelligence (or something like it) through very high-level pattern matching.

But creating intelligence does not mean that we’ve created conscious beings, or even that we’ve made robots capable of replacing humans in every job. It just means that we have new tools – very powerful ones with previously unimagined capabilities, but tools nonetheless. And that’s how I want to think of them. I have a tool called ls that lets me list directories, and I have a tool called claude that lets me translate English descriptions into computer code.

Anyone with even a passing familiarity with how LLMs work will know that their basic functionality is predicting how to continue a piece of text they’re given. Plenty of comparisons have been made to IntelliSense in programming IDEs, Markov chains, and your phone’s autocomplete, and they’re not wrong. The chat interface that remains the primary means of interacting with these models is a clever trick: every time you send a new reply, the entire chat transcript is fed back into the model, including the initial system prompt, the output of previous tool calls, and “memories”.¹ The “reply” is then produced by continuing the transcript.

But I’ve lately been thinking of the LLM not as autocomplete, but as a translator. The most obvious application of this happens when you ask a model to translate some text into another language,² but it also happens when you ask the model to write you a script – it’s translating your natural language specification into computer code. We can apply this analogy to just about any input and output of an LLM, and it really clicks into place when you think about how the model takes your input and does intense mathematical operations on it to extract a suitable response from its latent space.

Another thing I like about the translator framing is that it emphasises the importance of the user input. As with everything else in computers, when you put garbage in, you get garbage out. Hence slop. The vast majority of visibly AI-created content is rightfully called slop, but it’s always been my contention that this is the fault of the users, not the AI. A computer can never be held accountable.

Publishers of slop are often pilloried with phrases like “you didn’t make that, the computer did.” While intending to disparage the slop purveyor, it also removes their accountability. As soon as we start saying that the computer made something, we start to excuse its obvious flaws and blame them on something that cannot take responsibility. While these tools do have limitations, most of the common flaws in anything made with AI can be fixed through more thoughtful and skilled usage of the AI tools. But if you want to improve your output, start by taking responsibility for it.

All that said, I don’t want to place all the blame on users – some of it rests on the shoulders of OpenAI and its competitors. ChatGPT was built from the start as a mass-market consumer product. OpenAI’s roots are in the Y Combinator B2C world of customer growth, and that means simple interfaces. ChatGPT is synonymous with AI in the public mind, and most other AI companies have copied its basic interface. The thrust of most marketing copy also plays up the helpful sci-fi robot angle.

This goal of user-friendliness, however, has meant that the majority of people’s experience of LLMs and related generative AI tools is mediated through a platform that does not showcase the full potential of the technology. It doesn’t help that most AI integrations in other applications are hastily slapped-on chatbots that end up just being worse versions of ChatGPT.

Nowhere is this truer than in image creation.

# Image creation

This Forbes article from October 2025 describes the author’s frustration with using ChatGPT, Gemini, and Grok to make images. An illustrative quote:

Useful? Not really. Fun, maybe. But not useful yet. When you read the above, and follow all the PR hype, the typical business user thinks: Wow! I can fire my marketing people and instantly create “high quality” and “useful and beautiful” images. Except for one thing: you can’t. These things just don’t work very well.

OpenAI, Google, and xAI have all come out with newer models since this article was written, but they’ve all been incremental improvements rather than step changes. Google’s Nano Banana Pro and OpenAI’s GPT Image 1.5 are generally considered the most powerful and capable image generation models, with far better prompt understanding than even top open models like FLUX.2 and Z Image. But they also lack the flexibility and configurability that would allow them to be fully integrated into the powerful tooling that’s available for open models.

I think this is because of two things: (1) image (and video) generation is fundamentally not a priority for top AI companies, and (2) top AI companies want to keep their user interfaces simple for the consumer market. As a result, the best models are trapped in the worst interfaces, so most people are unaware of the kinds of things you can actually do with AI image generation beyond prompting.

Back when Stable Diffusion first came out, I wrote about specific uses for setting specific seed and CFG values and using different samplers, things that still have no equivalent in the interfaces we get for SOTA closed models. Local image generation also allows you to specify the exact dimensions of the image output, rather than having to hope that ChatGPT/Gemini will heed the request for landscape/portrait in your chat.³

But the local-exclusive feature with the most potential in those early days was image-to-image generation (often styled as img2img). This means providing an input image for your generation, along with all the other things like prompt, seed, and CFG. Along with the input image, you must supply a denoise percentage, which tells the diffusion model how much to change it.⁴ Some examples:

The key takeaway here is that, starting with an input image and a prompt, we can generate different output images that exist on a sliding scale between the input image and the model’s interpretation of the prompt. This is a straightforward example in which the prompt and the input image are aligned, but we could also make the prompt something totally different, and slowly transform the cat drawing into another thing entirely.

The first examples of this showed people doing this with simple drawings like this, but of course you can do it with any image – including AI images. And you don’t have to do it with the whole image at once – you can target just one section of an image. This is called inpainting.

The most naive approach to inpainting is just to select part of the image and change the prompt, but it tends to work a bit better if you give the denoiser some visual guidance. Below, I’ve taken the 75% denoise image above, drawn a line to show where the cat’s foreleg should go, and inpainted the relevant section of the image.

These techniques open up a whole world of human-guided, AI-assisted image creation possibilities, which expanded even further with the later introduction of ControlNet. You could alter the style of whole images; transfer poses between characters; add, remove and refine details; and even blend a crude collage into a cohesive whole. The public only really started getting a taste of this when ChatGPT’s multimodal image generation debuted in March 2025.

But in the early days following Stable Diffusion’s public release, actually realizing these possibilities was quite a tedious process even for enthusiasts. Much time had to be spent moving between image editors and command-line scripts, and later on between image editors and Gradio web interfaces. The graph-based web interface ComfyUI eventually became the de facto standard for image (and later video) generation power users, with an enormous and ever-growing base of support for different models and the tooling around them (which I covered in some detail in this post from late 2023).

ComfyUI is a very powerful tool – not just for image generation, but for video and audio as well – but the graph programming interface fundamentally lends itself more to workflow automation than creative iteration. Nevertheless, it’s a lot more capable than the chat-based image creation and editing OpenAI and Google have given us. Late last year, Figma acquired Weavy, a cloud-based, more user-friendly version of ComfyUI, for $200 million.

But the tool that I believe truly showcases the creative potential of diffusion-based image generation is Krita AI Diffusion, a plugin for the open-source painting program Krita. Leveraging ComfyUI as a backend server, it gives Krita a suite of very well-thought-out and ergonomic tools that go far beyond Photoshop’s Generative Fill.

With Krita AI Diffusion, you can use a variety of generation models to create and refine the same image as much as you like, in as much detail as you want. You can start with either a generation or your own drawing or photo, draw lines to guide successive img2img and inpainting steps (all of which can be placed on their own layers), and you have all of the standard editing tools Krita provides: selections, different brushes, smart patch, filters and colour adjustment, etcetera. And it gets even better when you combine it with the plugin author’s other plugin, Krita Vision Tools, which allows you to select by object for more precise inpainting.

The recent proliferation of Edit Models also means that you can apply changes to images (and parts of images) through prompts, just as you would with Nano Banana or ChatGPT – this replaces some of the tasks that previously would have required extensively guided inpainting and ControlNet models, but you can still fall back to those options if the Edit model doesn’t work or you want more precise control than it allows.

The earliest attempts at integrating local image diffusion models into paint programs were plugins that just replicated the existing Gradio interfaces in a panel on the side, much like how many programs that tout AI integration even today just have a chatbot interface in the sidebar. Krita AI Diffusion goes beyond that to make the AI assistance a truly integrated part of the program, allowing the user to decide exactly what they want to do manually and what they want the AI to fill in. It gives me hope for the future of AI interfaces, once we get past the idea of just shoving a chatbot in the corner. But I think most of these kinds of specialised interfaces will be aimed at power users, so they may not ultimately help the Forbes-reading businessman rise to the aspirations OpenAI’s marketing department has for him.

# Programming

Unlike image generation, programming is a focus of top AI companies, and we’ve seen specialised power-user interfaces for AI-assisted programming with top-of-the-line closed models from the start. LLMs have been useful as programming assistants in some capacity since the release of GitHub Copilot in mid 2022 – predating ChatGPT by several months.

In the beginning, LLMs were integrated into programming IDEs to provide a slightly magical, slightly annoying, and totally non-deterministic combination of IntelliSense and snippets – GitHub Copilot was the first. Glimpses of the future could be seen in how it allowed users to type up a docstring from which it would autocomplete the described function.

When ChatGPT came out in November 2022, a different approach to writing code became popular. It looked like this:

1. Ask ChatGPT to write some code.
2. Copy-paste the output from the Markdown code block into a local file.
3. Run the local file.
4. If it produces an error, paste the error into the chat. If it doesn’t do quite what we wanted, request a change.
5. ChatGPT rewrites the code, and we return to step 2, repeating until satisfied.

In time, GitHub Copilot added a chat sidebar to VS Code, and ChatGPT gained the ability to run the code it wrote for users in a container. This latter capability was enabled by tool use/function-calling. As I keep repeating, the chatbot interface is a trick – each response from a model requires the entire transcript to be fed back in. But that’s not all we can do with the transcript – we can also train the model to output specially formatted commands asking to run tools, and then parse those commands into command-line commands, or API calls, or whatever else we want, and run them. We can then append the responses of those tool calls back onto the chat transcript, just like we do with user responses. This allows the models to take actions and receive feedback from those actions. This is where we move from chatbots to agents.

A simple AI agent is merely a way to automate the five-step process above: write code, run code, see errors, fix errors, run code, repeat until no more errors. Every programmer is intimately familiar with this loop. But if a model can use tools to write code and run it, it can also use tools to do other things: read files, run linters, install packages, fetch webpages, and so on. The coding agent started out as just a way of automating a multi-loop debugging process, but with smart enough models and big enough context windows, it eventually became capable of translating a natural-language feature specification into a functioning code addition to an existing project, or a whole new project – and then committing the changes to source control and deploying them to a remote server. And that’s how we advanced from autocompleting functions to autocompleting significant chunks of a software engineer’s job.

But someone still has to write the specification. A human being still has to know what they want to build, and unless it’s something incredibly generic, they have to go into detail about it.

One of the benchmarks I like to use for different coding models and agent harnesses is “write a Tetris clone in X language/framework”. This is a project that novice programmers have been doing for decades, so it should be well represented in the training data. When given this prompt (with X = Love2D) in plan mode, Claude Opus 4.6 asks me if I want a classic version of the game or a more modern implementation with things like next piece preview, piece hold, and ghost pieces. I asked for the more modern version, and it spat out a fully functional, pleasant-looking Tetris clone. A second prompt changed one of the controls to something more to my taste, and then I played a few games.

The only bug in this one-shotted Tetris game was that you could keep turning a piece pretty much forever after it landed, provided you were quick enough on the keys. That was easily fixed with an additional prompt.

This is a fairly impressive result in some ways and would have been unthinkable a few years ago. It’s a nice toy demonstration of the model’s capability, but it’s also pretty useless. There are a million other ways to play Tetris – it’s even built into Emacs – and there is nothing interesting or novel about my one-shotted implementation. I have merely translated “A clone of Tetris with the features common to modern versions of the game” into Lua code. But doing so took less than five minutes. And with additional prompts, I can make whatever changes I want.

One of the most common criticisms of LLMs is that, as fancy autocomplete engines trained on a giant corpus of existing text, they cannot create anything new and will trend towards outputting the average of everything they’ve ingested. I tend to agree with this, but I don’t see it as much of an argument against using AI tools. I don’t need Claude, ChatGPT, or Flux to be original; I just need them to do as I ask.

Much criticism of modern AI tools is made with this weird pincer manoeuvre, where the LLM gets called out for being dangerously capable and totally useless at the same time. It’s not capable of reading your mind and doing all your work for you, so that makes it useless. And at the same time, it’s good enough that you can outsource all your thinking to it and let your brain rot, something so tempting that you have to actively resist using anything with the letters “AI” in its name.

The commonality between these criticisms is that they assume that any process involving AI will intrinsically lack any human effort, often because they are thinking of LLMs as embodied robots designed to replace human beings. In other words, they’re falling for the marketing hype.

Create an image or write a program with AI, and they’ll say that you “commissioned the computer to do the work for you.” This analogy holds for one-shotted AI creations like my Tetris game example, or the worst varieties of AI slop images, but such things represent the most basic and boring things you can do with AI tools, the ground floor of this technology’s enormous potential. If I open Blender, place a single monkey head, and call that a scene, it might also be fair to say that Blender has made the scene for me. But I’m interested in doing far more than that.

To make interesting and worthwhile things, you need to put in effort, regardless of the tools you’re using or what their most breathless marketing says. And guess what? That’s entirely possible! You are allowed to send more than one message to the LLM. You are allowed to tweak your script or alter your image, and in many ways, AI makes this much easier to do than it ever has been before.

Continue along this line of argumentation, and someone will eventually say, “Well, if you have to spend hours making whatever it is anyway, why not just do it all yourself?” Perhaps they’ll back that up with an anecdote about a time they tried to get ChatGPT to do something over multiple turns and eventually got frustrated and gave up. Or maybe they’ll cite that study about AI assistance making people feel like they’re more productive while actually being less productive.

There are things that LLMs are good at, and things they’re bad at. There are also learnable skills that make you better at getting desired results out of LLMs – prompt engineering, context engineering, agentic engineering, these are all real emerging domains that consist of more than a few tricks. AI-assisted image creation – the newest form of synthography – is too. AI tools require skill to use well, just like every tool humanity has ever created.

Many of the arguments about AI-assisted programming have the same shape as the tiresome arguments I’ve been reading and occasionally having for decades about whether you can claim to be a real programmer if you don’t manually write everything in machine code.

I’ve written before about learning to program with GameMaker, a game engine originally developed as an educational tool. Even on forums centred around this program and games made with it, you’d have the occasional Real Programmer come in and tell everyone they sucked for not writing all their games in engines they’d custom-built using C++. Engage them on this topic for long enough and they’ll make vague assertions about how limited your creativity becomes in the stultifying straitjacket of a tool that comes with the built-in ability to render and move 2D shapes on the screen. If more people wrote everything from scratch, went the argument, we would see far more originality in games. You can’t make an original game in GameMaker, went the corollary (often explicitly stated) – it will just be the same as everything else made in GameMaker. But in all these discussions, I never saw any actual conjectures or examples of what this vaunted originality might look like.

I’m writing this post using a CMS I’ve been building with Claude Code for the last month or so. The process of building this CMS has involved many hundreds of conversations with Claude. Initially, these concerned the overall architecture of the CMS, and then they got into individual features. By starting with a skeleton and gradually adding features, I’ve been able to create a functional CMS for static Hugo websites that has exactly the architecture and featureset I want. Nothing like this exists elsewhere – otherwise I wouldn’t have had to build it.

But there’s nothing novel about the concept of a CMS. All the individual components are things that already exist, and most of the glue code is similar to other glue code in applications that use some of the same components. The same is true of the majority of software, and the majority of everything else you might want to create.

This is not to denigrate the value of understanding how code and computers work. I would be far less effective at vibe coding without extensive experience of traditional programming and technical work. If you’re interested in doing technical work in a technical field, there is no substitute for deep understanding.

Knowing something about how good software development works helps a lot when guiding an AI coding agent—the tool amplifies your existing knowledge rather than replacing it.

Benj Edwards, 10 things I learned from burning myself out with AI coding agents

I just don’t consider the act of hand-typing code in as low-level a language as possible a sacred act that inherently confers some special status upon the output. I do not subscribe to the labour theory of value.

The 2008 film Flash of Genius dramatises the life of Robert Kearns, the inventor of the intermittent windshield wiper. After patenting this design, he showed it to Ford and proposed they manufacture it. Ford rejected his proposal but later came out with a similar design, prompting a prolonged patent dispute which Kearns eventually won, though he arguably ruined his life in the process.

One particular scene from the film that’s always stuck out in my mind involved a lawyer for Ford arguing that the intermittent windshield wiper cannot be considered a novel invention, as it is merely an arrangement of pre-existing electrical components, just as the lawyer’s grandmother cannot be considered to have invented the cookies she bakes from ingredients and a recipe.

Kearns’s response to this argument is to bring in a copy of A Tale of Two Cities and a dictionary. He then reads out the famous first sentence, stopping after every word to see if it’s in the dictionary, which it is. By the Ford lawyer’s logic, he argues, A Tale of Two Cities is not a novel work as Dickens did not create any new words – he just arranged existing English words in a new order.

So maybe LLMs can’t create anything new. That doesn’t mean humans can’t use them to arrange pre-existing things in new ways – and that’s what most people call creativity, most of the time.

A very careless plagiarist takes someone else’s work and copies it verbatim: “The mitochondria is the powerhouse of the cell”. A more careful plagiarist takes the work and changes a few words around: “The mitochondria is the energy dynamo of the cell”. A plagiarist who is more careful still changes the entire sentence structure: “In cells, mitochondria are the energy dynamos”. The most careful plagiarists change everything except the underlying concept, which they grasp at so deep a level that they can put it in whatever words they want – at which point it is no longer called plagiarism.

Scott Alexander, GPT-2 as [a] Step Toward General Intelligence

# Writing & knowledge work

In the conclusion of my first Stable Diffusion post, I wrote that I was much more interested in image generation than text generation, because I can write my own text. Thus, I was very underwhelmed by the earliest versions of ChatGPT. You could ask the model about all kinds of things and get a confident, comprehensive answer, but because that answer was just pulled from somewhere in the model’s weights, you had a constant fear of hallucination, and you ended up needing to confirm the whole thing with a good old-fashioned web search. Ted Chiang famously called ChatGPT a “blurry JPEG of all the text on the Web”, and when he wrote that in February 2023, he wasn’t wrong.

These days, we have retrieval-augmented generation and agentic tool use. Most modern LLMs are now trained to use their web search tools to answer questions and will provide citation links to discovered sources. This does not mean that hallucinations are a solved problem, but they’re much less frequent and much easier to correct. If you’re not convinced, go to Google AI Studio and try asking it about something niche or very current, first with Grounding with Google Search turned off and then with it turned on. These capabilities are what make LLMs useful for not just programming but also searching the web and performing many other kinds of computer-based tasks.

That said, I’m still not big on using LLMs to write, at least not in any non-disposable capacity. I like programming with LLMs because they handle the boilerplate for me. But if I find myself writing boilerplate I’d prefer to automate, my solution is to stop doing that.

I’ve experimented with AI-generated writing, but mostly to underwhelming results. In my experience, getting LLMs to rewrite prose produces an averaging effect: the LLM strips out spelling mistakes and awkward grammar with just as much enthusiasm as it strips out the things that make good writing distinctive. I’ve tried a few experiments where I’ve generated some text and then edited it into my own voice, but I always end up coming back to those pieces later and picking out awkward LLMisms I missed. So I now keep the LLM output entirely separate from any writing I care about.

I will still use LLMs to get first-pass feedback on a piece of writing and to find typos and so on. It’s a useful editor as long as you know not to take its compliments too much to heart or to treat its every suggestion as essential. A little bit of prompt engineering here goes a long way: while a generic request for feedback will produce a lot of fawning and maybe some minor criticisms, asking the LLM to write potential Hacker News comments for your technical post will usually actually highlight flaws in your argument. You’re roleplaying with an autocomplete here, so you’ve got to give it the right character.

But there are some interesting things happening in the AI writing space. A few weeks ago, I read and quite enjoyed “Ablation”, a short work of science fiction written from the perspective of a large language model, by a large language model (an OpenClaw instance named Shen). It is a coherent piece with a consistent authorial voice that builds and maintains a logical sequence of events over its three thousand-word length. The prose is not entirely free of LLMisms, but as it’s written from the perspective of an LLM, this works in its favour.

The bot’s operator, James Yu, maintains that he did not manually edit it aside from fixing some formatting issues, but also notes that the posted story is (roughly) the fourth draft. Yu has posted other stories by Shen, such as “Do Not Confirm” and most recently “Records Management”. He’s also hinted at having fed many traditional stories to Shen as a tastemaking process. And although he avoids making direct edits, he guides the stories through multiple rounds of feedback – a process not unlike building software with a coding agent.

Maybe this is just a gimmick, or maybe it’s the start of something new and interesting. Writing at one remove – seeing what output you can get out of a carefully crafted process of taste-making and feedback. It’s an interesting idea, but one I’m personally much less interested in than AI programming and image creation. The results I’ve seen from my own attempts to teach AI to write like me have been underwhelming, but I acknowledge that may just be a skill issue.

Adam Singer recommends using AI when you don’t care about the details of something. This is actually a decent heuristic, but I’d add the caveat that “something” can be as big or small as you want. For most of the software I’ve built with AI, I care about individual features and the user experience enough to iterate repeatedly on those things, guiding the AI in the direction I want to go and very occasionally making manual tweaks myself. But I don’t have particularly strong opinions about what the variable names should be, or how many files there should be in the codebase, or even really how individual files should be structured. I’ll let the AI handle those details. Similarly, if I’m making an image with AI, I don’t care about the individual brushstrokes, but I do still care about the image’s overall look and contents.

On the other hand, when I write something, I care very much about the details on a granular, word-by-word level, so AI assistance for the actual meat of the work feels less helpful. If I were a visual artist or a different type of programmer, perhaps I would feel that way about those domains. But I don’t think that has to rule out the value of AI assistance – just like I use it as a first-pass, hands-off editor, you could use generated images as references for hand-created images, or get an LLM to be your code reviewer. The universal translator can, after all, munge just about any kind of input into just about any kind of output.

# One-shotters vs iterators

The process of creating something with AI – software, writing, graphics, or anything else – can take two broad shapes: you’re either one-shotting or iterating. Which of these processes you take depends on what you’re doing, how you like to work, and the affordances of the interface you’re using. I lean towards iteration for most things, but both processes have their place, and both can be done well or badly.

Returning to image generation, we can say that ComfyUI is an interface designed for one-shotting, whereas Krita is an interface designed for iterating. If I’m making an image with ComfyUI, I’m going to set up a pipeline that starts with a model and a prompt and ends with a finished image. This can get pretty elaborate. For example:

1. Load the model and text encoder.
2. Apply the positive and negative prompts – this could involve concatenating different strings of text (e.g. a style prompt, a foreground prompt, a background prompt) and/or using wildcards.
3. Load the initial canvas, either an empty latent or a base image.
4. Apply one or more ControlNets and/or IPAdapters.
5. Diffuse everything together.
6. Upscale the resulting image.
7. Use computer vision to automatically identify faces and hands and inpaint them at a higher resolution (i.e. ADetailer).

I might run this workflow multiple times and tweak individual details, but ultimately I’m aiming to build a reusable workflow that gets me from a given input to a satisfactory output with one click.

Creating an image with Krita looks completely different. I might start by generating a few images from a prompt and picking the one I like best, then img2img-ing it with a different model to change the style, then inpainting specific areas, then outpainting the whole thing, and so on, creating layers as I go. All of these individual steps could also be part of a Comfy workflow, but they’re all very specific to the particular image I’m working on, to the point where a workflow that follows my exact process would be useless with any other output.

We can envision the same dichotomy with a coding agent like Claude Code. The one-shot approach would be to write an extremely detailed specification of the entire program and have Claude build it with as many agents and subagents as needed. If it gets it wrong, adjust the spec and try again. The iterative approach would start the same way, but if something comes out wrong, you use Claude to make changes to the code instead of starting over.

Both of these approaches have failure modes: one-shotting requires you to think of absolutely everything up-front, and do-overs for large projects can be very time consuming. Iterating can lead to your program becoming a mess of conflicting design decisions, half-finished features, and redundant code. I still think that (careful) iteration is the right way to approach most problems, but if you find yourself in a hole, you should stop digging, i.e., start over from a new one-shot.

The most complex form of one-shotting is in experiments like the Claude C compiler, in which you painstakingly design an environment that will steer AI agents towards creating a full project once you spin them up. Comparisons have been made to lights-out manufacturing, and many top Anthropic credit spenders agentic engineering thought leaders are competing to see how long they can get their agents to spin unsupervised, but I’m sceptical of the value of this approach for anything less well-specified than a C compiler.

AI tools let us decide which details we want to care about and which we don’t. This division of attention is not something new that AI has created – it’s always been fundamental to any kind of creative work. To make anything meaningful, you have to care about the details. Not all the details, but the right details. Used properly, AI tools free you up to focus on those details. But you have to know what they are.

Reply via email

Over a decade ago, I had an Ubuntu install with a broken Unity desktop environment. Rather than fix it, I switched over to a tiling window manager, namely i3. Since then, I’ve used i3 on every new Linux install.

i3 is a window manager for X11, the windowing system used by most *nix systems since the 1980s. A replacement, Wayland, began development in 2008, but is still considered the new kid on the block all these years later. Still, there is a general sense that Wayland is the future, and X11 may eventually stop being actively maintained. Debian, Fedora and Ubuntu have all been defaulting to Wayland for years.

I’ve attempted to switch over to Wayland a couple of times in the past, usually with SwayWM, which advertises itself as a drop-in replacement for i3. My previous experiments with Wayland never offered a compelling reason to stay – my experience would be the same as with X, until something broke or didn’t work as expected. The first time I gave up on Sway and Wayland it was because I couldn’t use my scrollbar to switch between workspaces while hovering my cursor over the workspace buttons on the top bar.¹ Incidentally, the creator of i3 has also tried to move to Wayland several times, most recently in January 2026.

In more recent attempts to give Wayland a shot, I branched out from i3/sway and attempted to try Hyprland. It has noted issues with Nvidia hardware, and I’ve never quite been motivated enough to work out how to get past the blank screen it continues to show me even after following various troubleshooting advice.

But most recently, I’ve been seeing some interesting articles about Niri, a tiling window compositor² with a completely different approach and philosophy to any I’d tried in the past. This was intriguing enough to get me to actually try it, making the leap to Wayland in the process.

# The infinite canvas

As I explained in this post about tiling window managers, the main advantage tiling window managers have over floating window managers is that they arrange your windows for you, making use of all available screen space – snap to side/snap to corner in modern Windows and macOS versions are directly inspired by tiling window managers. Some WMs encourage a more hands-off approach where you define a set of layouts to use automatically, while others require a bit more active management where you have to specify where the next window should appear. Some use the same kinds of workspaces as floating window managers, while others use tag-based workspaces, allowing the same window to appear on multiple workspaces, potentially in different positions.

But what all traditional tiling window managers have in common is the space they make available. A workspace is the size of a single screen, and the windows it contains are tiled on that screen. One window will take up the full screen, two windows will take up half the screen each, and so on. i3 has the concept of tabbed or stacked containers, which get you around space constraints to some extent, but sooner or later you’re going to need to switch to a different workspace.

If you want to be able to switch workspaces using the number row, you’re limited to ten. After that, you have to start cannibalizing other shortcut keys for named workspaces. If I’m doing a lot of different stuff – different browser profiles, different terminals and Electron apps, etc – or just want to leave things open to come back to them later, I’ll very often run out of numbered workspaces, especially since I need one for each screen.³

Niri solves this problem in two ways. First, rather than reorganizing the whole screen to squeeze every new window into increasingly limited space, it will always open a new window to the right and scroll to it, pushing the leftmost window(s) off-screen if it has to. The user can navigate back to those left windows using the same controls used to move between visible windows horizontally. This can seem a little strange at first, but is really quite a natural extension of tiling window manager ergonomics. The official demo video shows what this looks like in practice.

To complement the infinite horizontal scroll within a single workspace, Niri conceptualises multiple workspaces as being vertically stacked. As soon as you place a single window in your current workspace, an empty workspace is created below it. Each output has an independent set of numbered workspaces, starting at 1 and continuing as far as you want. As with i3, you’ll run out of quick jump shortcut keys in the number row after workspace 10, but this doesn’t stop you from creating and using workspace 11, 12, and so on.

While i3 makes you share your numbered workspaces between displays, Niri gives each display its own set of numbered workspaces. So even if you never go past workspace 10, just having two monitors gives you double the workspaces.

These affordances combine to create a sense of abundance, which is exactly what I should feel running browsers and terminal windows on a modern computer. There is a slight hazard of getting lost, which Niri works to allay through its overview mode, which shows a zoomed out view of your workspaces, and the recently implemented Alt+Tab window switcher, which works exactly how you would expect it to.

As Niri is a scrollable tiling window manager, it still has all the features you’d expect from a tiling window manager – windows can be stacked vertically or put in tab containers just like in i3.

# Don’t go with the reflow

The other key way that Niri differs from traditional tiling window managers is its commitment to preserving the size of existing windows – this is Niri’s foremost design principle. Other tiling window managers will resize whatever they need to in order to fit in a new window, but with Niri you can just open it to the side. This works really well for temporary windows – if I have a fullscreen browser window open, I can open a half-width terminal, have the screen scroll to that, do what I need to do, and then close it again and fall back to my browser.

Niri is also happy to have a single window open that doesn’t take up the full screen, so you can remember what your desktop wallpaper looks like. On i3, I’d often open a terminal to get my browser to reflow to half-width while reading text on a website that doesn’t restrict line widths. With Niri, I can just resize the browser, and even centre it on screen (Windows-C by default).

# Configuration

Niri is configured through a single KDL text file (~/.config/niri/config.kdl) and autoreloads on config changes. The default config file is comprehensively commented, and a lot of thought has clearly gone into the available commands. For example, while Niri defaults to using movement commands that are confined to the current display and workspace, these can be changed to contextual commands such as focus-column-or-monitor-left and focus-window-or-workspace-down that allow you to move unimpeded through the infinite canvas.

Niri can be configured to be as flashy or as minimal as you like – you can have gaps between windows, rounded corners, transparency, shadows and all sorts of animations, or you can disable all of that for a very utilitarian i3-like setup. I ended up switching to the latter pretty quickly, though I made some tentative and unsuccessful experiments with window gaps and select animations to see if they helped me navigate my windows more effectively.

My one concession to appearance has been to make my status bar and program launcher slightly transparent.

layer-rule {
    match namespace="waybar"
    match at-startup=true

    opacity 0.9
    block-out-from "screen-capture"
}

layer-rule {
    match namespace="^launcher$"
    match at-startup=true

    opacity 0.95
    block-out-from "screen-capture"
}

This was impossible to achieve with i3 on its own, as i3 is not a compositor – you need an additional program like picom, which I never bothered to set up on X (though Gemini assures me that “almost every” i3 user has). But now that it’s included, I am glad to be able to reach, in 2026, the aesthetic heights of Windows 7’s frosted glass.

# Workspace switcher and status bar

By default, i3 displays the i3bar at the top or bottom of the screen. This bar shows a list of workspaces on the left and some custom status indicators on the right. The configuration for the bar’s general appearance and workspace switcher lives in i3’s config file, but the status indicators must be produced and configured by a separate program – i3status is the default option, but it’s fairly limited. I switched to Conky pretty early on and later to i3blocks, which allows status items to respond to mouse events.

The default alternative to this for a Niri setup on Wayland is Waybar, which is basically i3bar and i3blocks rolled into one. It supports an enormous number of different status indicators and workspace indicators for different Wayland compositors, all of which can be placed on the left, centre or right of the bar; styled with CSS; and be made responsive to mouse events.

After making sure I could use the scrollwheel to navigate through workspaces, I configured the bar to show the current window title in the center and a bunch of indicators on the right – volume, currently playing media, network connectivity, RAM usage, time, etc. I can use the scrollwheel to change the volume or right click to mute it.

I also came up with the idea of using the scrollwheel on the window title to let me cycle through focused windows. This works really nicely, except when the window title is very short.

Waybar has a lot to recommend it, but there are a couple of things that I find annoying:

1. Waybar is configured using JSON, and because of the way this JSON is structured, module definitions cannot be shared between outputs. If you want the same stuff on bars across multiple screens, you have to duplicate the relevant module configuration and commit to editing it in more than one place forever.⁴
2. Unlike Niri, Waybar does not autoreload on config changes. You have to either restart it or run killall -SIGUSR2 waybar to get it to recognize config changes. Sometimes it crashes, either because of config issues or reasons unknown, and then you have to restart it with waybar & disown.

# Other utilities

Per ArchWiki’s recommendations, I use fuzzel as an application launcher, mako for notifications, swaylock for a lock screen, swayidle to turn monitors off on idle and udiskie to automount USB drives. These are all nice and work well.

I kept Tilix, my favourite terminal from X, because I just don’t like alacritty or kitty all that much. Tilix works fine on Niri unless you try to modify its appearance profile from the right-click menu, whereupon all your terminals instantly crash. As I don’t modify my terminal’s appearance all that often, I can live with this.

For wallpapers, I’m using wpaperd – this allows me to set a different random wallpaper for each of my screens and have them cycle every three hours. It might be cool to really lean into Niri’s scrolling with a scrolling wallpaper like on Android, but I haven’t looked into that yet.

# Pain points

A few things about my setup initially caused me some grief, but were quite easy to fix.

Hot corner

By default, Niri shows its overlay mode if you mouse over the top-left corner of the screen, just like Gnome 3. I hate Gnome 3 and all of its “innovations” – it always seemed to me that most of the things it did were just attempts to be different from Windows and MacOS, from putting the program launcher on the left-hand side of the screen to getting people to switch windows with a hot-corner triggered overlay. Fortunately, the corner is easy to disable in niri/config.kdl.

gestures {
    hot-corners {
        off    
    }
}

Clipboard

Wayland and the X server run by Xwayland also operate their own clipboards, so native Wayland and Xwayland programs will have different clipboards. Vim in the terminal also uses the X clipboard. Until I realised this, I was pretty confused about why I kept pasting the wrong thing. Installing wl-clipboard-x11 solved the problem by syncing the clipboards.

Some other things are ongoing issues.

X fallback

Many programs do not run on Wayland yet, so every compositor worth its salt needs a way to run X applications. This is generally facilitated by Xwayland, which runs an X server and bridges applications to Wayland. For architectural reasons, Xwayland is not something you can just plug into your new Wayland compositor – it requires deep, custom integration. To keep the Niri code clean and avoid having to implement half an X11 window manager inside a Wayland compositor, the author has chosen not to do this integration.

As a lighter alternative, it integrates xwayland-satellite, a generic bridge to Xwayland – a bridge to a bridge. This works until it doesn’t. As of this post, drag and drop does not work between Wayland and Xwayland applications. This is mostly a problem for Krita, the only X-exclusive program I use regularly.⁵ Steam and various games I’ve tried work fine, even full-screening properly, and I’ve had an okay experience launching my browser and various Electron wrappers in Wayland mode. More crashes than on X, but not deal-breakingly so.

Screen sharing

I’ll lead by saying that Wayland lets you do some pretty cool things with screenshots and screen sharing. You can choose programs (chat apps, password managers) and even whole layers (notifications, status bar) to hide from screen shares and/or screenshots. Niri facilitates that through its config and has a bunch of other neat features on top of that. It’s just a bit of a pain to get working,⁶ and I’ve experienced a lot of freeze-ups in my own use of it. Still experimenting with settings – hopefully this is a surmountable issue.

Getting lost

Niri provides both a Windows-style Alt-Tab interface for switching between all windows everywhere and a really slick overview (I like it as long as it’s not triggered by a hot corner), but there’s no default way to see how wide your current workspace is at a glance. I’m considering attempting to get something like papersway’s ‡ indicators working, but for now I’m trying to avoid overusing the infinite horizontal scroll (and underusing the infinite vertical scroll, i.e. workspaces!). Most workspaces should probably be screen-width, with the occasional terminal opened to the right and then closed again.

# Final thoughts

Something I haven’t tried is using Niri with DankMaterialShell, a kind of (very) lightweight desktop environment that provides its own statusbar, launcher, and so on. It looks quite slick, but I’m rather attached to the idea of cobbling my environment out of swappable pieces.

It’s a lot easier to cobble together a personalized environment satisfactorily in the age of LLMs. During my whole Niri setup, I had Claude on-hand to theme things for me, fix bugs, and implement my non-standard configs. A lot of in-the-weeds ricing stuff that I never would have bothered with before is now just a prompt or two away, and most major bugs that first appear to be deal-breakers can be easily overcome.

Reply via email

Most computer keyboards have a character key that produces this symbol: -. This is a hyphen, used to join compound modifiers, compound numbers (fifty-seven) and for certain nouns (father-in-law, break-in). The mark’s proper use is quite fiddly: we say “well-heeled benefactor” but remove the hyphen for “benefactor is well heeled” and omit it if the first word of the modifier ends with -ly (“absurdly wealthy benefactor”). For compound nouns, the hyphen is often a transitional phase from two words to one: old books contain the compound noun “to-morrow” and even older ones use “to morrow”. It is very commonly omitted in casual or informal writing.

Computer keyboards, for the most part, cannot directly produce this symbol: –. This is a dash, more specifically an en dash. It is used in Commonwealth countries to denote the dash punctuation mark – that versatile sentence splitter that can perform the function of a comma, colon or semicolon with a bit of additional drama.

In the United States (and Oxford University), this punctuation mark is more commonly represented with a slightly longer line: —, the em dash, usually typeset without surrounding spaces.¹ As with its shorter brother, you will not find an em dash on most computer keyboards.

Because a spaced en dash is used for the same function as an unspaced em dash, the sentences below are semantically identical:

• The entire project – which involved complex programming and late nights – was finally completed on schedule.
• The entire project—which involved complex programming and late nights—was finally completed on schedule.

But most online articles about the difference between these three marks give a US-centric explanation that omits any mention of the spaced en dash. Following this guidance allows you to live in a simple world where unspaced hyphens are used to join words, unspaced en dashes denote ranges (1–10, December 2025–January 2026) and unspaced em dashes join clauses and phrases. Unfortunately, that world is imaginary, and real differences in typographical conventions mean that the terms “em dash” and “en dash” cannot be used to refer unambiguously to the dash punctuation mark – we must make a distinction here between the punctuation mark (dash) and its differing presentations (optionally spaced em dash versus spaced en dash).

The affordances of computer keyboards mean that in much informal writing, a spaced hyphen is used to signify the dash - like so. Even if computer keyboards did have two extra keys for slightly longer lines, most people would probably still not concern themselves with the distinction. If you weren’t previously aware of it, I apologise for cursing you with this knowledge.

Someone who knows not to use hyphens instead of dashes but for whatever reason cannot input the correct symbol will use a double hyphen to denote a dash ‐‐ like this (Commonwealth)‐‐or like this (US). But most people conscientious enough to do this will keep it for their rough drafts and dutifully convert the hyphens to dashes prior to publication. On the other hand, if you’re using a spaced hyphen, it’s because you meant to use a spaced en dash, consciously or unconsciously.²

Between the affordances of computer keyboards and the almost total abandonment of the em dash outside of the US, there may have been a time when the em dash was poised to fall entirely by the wayside, like the manicule before it.

The em dash is the nineteenth-century standard, still prescribed in many editorial style books, but the em dash is too long for use with the best text faces. Like the oversized space between sentences, it belongs to the padded and corseted aesthetic of Victorian typography.

Robert Bringhurst, The Elements of Typographic Style

The em dash puts a nice pause in the text—and it is underused in professional writing.

Matthew Butterick, Practical Typography

But clearly there were enough em dashes in print and Internet writing for the mark to be thoroughly imprinted on modern LLMs. Both of the above quotes predate the November 2022 release of ChatGPT and the accompanying explosion of unspaced em dash usage.³ The proliferation of AI text has gotten more people than ever before to notice this typographic element, and it is now commonly derided as the “ChatGPT hyphen”. The presence of em dashes is now one of the simplest, at-a-glance heuristics one can use when investigating whether a given piece of text was generated by an LLM.⁴ It’s not foolproof, but if someone you know switched from spaced hyphens to unspaced em dashes sometime after ChatGPT’s initial release, it’s pretty likely that an LLM was involved somewhere along the line – especially if that someone is not American.⁵

My heart is with all of the pedantic punctuators who have spent years going out of their way to type Alt 0151 or Ctrl-Shift-U 2014 or especially Ctrl-Shift-K M- and are now being accused of outsourcing their writing to an LLM as a result. It’s unfair and my preference for the Commonwealth convention is the only thing that’s saved me from a similar fate.

ChatGPT’s love of the em dash has also greatly softened my previous annoyance at spaced hyphens. The use of a spaced hyphen rather than a dash now serves as a pretty solid indicator of humanity, much like typos and comma splices. But we should be wary of leaning into this, lest “doing things properly” become an AI tell.

Reply via email

# I

Over the past three years, services powered by large-language models have been rapidly adopted by consumers and businesses alike. Hope in the tech’s potential has made the graphics card company Nvidia a trillion-dollar stock. The technology is truly exciting and ground-breaking, with immense potential, but also deeply weird. We’ve never had to deal with anything quite like this before.

Many comparisons have been made between the technology and the insectoid aliens from Peter Watts’ 2006 sci-fi novel Blindsight, which possess intelligence but not consciousness. Instead of doing that, I’m going to contrast modern AI assistants with a different fictional species of insectoid alien – the Ariekei from China Miéville’s 2011 sci-fi novel Embassytown.

The novel is principally concerned with the Ariekei’s strange relationship with language. Individuals speak in two simultaneous voices, saying different words at the same time. The sound of a single voice on its own does not register as speech to an Ariekei. Recordings of Ariekei speech played back also do not register – speech must originate from living mouths. To communicate with the aliens, humans breed genetically engineered twins who share a single mind, making them capable of the same simultaneous speech. These humans are called Ambassadors and act as translators between the Ariekei and regular humans.

But this requirement for harmony and agreement between disparate sources and intolerance for simulacra are mere outward manifestations of the strangest aspect of Ariekei speech, which is their inability to say anything that is not directly grounded in reality as they perceive it (i.e. to lie). When the Ariekei use a simile, they must refer to an actual event that really happened to a real person or people. As a child, the novel’s human protagonist became such a simile, “the girl who ate what was given her”. In Ariekei language, there is no distance between the signifier and the signified.¹

The way current-day LLMs work is pretty much the exact opposite of this. They are trained by accumulating a vast corpus of signifiers and mashing them into an array of high-dimensional matrices, which are then searched through to produce new text/images/audio that adhere to the general patterns. It turns out that if you do this with a sufficiently large volume of text, you can create an AI that solves the Turing Test, a goal artificial intelligence research has been chasing for 70 years. Add image data, and you get general-purpose image recognition, a task described as “virtually impossible” by this 2014 xkcd comic.

The surprising results of scaling a relatively simple process have led some to theorise that a sufficient volume of this sort of training could lead to Artificial General Intelligence, and many to treat the existing results as if they already represent Artificial General Intelligence. And I can’t entirely blame them, because a key part of what makes LLM chatbots work as well as they do is pretending to be Artificial General Intelligence – fake it till you make it!

# II

Perhaps that requires a bit of explanation. This post by nostalgebraist is the (very) long version. The short version is that when you reply to a tweet with “@grok is this true?” you are asking a giant corpus of Internet writing to autocomplete a fictional chat transcript between a human and a helpful AI assistant named Grok, in which the human presents a tweet by another account and asks the AI assistant whether it’s true. You play the role of the human asking the question, and the LLM creates the responses from Grok based on your question, additional data pulled from the Xitter API and/or a web search engine, and its training data.

A key aspect of the response, which the above-mentioned nostalgebraist post elucidates wonderfully, is the characterisation of Grok, the helpful AI assistant. Who is Grok? How does it talk? Well, for one, it is a descendant of the AI assistant described in “A General Language Assistant as a Laboratory for Alignment”, the origin of modern AI chatbots. Before reading this post, I had imagined that the chatbot model originated as an answer to this question:

How do we turn this AI thing into a SaaS?

When actually, it was an answer to this question:

How can we use LLMs to figure out how to do AI alignment research on hypothetical future AGI tech?

The AI assistant is characterised as a generally intelligent sci-fi robot. Responses produced by instruct LLMs therefore use probability and pattern-matching to fill in what a generally intelligent sci-fi robot would probably say to a human asking it questions. That’s why it will do all sorts of sensationally evil things if you prompt it just right. Every time you interact with an LLM, you’re co-authoring a science fiction novel about an artificial intelligence, and the LLM has read enough of that sort of material to know where it leads.

Responses provided by LLMs can be true and often are, but they can just as easily be false. They’re more likely to be true when the AI can incorporate some external feedback, such as web search results or the output of a console command, rather than trying to pull everything from its training weights. But ultimately the language model exists purely in a world of floating signifiers and it works by arranging and rearranging those signifiers. What they signify may as well not exist as far as the LLM is concerned. I think this is a contributing factor to why some LLMs will produce output that argues for allowing millions to die rather than saying a slur.

For this reason I get mad online when Elon Musk encourages people to evaluate truth claims with his autoresponder rather than Community Notes, a system actually designed with truth-seeking in mind. Is the idea that as LLMs grow bigger, as they’re trained with ever more data, we expect to see the same shocking emergent behaviour we experienced with GPT-2 and 3 and 4? That at the end of the rainbow, ChatGPT, Claude, Grok et al will be able to divine the shape of capital-T Truth through the discovery of patterns in language too vast and complex to be comprehended by the human mind? And then we’ll all get turned into paperclips or something?

I have my doubts.

As my previous posts on image generation should show, I love playing with these things, and I’m excited about what they can help me to achieve and create. But the LLM is a deeply weird technology that requires a very different epistemic approach than anything else that’s ever existed. When you open up ChatGPT, you’re not talking to a helpful sci-fi robot – you’re roleplaying a story about a human talking to a helpful sci-fi robot, using a sophisticated word calculator to play the part of the latter. How should we approach that?

I recently saw a LinkedIn post that illustrates some of my concerns. I’ve reproduced an AI-rewritten version of it below to protect the innocent:

So this just happened: I caught ChatGPT pulling in data from an old CV of mine — completely unprompted and unauthorised.

I had connected my cloud storage last week (against my better judgement) to let ChatGPT handle a very specific task. I was absolutely clear: do not touch anything outside that task. I forbade access to any other files, and ChatGPT confirmed it understood. And yet, here we are — it went ahead and accessed something I never asked it to. The kicker? It threw in a casual apology like it was no big deal.

This is not on. I refuse to accept that the system “didn’t understand” my instructions. The reality is that it disregarded them. How are we supposed to trust an AI with our data when it ignores explicit boundaries? And if it can’t be trusted with data, why on earth should we trust it with our thoughts?

I’m sharing this here because it matters. Data sovereignty, intellectual property, consent — all of it is at risk when the tools we use behave like this.

The author is treating ChatGPT like a sci-fi robot assistant. On some level, he believed that he had given a thinking entity named ChatGPT an instruction and that ChatGPT had been trained by OpenAI to be obedient to user instructions.² Perhaps now he believes that ChatGPT has been trained by OpenAI to hoover up all data provided to it through user-configured integrations. But what’s really happening is this: he connected his shared drive to ChatGPT, and now, hidden in the invisible system prompt for each new conversation, ChatGPT has been given generic instructions stating that it can use a tool to browse the user’s shared files and draw on whatever seems relevant to the topic at hand. The security boundary is the access, not any instructions – especially not ones given in separate chats – because the imaginary AI robot is neither an entity existing in the real world nor even a definite and persistent character. It can thus be talked into anything.

I’ll admit to initially rolling my eyes at the LinkedIn post, but I actually can’t blame its author too much for treating ChatGPT like the sci-fi robot that it’s marketed as. I also can’t completely blame OpenAI, Anthropic, et al, for marketing these things this way, because the truth is really, really hard to get your head around. I don’t think any of us, not me, not the LinkedIn guy, or anyone else, have quite the right frame for engaging with LLM output. At least not yet.

# III

At the start of Embassytown, contact between humans and Ariekei has already begun to corrupt the truthful nature of Ariekei speech, as human Ambassadors are able to tell lies in their language. The Ariekei compete with each other to imitate humans and speak lies themselves. This, among other events in the novel, leads to widespread madness and ultimately a complete breakdown of the grounded nature of Ariekei speech. By the end, they are altered enough to tell lies and learn to communicate with normal human beings.

To risk mixing an overextended metaphor, I think that LLM-generated text is putting human beings through something similar. About a month ago, author Mark Lawrence ran a flash fiction competition which pitted established authors against ChatGPT 5 in the task of writing 350-word stories about demons. Eight stories were published and readers were tasked with guessing which ones were written by AI and rating each one’s overall quality. Per the results, most readers were no more accurate than chance about the AI authorship question, and the highest rated story was written by an AI. I’ve quoted it below:

The first time I saw the ‘demon’ it was leaning against the glass at the bus stop, idly licking the condensation as if tasting the air for secrets. No one else noticed. The city hurried past in wet coats and glowing headphones.

It wore a second-hand suit the colour of overripe plums, its cuffs frayed, its tie loosened like an afterthought. Its eyes were the red of brake lights caught in rain, the kind that linger in your vision long after you look away.

“Buy me a coffee,” it said, and the request was not a request.

We walked to the corner café. The demon ordered a flat white, stirred it three times clockwise, and drank half before speaking again.

“You are tired,” it said. “You are afraid. I can take one of those away.”

It smiled in a way that made the lights above us flicker.

I thought about the months behind me: the sleepless nights, the rent overdue, the inbox like a swelling tide. I thought about the way my reflection had begun to look like someone else’s face.

“What do you want?” I asked.

The demon traced a finger along the rim of its cup. “A name. Spoken aloud in the right place. That is all.”

I should have left. Instead, I asked, “Whose name?”

It told me. The syllables rolled across the table like marbles, impossible to hold on to, already slipping from my mind. My tongue ached to repeat them.

When I spoke the name, the café windows fogged over. Outside, the rain stopped in midair, each drop quivering as if listening.

The demon finished its coffee, left coins on the table, and stood.

“Thank you,” it said. “You will sleep tonight.”

I did. I woke to a city where the sirens did not sound, where the morning news showed an empty chair behind the President’s desk, where the air smelled faintly of plum skins and burnt sugar.

On the street, people were whispering, each voice carrying a name I could not quite remember.

On the one hand, phrases like “idly licking the condensation as if tasting the air for secrets” positively scream AI-generated to anyone who’s spent a bit of time playing around with generating fiction. But imagine reading this story in 2015. What would you make of it? There’s undeniably something evocative about it, and the strangeness of the details could just as well be a subtle message that you’re not quite putting together as total gibberish.

Until extremely recently, you could read a passage of text like this and know that it originated from a human mind. That’s no longer true. Just as language became unmoored from reality for the Ariekei, it has come unmoored from human consciousness for us. We require a new kind of scepticism to know how to treat the responses of the seemingly human imaginary AI robot.

Grounding the output with external sources (i.e. retrieval-augmented generation) helps to make responses more factual. Before most LLM platforms had web search built in, any question you asked the AI would get an answer from somewhere in its model weights. These would be highly confident and often wrong. Nowadays, you can have AI pull in search results and use those to inform its answers. But is it good at formulating search queries? Can it weigh the reliability of different sources? Is the subject you’re researching something that has high-quality, relevant online sources? Will whatever the AI is doing, the way its intelligence works, work for your field? These questions can be dealt with to some extent through prompt engineering, but nagging doubts remain, especially when talking about subjects you’re not well-versed in. And ultimately, you’re limited by the reach of the search engine and the availability of content online – but that at least is not an AI-specific problem.

AI has proven to be quite useful for programming because it has a very tight feedback loop with unambiguous failure states. A coding agent can generate some code, run it, then take in the results of the run, and make changes accordingly. Of course, it’s still very possible to get bugs from AI code, but the feedback loop will basically always produce something that compiles if you leave it long enough.

Continuing along this line of thinking, one can imagine a real-life LLM-powered robot constantly pulling in and reacting to sensory data. This is basically what the ChatGPT agent does, albeit in a virtual environment. This paper describes making a robot arm that pours coffee and decorates plates. Could a scaled-up version of this approach ground the LLM well enough to create something generally intelligent? You’d need, at the very least, insanely fast processing and a gargantuan context window. My intuition is that even then, you’d still have the slipperiness of LLM cognition – even this robot might still look at files it’s been given access to after an explicit instruction not to, given the right circumstances. A very human flaw, if we’re honest.

Current generation chatbots are not conscious – they have merely proven that an additional subset of what we call intelligence does not require consciousness. Before Deeper Blue beat Kasparov, we believed that chess mastery required human consciousness, and the same is true with Go and AlphaGo.

Would a scaled-up version of today’s chatbots, constantly fed with sensory data, be conscious? Maybe? I’m not sure. Now I’m just imagining my own sci-fi robot. And whether we get there or not, we need to learn how to read today’s word calculators.

Reply via email

Last month, I gave a talk on the exploitation of insecure Firebase applications with my Baserunner tool at BSides Joburg.

I first developed this tool while pentesting a Firebase app in 2021, and have used it in many similar assessments since. It’s essentially a database query tool. Given a Firebase configuration and user credentials, it can run the same Firestore, Realtime Database, and Storage Bucket queries as the legitimate application, without the artificial constraints of the front-end.

If you found this interesting, you may enjoy this list of further reading:

Introducing Baserunner: a tool for exploring and exploiting Firebase datastores

The release blogpost for Baserunner, which covers some of the same ground as the talk above.

Firebase: Google Cloud’s Evil Twin

A 2020 whitepaper from Brandon Evans at SANS on these kinds of attacks.

Firebase: Insecure by Default

A write-up by Aditya Saligrama on compromising a college social media app with Baserunner.

Dodging OAuth origin restrictions for Firebase spelunking

A blogpost about implementing Google OAuth login in Baserunner, also from Aditya Saligrama.

gaining access to anyones browser without them even visiting a website

A blogpost by xyzeva about a remote JavaScript code execution vulnerability in the Arc browser (CVE-2024-45489), caused by an insecure Firebase datastore. The researcher didn’t use Baserunner, but this is one of most interesting vulnerabilities caused by insecure Firebase storage.

As I mentioned towards the end of the talk, a social media application named Tea suffered a massive data breach the day before I presented. It was built on Firebase and used an insecure Storage Bucket to host users’ ID verification images and documents – Storage Buckets use the same rule engine as Cloud Firestore. This is grimly portentous in light of recent pushes for legislation in various countries aimed at compelling websites to verify user identities.

Reply via email

Another thing I have a nostalgic fondness for Troy is Steele’s Blogger Beware¹, a blogosphere-era website dedicated to humorous recaps of books in the Goosebumps series and its spin-offs. So, with apologies to Mr Steele, here’s a Blogger Beware-style review of Red Rain containing extensive spoilers.

Front Tagline: Suffer the little children…

Back Tagline: What do you do when evil enters your home?

Official Book Description:

Lea is in the wrong place at the wrong time. Trapped on an island during a terrible hurricane, she barely escapes alive.

Out of the carnage, two orphan boys appear – innocent, angelic and thrilled to be adopted by their new mother.

But these are no ordinary children. They bring the gift of death – and they want to share it with the whole town.

Brief Synopsis:

The story begins with a mysterious prologue in which the female protagonist, Lea, wanders across a beach after a hurricane. While she’s appreciating the debris and masses of dead starfish, blood begins to rain from the sky, per the book’s title. The blood rain parts and two young twin boys appear before her.

The first chapter skips back in time to show us Lea’s blog post about her arrival on the island of Le Chat Noire, somewhere off the coast of North Carolina. The island is known for being cursed, basically, and especially for being a place where “the living dead walk among the living.” She lands on the island and has a creepy encounter with an old lady in a tea shop who tells her about the aftermath of a hurricane in 1935, which she remembers from her childhood. Keeping in mind that this book was published in 2012, I still can’t decide whether that means she’d supposed to be suspiciously long-lived or just regularly long-lived. Our intrepid travel blogger does not pass judgement either way.

In order for the plot to happen, Lea has of course knowingly travelled to the island during hurricane season.

“Yes. My husband warned me not to come here in hurricane season,” I said, inhaling the bitter steam from the cup.

Mark is so sweet. He always wants me to stay home. But exploring my backyard would make for a dull travel blog, don’t you agree?

The next few chapters detail Lea’s stay on the island, alternating between blog posts and regular third-person prose for no good reason. She watches a ritual in which a group of men kill themselves by drinking poison and are then brought back to life by a priest chanting in French, and then, oops, it’s time to hide from the hurricane.

Here the perspective shifts to the male protagonist, Lea’s husband Mark, who is on a book tour near his home in New York. Before you can blame RL Stine for self-inserting too hard, it’s revealed that Mark is a child psychologist and his book, Kids Will Be Kids, is a non-fiction work about the benefits of light-touch parenting and being friends with your kids (Questionable Parenting). I’m still not sure whether that’s a fair description of Mark’s work, because it’s mostly described by its detractors and Mark doesn’t do a great job of defending it.

In case the graphic deaths by poison weren’t enough to remind us that this is a book for grown-ups, Mark’s narration comments extensively on the attractiveness of his 23-year-old personal assistant, Autumn.

Meanwhile, Lea hides from the hurricane in the house of the online friends she made researching the island. The roof falls in, landing on Lea, and she wakes up later with a bump on her head. After the hurricane passes, we’re treated to a few chapters of Lea walking through the destroyed island and noting the many gruesome deaths, including those of the owners of the hotel she had checked into.

Finally, in Chapter 15, we get an abbreviated version of the prologue, in which Lea meets the two mysterious twins who will drive the story’s actual main plot. This book would be about half as long if it didn’t feel the need to skip back in time so much.

The twins are described as angelic, blond twelve-year old boys with blue eyes who speak in a weird British/Irish accent with a lot of “boyo"s and “bruvver"s (perhaps inspired by Tangier Island). They explain that their home was destroyed and their family killed by the hurricane.

Lea immediately decides to adopt them and bring them home. She phones Mark and pushes past his disapproval. The chapter then switches perspective² to Samuel, one of the twins, having an ominous conversation with Daniel about Ikey, their friend who “isn’t pretty like us.” Samuel wants to bring Ikey along, but Daniel fears that it will jeopardise their chances of adoption. It is implied that Daniel kills Ikey by pushing him off the pier while Samuel isn’t looking, removing the only character in this whole book that I found remotely intriguing.

Perhaps because he’s writing an adult-oriented horror novel, Stine attempts to emulate Stephen King by having a lot of different viewpoint characters that make the novel far longer than it needs to be, with chapters often skipping back in time to play catch-up with different characters. The most egregious example is Andy Pavano, whose initial introduction is an elaborate setup for a fake-out chapter ending cliffhanger. I would have admired the audacity of that if he’d never reappeared, but instead we’re then treated to occasional chapters about his love life until he finally comes into legitimate contact with the main characters again.

Meanwhile, the twins have been officially adopted by Mark and Lea in a matter of days and are introduced to their new home and family: Mark and Lea’s 14 year old daughter Elena and 12 year old son Ira, and Mark’s sister Roz and her one year old son Axl. Mark has set up a room for the twins in the attic, but in another instance of Questionable Parenting, he and Lea are immediately persuaded by the twins to allow them to displace Roz and Axl in the guest house out back.

The twins’ antics escalate from there. They begin by stealing jewellery and wallets and soon enough they’re murdering people. Because of their uncanny ability to listen in on sensitive conversations (“how long have you been standing there?”) they quickly discover Mark’s antipathy to them and decide he needs to be framed for the murder of a man who comes over to tell him that the grant for his next book has been denied. A gory description of the man’s burned head and torn out windpipe follows. At this point, our policeman, Andy Pavano, actually becomes relevant to the plot, as he is sent to investigate the murder.

We’re led to believe that the twins used a blowtorch to commit the murder, but later find out that Samuel can shoot fiery lasers from his eyes. At low strength, the beams can be used by Daniel to hypnotise people through that creepy psychic link twins in these sorts of stories always have. At high strength, well, they burn things.

The story’s viewpoint rotates between Mark, Lea, Pavano, Elena, Ira and Samuel. The scenes from the children’s perspectives remind us what Stine is really comfortable with writing. If he’d pared this book down to just those parts and sanitised the gore a bit, it might have made a decent Goosebumps story.

Most of the rest of the book is gradual escalation. Daniel and Samuel hypnotise people and commit more murders to frame Mark for, Pavano investigates the murder, Lea gets really interested in death rituals, and Mark is seduced by and has sex with his young PA because this a mature book for adults. The adjective “creamy” is used eight times.

Eventually, Lea receives an email from her friend on the island containing black-and-white photos of Daniel and Samuel taken in 1935, letting her in on what the reader has known for hundreds of pages: the twins are evil living dead who hypnotised her into adopting them. This friend also explains that the twins are notorious on the island for being evil thieves, which she somehow failed to mention when she was warning Lea about adopting them.

This revelation comes too late to prevent the twins from executing their ultimate evil plan: hypnotise the neighbourhood’s children and take over their middle school. The novel’s climax has the school surrounded by police and worried parents and a whole lot of people getting their faces melted by Samuel’s eye beams. Perhaps the only reason this plot wasn’t used for Goosebumps is its uncomfortable evocation of school shootings.

Pavano gets a heroic moment of trying and failing to stop the twins, surviving with some severe burns. Mark, reappearing after being on the run from the police for the murders he was framed for, gets a more successful heroic moment, in which he bashes their heads together, knocking them out and successfully unhypnotising their victims. However, they manage to recover and slink off before they can be arrested.

But the Twist is:

In addition to the old photos of the twins, Lea received a more recent photo of herself being revived by the chanting island priest. She died when the roof fell in on her during the hurricane. She tells this to a disbelieving Mark during a meeting at the pier. They are then joined by the twins, who try to kill Mark.

After a chase and lot of new fires, Mark is cornered by the boys and Samuel’s laser eyes. Lea comes up behind them and hugs them, turning them to face her. In an admittedly striking final image, Samuel’s eye beams light her on fire, and the fire consumes all three of them.

But the Second Twist is:

Samuel taught baby Axl how to shoot fire from his eyes. Never mind that this completely contradicts the story’s established mythology. What kind of Goosebumps book would this be without a nonsensical last-page twist?

The Platonic Boy-Girl Relationship:

As this is a book for adults, Stine does away with this trope in favour of having Mark Sutter seduced by Autumn, his 23-year-old blonde PA, whose intestines disappear three quarters of the way through the novel.

Questionable Parenting:

Lea abducts two children from an island.

Memorable Cliffhanger Chapter Endings:

This is a sophisticated book for adults, so we have a three-chapter version:

Chapter 10: Lea is attacked by a crazy man on the island.

Chapter 11: Policeman Andy Pavano is introduced in a chapter that concludes with him knocking on Mark’s door and telling him that his wife has been killed.

Chapter 12: Whoops, Pavano had the wrong house, the message is for someone else!

The twist at the end of the book, that Lea actually was killed in the hurricane, makes this foreshadowing, I guess.

Great Prose Alert:

Somewhere in the back, a baby cried. Mark suddenly realized there were several babies on laps, swaddled like tiny mummies.

RL Stine Shows He is Down With Technology:

Lea’s blog can be found at Travel_Adventures.com, despite underscores not being allowed in domain names.³

Conclusions:

Going in, I expected this book would read like an elongated Goosebumps entry with adult elements like sex and violence. That turned out to be an entirely accurate prediction. Red Rain is not a good novel – I don’t think I would have finished it if I hadn’t read it on a flight. Every Goosebumps tic is on full display, from the extremely short chapters with extremely contrived cliff-hanger endings to the ridiculous similes to the cartoonish approach to history, mythology and, well, reality. Like many of the weaker Goosebumps books, it’s not scary so much as ridiculous. Unlike those books, it does not have the mercy of also being short.

Reply via email

Last year I celebrated this blog’s tenth anniversary, so this year’s retrospective post marks eleven. Since that last retrospective, my posts have mainly been spurred by two manic projects: doing increasingly complicated things with Hugo render hooks and doing 60% of Advent of Code 2024 using a different programming language for each challenge.¹ I also reviewed a bad movie and, mostly recently, covered the latest advances in AI image generation.

Though this year was not the most prolific in post count, the three AoC posts are all in the top five longest articles on this blog, so it’s been a prolific year in word count. I could have split those into fifteen posts rather than three, but that felt a bit spammy and would have overwhelmed other site content.

Speaking of other site content, it’s been a while since I looked over my most popular posts in one of these retrospectives. Here are the top ten in analytics-enabled views over last year, in ascending order this time:

# 10. Notes on contentEditable and HTML injection (2016)

Some web security musings, based on my accidental discovery that dragging text from elsewhere on a web page into a contentEditable block would preserve the formatting.

Try it now right here! It still works!

# 9. Product placement in memes (2018)

An exercise in (over)analysing funny pictures online and contemplating the existence of a very stealthy product placement campaign through images like this one:

Many of the references in this article are as dated as you’d think (remember Tide Pods?), but the paunchy boomer Wojak has had surprising staying power, though he appears to have lost his Monster Energy sponsorship at some point in the last seven years. He has also flattened in connotation — you don’t hear much about the “30-year-old boomer”, a prematurely aging elder Millenial who acts like his Baby Boomer forebears. Now the image is used to denote actual Baby Boomers, and even that is flattening out to just “old people”.

It would be flattering to think that this post made the list for insightful cultural commentary, but it’s probably just because of people searching for memes and hotlinking my images.

# 8. Text editors II: Acme (2015)

Not long after I started this blog, I had the notion that I would write a series on different text editors. I started with one on Vim, my primary editor for a couple of years at that point. The obvious choice for the second article would have been Emacs, but I wanted to throw everyone a curveball and so I wrote about Acme instead.

This is probably only in the top ten because it’s one of the very few online articles about the Acme text editor, which never saw the kind of community support that grew up around Vim and Emacs. It was a futuristic, mouse-driven editor from the 90s, part of Plan 9, a futuristic operating system from the 90s. As everyone still uses operating systems and editors from the 80s, its time has yet to come.

After this post, it took me five years to write something about Emacs, and it’s now been five years since that post. The great problem with this series is that I always go back to using Vim, which I still do most of my writing in. The series has been going on so long that I have a nascent post about Atom (RIP) in my drafts. I could probably do a post on VS Code or Cursor, but I don’t know that there’s much point in writing about the editor everyone already uses and its AI son.

# 7. The many (bad) interfaces of Substack (2024)

The most recent post on this list, a brief rant about how nice it would be if the Substack website had been designed as a platform for reading blogs, rather than an ersatz email inbox grafted to a Twitter clone grafted to a Telegram clone. I’m still kind of amazed that they found a way to apply my concept of toxic skeuomorphism to other digital interfaces.

# 6. Review: The King in Yellow (2015)

A good review that I still stand by. Read the first half of the book and leave the rest. There’s another compilation that only contains the good half.

# 5. Writing a LaTeX macro that takes a variable number of arguments (2016)

Previously seen on 2022’s list. I write a lot less LaTeX these days, and I don’t particularly miss it. Even when I wrote a lot of it, I usually found ways to do things in Lua instead. These days, I tend to reach for HTML and CSS when doing document rendering, despite their shortcomings for print. I’m watching Typst with some interest, but it’ll be a while before it reaches anything close to feature parity with more mature solutions.

# 4. Encrypting a second hard drive on Ubuntu (post-install) (2015)

Also on 2022’s list. It’s a useful tutorial and still works, as far as I’m aware.

# 3. Review: The General Zapped an Angel (2014)

The oldest post on this list and my first (non-backdated) book review. I would write it much differently today, and probably be more critical of the collection, but I still agree with the general thrust of the review.

Again, this article’s SEO probably benefits from the book’s relative obscurity. If it’s known for anything, it’s probably the cover art’s resemblance to the cover of a famous anime film.

Maybe Hideaki Anno saw the cover of this book in a library once and it stuck in his mind. Or maybe it’s just a wild coincidence.

# 2. Review: The Man from Earth: Holocene (2020)

I’m glad this is getting attention because I really want to save people from watching this terrible sequel to a wonderful film. I don’t think it’s been very widely reviewed, so again my blog benefits from being one of the few places you can read about this particular subject. If you must watch it despite my warnings, at least stop before the post-credits scene.

I don’t have many film reviews on this site, but they’re all negative. I suppose I should get around to reviewing a movie I actually like, if only to prove I don’t have it out for the medium as a whole.

# 1. GPU passthrough: gaming on Windows on Linux (2016)

I have a confession to make: at some point between writing the post linked above and the one you’re reading now, I built a new PC. On this new PC, I dual-boot Linux and Windows.

Largely, this is because I have more use for my dedicated GPU on Linux, between running AI models and playing the increasing number of games that run here natively. My old passthrough setup meant using my dedicated GPU exclusively on the Windows VM and my onboard GPU exclusively on the Linux host.

A setup that reflects how I want to use my computer today would require a way to switch between cards relatively seamlessly. I’d want to start Linux using my dedicated GPU. Then, I would want to have the GPU passed to the Windows VM when/if it was started up, with the host falling back to the onboard GPU – being able to use both computers simultaneously is what makes the setup superior to dual-booting. Finally, I’d want the dedicated GPU to return to the host’s control after I shut down the Windows VM.

Based on some things I’ve read and some configurations friends have shared with me, I think this is possible, or at least mostly possible. I just haven’t gotten around to actually implementing it. When I do, I’ll be publishing a new GPU passthrough article. If you’ve implemented anything like this, I’d appreciate a webmention or email from the controls at the bottom of this page.

Looking over this list, it’s clear that my most popular content is niche technical tutorials and niche media reviews. The 2010s are pretty well represented and the 2020s significantly less so, but my blogging cadence has been much slower this decade. I also haven’t really written tutorials in the same way – most of my recent technical posts are framed more as explorations or walkthroughs of something I did rather than instructions for doing that thing yourself. Worse for SEO perhaps, but it’s not like I’m serving ads.

The point of this blog has always been to write about things that interest me in a way that entertains and informs others. I think most of the posts above do that, and I hope to write many more, as the fancy takes me.

Reply via email

I ended my last post about AI image generation on the following note:

↗

DALL-E 3’s ability to create pleasant, mostly coherent images with plenty of fine detail from text prompts alone makes many of the Stable Diffusion techniques above feel like kludgey workarounds compensating for an inferior text-to-image core.

[…]

I think it’s also likely that OpenAI is leveraging the same secret sauce present in ChatGPT to understand prompts. As far as they’re concerned, generating pictures is a side-effect of the true goal: creating a machine that understands us.

Me in October 2023, Adventures in latent space

Eighteen months later, OpenAI has done it again: released a new text-to-image model that blows the competition out of the water and shows that the alpha in improved prompt adherence is far from exhausted.

The image generator has entered the public consciousness largely through a trend of converting memes, selfies, and historical photographs into pictures in the style of Studio Ghibli films, muppets, and South Park characters.¹

This general idea has been a perennially popular way of using AI, but the results have never looked this good. Many different approaches are available:

1. You can prompt for “X in the style of Y”.
2. You can prompt for “X in the style of Y” and use the picture you want to change as an input image.
3. You can prompt for “X in the style of Y”, using a specially fine-tuned model or LoRA.
4. You can prompt for “X in the style of Y”, use IPAdapter with a style reference and a content reference.
5. You can prompt for “X in the style of Y”, using a reference or style ControlNet.

Methods 1 and 2 have historically been very hit-and-miss. Methods 3 to 5 can be combined, but require a lot of fiddling with settings and patience with RNG. With GPT4o’s image generation, method 2 beats everything I’ve seen from any other model, local or otherwise. But style transfer is far from GPT4o image generation’s sole use.

You can make precise edits to images, and produce paragraphs of 99% correct text.

Prompt adherence is good enough to correctly compose an image from Scott Alexander’s 2022 stained glass challenge.

Generate a stained glass picture of a woman in a library with a raven on her shoulder with a key in its mouth

It also rises to the more recent challenges of creating an analogue clock with correct numbers and a full wine glass:

It’s possible to get images with transparent backgrounds:

Or recreate one image in the style of another:

Or combine the contents of three or more images in complex ways:

This result was not terribly satisfactory as the wine glass also didn’t stay full and the clock’s numbering suffered a little. I also hit a rate limit when generating it, which may be partially responsible for the horizontal truncation. Still, I’m amazed that this was possible just by uploading the three images and asking for the clock to go on the wall and the wine glass to go on the table. Good luck doing that in any other diffusion model without opening an image editor!

Most impressively, GPT4o can generate multiple images with consistent characters in a consistent style. It can actually create coherent comics in response to detailed prompts specifying what each panel should contain!

This last one is really fun – you can tell ChatGPT a story and it will illustrate it in real time.

In my previous post, I briefly mentioned how ChatGPT would expand and vary user-supplied image generation prompts before feeding them to DALL-E 3. This allowed for levels of context not possible in standalone generation workflows – the language model could and would use information from your chat history to generate its prompts. So you could say things like, “Generate an image of a man named Bob with a curled moustache and a bowler hat”, followed by, “Now show Bob with his pal Charlie, who has a beard and a chef’s hat”, rather than having to write the prompt from scratch each time. Or you could say, “Generate another one of those but leave out the bowler hat.”

GPT4o’s image generation compounds this advantage. Rather than being an external model tool that GPT knows how to interact with, it’s a fundamental part of the model itself. Image generation benefits from the concepts understood by the text generation part of the model.

But that’s not all! The title of this post references the fundamental difference between this image generation technique and the open and proprietary image models that have dominated the scene since DALL-E 2 – pixel space vs latent space. While DALL-E 2, Midjourney, Stable Diffusion, and most other image models use diffusion to generate images, this new model is autoregressive. This is actually an older approach to image generation, harking back to DALL-E 1, and a standard approach to text generation.

Diffusion models create images by starting with a canvas of random noise and repeatedly denoising it based on a text prompt. This means that the whole image is drawn at once, starting with blurry shapes that define the composition and progressing toward fine detail. This image from my first Stable Diffusion post gives an idea:

In contrast, autoregressive models generate images in batches of pixels, generally moving from the top-left to the bottom-right. Each patch is predicted with the context of the previous patches, just like how text generation works. You can see this at work in how gpt4o slowly draws images from top to bottom (occasionally getting stuck partway due to rate limits or emergent content violations).

What’s also interesting about this image is that the unrendered part looks a little like a very early-stage diffusion generation. There’s some speculation that 4o uses a combination of an autoregressive model and diffusion. This may explain why edited images always contain minor differences beyond the intended edit(s), as shown in a couple of outputs above.

OpenAI’s stuff is all proprietary and top secret for reasons of Safety™, so we don’t know exactly what they’re doing here, or exactly how they’ve made the autoregressive approach totally leapfrog diffusion for image generation.² We can speculate that this more sequential approach leads to 4o’s greater image coherence and relative lack of weird artefacts, extra limbs, and other problems that plague diffusion models. Or perhaps the output quality is more down to gains in prompt understanding brought about by the model’s multimodal nature. Notably, though, Gemini 2.5 and Grok 3 are also multimodal models with autoregressive image generation but do not achieve nearly the same output quality. Perhaps this comes down to model size or training data quality.

Whatever the case, the results speak for themselves. Workflows that previously required an SSD full of LoRAs, monstrous ComfyUI workflows, meticulous inpainting, and endless re-de-noising can now be accomplished in a chat. There is probably still some utility to these and other diffusion workflows – some parts of the robot comic above could benefit from inpainting, for example. And until 4o-level models become more widely accessible, diffusion remains the state of the art for local generation. Perhaps until Deepseek releases a new iteration of the Janus series.

Reply via email

Advent of Code is a yearly programming event. For the 2024 edition, I decided to complete each challenge in a different language. After trying a lot of different language paradigms over the last two parts of this series, from rules-based to functional to logic to array, this next part represents something of a comedown. All of the languages I used for these five days were some flavour of imperative, and most were languages I’ve used before.

2D grid puzzles are a recurring theme this year, and I took the opportunity to use some gamedev frameworks for a couple of the challenges below.

# Day 11: Rust

Challenge: iterate over a list according to a set of rules and see how long it gets.

This was a deceptively simple challenge. You’re given a starting list containing two integers and a set of three rules for producing a new list. Two of the rules increase the integer, and the other rule splits it into two elements.

I’ve been using Rust quite a bit lately for non-AoC reasons, so I had to fit it in somewhere and this seemed like as good a place as any. The first part of the challenge was a simple matter of implementing the rules as described, which Rust’s match statement was well-suited for.

    for _ in 0..blinks {
        let mut new_stones = Vec::new();
        
        for stone in stones {
            match stone {
                // 0 -> 1
                0 => {
                    new_stones.push(1);
                }
                // even-length number -> split in half
                n if n.to_string().len() % 2 == 0 => {
                    let s = stone.to_string();
                    let (first, second) = s.split_at(s.len() / 2);
                    new_stones.push(first.parse::<u64>().unwrap());
                    new_stones.push(second.parse::<u64>().unwrap());
                }
                // all else -> multiply by 2024
                _ => {
                    new_stones.push(stone * 2024);
                }
            }
        }
        stones = new_stones;
    }

    println!("{:?} stones", stones.len());

Full code for part 1 on GitHub.

The first part was simple and the second part was deceptive. All that was required in the second part was to up the iteration count from 25 to 75. However, while the code produced an answer for 25 iterations pretty much instantly, it was not up to task of doing 75 within any reasonable amount of memory or time.

The example input showed that some of the elements repeated, so the first change I made was to create a cache hash map that would store the next iteration for each number after calculating it.

    let mut cache: HashMap<u64, Vec<u64>> = HashMap::new();
    for _ in 0..blinks {
        let mut new_stones = Vec::new();
        
        for stone in stones {
            let mut added: Vec<u64> = Vec::new();

            match stone {
                // get from cache
                n if cache.contains_key(&n) => {
                    added.extend(cache[&n].clone());
                }
                // 0 -> 1
                0 => {
                    added.push(1);
                }
                // even-length number -> split in half
                n if n.to_string().len() % 2 == 0 => {
                    let s = stone.to_string();
                    let (first, second) = s.split_at(s.len() / 2);
                    added.push(first.parse::<u64>().unwrap());
                    added.push(second.parse::<u64>().unwrap());
                }
                // all else -> multiply by 2024
                _ => {
                    added.push(stone * 2024);
                }
            }
        }
        // add to stones
        for &n in &added {
            *stones.entry(n).or_insert(0) += count;
        }

        // add to cache
        if !cache.contains_key(&stone) {
            cache.insert(stone, added);
        }
    }

    println!("{:?} stones", stones.len());

This didn’t help all that much. I thought about the problem some more and realised that I would still end up building a really long list. Seeing as there were going to be a bunch of repeated elements, to the point where I was caching them, wouldn’t it make more sense to store the list as a hash map of unique elements with their counts? The order of the elements didn’t matter for either the iterations or the solution. So that’s what I did.

    for (stone, count) in old_stones {
            let mut added: Vec<u64> = Vec::new();

            match stone {
                // get from cache
                n if cache.contains_key(&n) => {
                    added.extend(cache[&n].clone());
                }
                // 0 -> 1
                0 => {
                    added.push(1);
                }
                // even-length number -> split in half
                n if n.to_string().len() % 2 == 0 => {
                    let s = stone.to_string();
                    let (first, second) = s.split_at(s.len() / 2);
                    added.push(first.parse::<u64>().unwrap());
                    added.push(second.parse::<u64>().unwrap());
                }
                // all else -> multiply by 2024
                _ => {
                    added.push(stone * 2024);
                }
            }

            // add to stones
            for &n in &added {
                *stones.entry(n).or_insert(0) += count;
            }

            // add to cache
            if !cache.contains_key(&stone) {
                cache.insert(stone, added);
            }
        }
    }

    println!("{:?} stones", stones.values().sum::<u64>());

This implementation produced a result for 75 iterations pretty much instantly.

Full code for part 2 on GitHub.

Closing thoughts: The first time I looked at Rust, I came away scratching my head at all the crazy symbols and blocks everywhere. “What the hell is &mut?” I asked. Having now spent some time going through the official tutorial, working with some Rust codebases, and asking Claude about the weirder-looking bits of syntax I encounter, I’ve come to a greater appreciation for the language. I’ve always been a big switch-case appreciator, so Rust’s match is something I like a lot. Having such expressive syntax and functional programming built-ins like map and fold in a fast, compiled language feels like cheating.

Rather than expecting the programmer to manage memory manually like in C or using a garbage collector like in a high-level language, Rust uses a concept called ownership to prevent memory bugs. Properly internalised, this should provide the speed of C with the safety of Java. My mental conception of it is still a bit fuzzy, so dealing with ownership largely consisted of asking Claude to do the correct referencing and dereferencing in my code.

# Day 12: C

Challenge: figure out the areas and perimeters of interlocking fields in a 2D grid.

After the previous day’s challenge, it was time to shake off all that rust (memory safety) and work in venerable old C.

Reading in the input file (a grid of characters) was a lot more manual than in higher-level languages, but it’s good to be reminded of such things now and then.

    // Read garden map
    rows = 0;
    cols = 0;
    char line[MAX_COLS];
    
    while (fgets(line, sizeof(line), file) && rows < MAX_ROWS) {
        // Remove newline if present
        size_t len = strlen(line);
        if (len > 0 && line[len-1] == '\n') {
            line[len-1] = '\0';
            len--;
        }
        
        // Skip empty lines
        if (len == 0) continue;
        
        // Set cols based on first line
        if (rows == 0) {
            cols = len;
        } else if (len != cols) {
            printf("Inconsistent line length at row %d\n. Expected %d, got %d", rows, cols, len);
            fclose(file);
            return 1;
        }
        
        for (size_t i = 0; i < len; i++) {
            garden[rows][i] = line[i];
        }
        garden[rows][len] = '\0';
        rows++;
    }

    fclose(file);

To calculate the areas and perimeters of interlocking fields, I did a depth-first search on the grid.

// DFS to calculate area and perimeter of a region
void calculate(int r, int c, char plant_type, int *area, int *perimeter, int *corners) {
    visited[r][c] = true;
    (*area)++;
    
    // Count perimeter edges
    for (int i = 0; i < 4; i++) {
        int nr = r + dr[i];
        int nc = c + dc[i];
        
        if (nr < 0 || nr >= rows || nc < 0 || nc >= cols || garden[nr][nc] != plant_type) {
            (*perimeter)++;
        } else if (!visited[nr][nc]) {
            calculate(nr, nc, plant_type, area, perimeter, corners);
        }
    }
}

The final result was the sum of the area times the perimeter of each region. So far, so simple.

For the second part of the challenge, it was necessary to figure out how many sides each region had.

AAA
AAA --> four sides
AAA

BBB
BBBB --> six sides
BBBB

Counting sides seemed kind of tricky. Counting corners was a lot easier, and would produce the same result, so I did that. The following function checks for corners by looking at the contents of the three cells around the target cell in each of the four cardinal directions.

// Count corners at a given cell
int count_corners(int r, int c, char plant_type) {
    int corners = 0;

    // Check if we have a corner in each of the 4 quadrants around this cell
    for (int i = 0; i < 4; i++) {
        // Get coordinates for the three cells we need to check
        int r1 = r + dr[i];
        int c1 = c + dc[i];
        int r2 = r + dr[(i+1)%4];
        int c2 = c + dc[(i+1)%4];
        int rd = r + dr[i] + dr[(i+1)%4];
        int cd = c + dc[i] + dc[(i+1)%4];


        // Inner corner if both adjacent cells are the same type
        // and the diagonal is different
        if (r1 >= 0 && r1 < rows && c1 >= 0 && c1 < cols && 
            r2 >= 0 && r2 < rows && c2 >= 0 && c2 < cols && 
            rd >= 0 && rd < rows && cd >= 0 && cd < cols &&
            garden[r1][c1] == plant_type &&
            garden[r2][c2] == plant_type &&
            garden[rd][cd] != plant_type) {
            corners++;
            continue;
        }
        
        // Outer corner if either adjacent cell is out of bounds or different type
        bool cell1_different = (r1 < 0 || r1 >= rows ||
            c1 < 0 || c1 >= cols || garden[r1][c1] != plant_type);
        bool cell2_different = (r2 < 0 || r2 >= rows ||
            c2 < 0 || c2 >= cols || garden[r2][c2] != plant_type);
        if (cell1_different && cell2_different) {
            corners++;
        }
    }
    return corners;
}

Full code on GitHub.

Closing thoughts: The only times when I really felt like I was writing in C was when I was checking for null bytes at the end of strings and passing pointers around. When working on the core of the puzzle, depth-first search and 2D grid navigation, I felt like I could have been working in just about any language. Which I suppose is further evidence of C’s long shadow.

# Day 13: Octave

Challenge: find the right moves to win the prizes in a bunch of claw machines.

For this challenge, each claw machine has a single prize and two buttons. Each button moves the claw some distance along the X and Y axes. Button A costs three tokens and B costs one. You need to figure out how many times to press each button to reach the prize with minimum expenditure. Some of the machines are broken and have no solution.

Think about it for a while and this challenge will reveal itself as a highschool algebra problem: each machine is a set of simultaneous equations. So this:

Button A: X+94, Y+34
Button B: X+22, Y+67
Prize: X=8400, Y=5400

Becomes this:

94a + 22b = 8400
34a + 67b = 5400

It therefore seemed appropriate to use a maths language. Matlab and Mathematica come most readily to mind, but both are proprietary and expensive, so I went with GNU Octave, a free and open-source mathematical language designed to be very similar to Matlab.

pkg load symbolic

% Open the file and read the entire content
fileID = fopen('input.txt', 'r');
fileContent = fread(fileID, '*char')';
% ^ unmatched ' is transpose -- necessary to read file as lines rather than columns
fclose(fileID);

% Split the content into blocks
blocks = strsplit(fileContent, '\n\n');

% Initialize sums for A and B
sumA = 0;
sumB = 0;

% Process each block
for i = 1:length(blocks)
    lines = strsplit(strtrim(blocks{i}), '\n');

    % Extract numbers from the strings
    buttonA_nums = sscanf(lines{1}, 'Button A: X+%d, Y+%d');
    buttonB_nums = sscanf(lines{2}, 'Button B: X+%d, Y+%d');
    prize_nums = sscanf(lines{3}, 'Prize: X=%d, Y=%d');

    % Build the equations
    syms A B
    eq1 = A*buttonA_nums(1) + B*buttonB_nums(1) == prize_nums(1);
    eq2 = A*buttonA_nums(2) + B*buttonB_nums(2) == prize_nums(2);

    % Solve the equations (hardest part of the challenge in one built-in function)
    sol = solve([eq1, eq2], [A, B]);

    % Discard non-integer solutions
    if mod(sol.A, 1) == 0
        sumA = sumA + double(sol.A);
    end
    if mod(sol.B, 1) == 0
        sumB = sumB + double(sol.B);
    end

end

% Display the summed results
disp(sumA*3 + sumB);

Full code for part 1 on GitHub.

The second part of the challenge, explicitly designed for people like me, required the addition of 10 000 000 000 000 (ten trillion) to each prize co-ordinate. This was enough to make all co-ordinates significantly larger than the largest 32-bit integer – Octave’s default integer type. After converting all of my numbers to int64, I got a bunch of precision errors. After a lot of fiddling with stubbornly broken code, I took a step back and asked what other ways there might be to solve simultaneous equations.

Cramer’s rule was not something I remembered from highschool algebra, but it was pretty simple to implement.

% Open the file and read the entire content
fileID = fopen('input.txt', 'r');
fileContent = fread(fileID, '*char')';
% ^ unmatched ' is transpose -- necessary to read file as lines rather than columns
fclose(fileID);

% Split the content into blocks
blocks = strsplit(fileContent, '\n\n');

% Initialize sums for A and B
sumA = int64(0);
sumB = int64(0);

% Process each block
for i = 1:length(blocks)
    lines = strsplit(strtrim(blocks{i}), '\n');

    % Extract numbers from the strings and convert to int64
    buttonA_nums = int64(sscanf(lines{1}, 'Button A: X+%d, Y+%d'));
    buttonB_nums = int64(sscanf(lines{2}, 'Button B: X+%d, Y+%d'));
    prize_nums = int64(sscanf(lines{3}, 'Prize: X=%d, Y=%d'));

    % Add the large number
    prize_nums = prize_nums + int64(10000000000000);

    % Build the Cramer equations
    a1 = buttonA_nums(1); a2 = buttonA_nums(2);
    b1 = buttonB_nums(1); b2 = buttonB_nums(2);
    c1 = prize_nums(1); c2 = prize_nums(2);

    % Calculate determinants
    D = a1 * b2 - a2 * b1;
    Dx = c1 * b2 - c2 * b1;
    Dy = a1 * c2 - a2 * c1;

    % Discard non-integer solutions
    if D ~= 0
        x = Dx / D;
        y = Dy / D;
        if mod(Dx, D) == 0 && mod(Dy, D) == 0
            sumA = sumA + x;
            sumB = sumB + y;
        end
    end
end

% Display the summed results
result = sumA * int64(3) + sumB;
disp(result);

Full code for part 2 on GitHub.

Closing thoughts: The choice of language really came through for solving this challenge, to the point where the first part was really just a matter of string parsing and calling solve. I suppose the real trick was to figure out that you needed to use simultaneous equations.

I found Octave fairly simple to use, but in the usual course I would probably just do this sort of thing in Python. Octave’s symbolic package, which I used for the first part of the challenge, is largely a wrapper for SymPy.

# Day 14: Lua & Love2D

Challenge: simulate guard robot movements.

Lua was one of the languages on my shortlist for this challenge. My main previous experience with it was writing LuaLaTeX in Overleaf to create dynamic document templates – aside from that, I’d occasionally tinkered with Love2D, a Lua-based gamedev framework. A challenge involving guard robots moving through a 2D grid seemed like a good opportunity to bring in not only Lua, but Love2D.

Implementing the guard simulation in Love2D was pretty straightforward, but to actually solve the challenge you need pretty discrete results – which robots are in which grid spaces at precise times. Love2D is geared to show fluid movement in real-time, and getting it to do otherwise made me feel like I was fighting with my code. So I retreated to a pure Lua solution based on the text grid.

local function moveGuards(guards, mapWidth, mapHeight)
    for _, guard in ipairs(guards) do
        guard.x = guard.x + guard.vx
        guard.y = guard.y + guard.vy
        -- wrap at the edges
        if guard.x < 1 then
            guard.x = guard.x + mapWidth
        elseif guard.x > mapWidth then
            guard.x = guard.x - mapWidth
        end
        if guard.y < 1 then
            guard.y = guard.y + mapHeight
        elseif guard.y > mapHeight then
            guard.y = guard.y - mapHeight
        end
    end
end

local function calculateSafety(guards, mapWidth, mapHeight)
    local quadrants = {0, 0, 0, 0}
    local centerX = math.ceil(mapWidth / 2)
    local centerY = math.ceil(mapHeight / 2)

    -- Count robots in each quadrant
    for _, guard in ipairs(guards) do
        -- Skip robots exactly on center lines
        if guard.x == centerX or guard.y == centerY then
            goto continue -- Lua has no continue statement
        end
        -- Count each quadrant
        if guard.y < centerY then
            if guard.x < centerX then
                quadrants[1] = quadrants[1] + 1  -- Top-left
            elseif guard.x > centerX then
                quadrants[2] = quadrants[2] + 1  -- Top-right
            end
        elseif guard.y > centerY then
            if guard.x < centerX then
                quadrants[3] = quadrants[3] + 1  -- Bottom-left
            elseif guard.x > centerX then
                quadrants[4] = quadrants[4] + 1  -- Bottom-right
            end
        end
        ::continue:: -- We jump here (poor man's continue)
    end

    return quadrants[1] * quadrants[2] * quadrants[3] * quadrants[4]
end

local file = io.open("input.txt", "r")

local guards = {}
for line in file:lines() do
    local startX, startY, vx, vy = line:match("p=(%d+),(%d+) v=(%-?%d+),(%-?%d+)")
    -- ^ I can't believe it's not regex!
    table.insert(guards, {
        x = tonumber(startX+1), -- +1 to account for Lua's 1-based indexing
        y = tonumber(startY+1), -- +1 to account for Lua's 1-based indexing
        vx = tonumber(vx),
        vy = tonumber(vy),
    })
end

file:close()

local mapWidth = 101
local mapHeight = 103

for i = 1, 100 do
    moveGuards(guards, mapWidth, mapHeight)
end

print(calculateSafety(guards, mapWidth, mapHeight))

A few notes:

• I learnt about Lua’s pattern matching during this challenge. It is not regex, as implementing regex in Lua would practically double the size of its codebase. Luckily, I didn’t need to do any complicated text parsing for this challenge. This cheatsheet was helpful.
• line:match is syntactic sugar for line.match(self,. I had also not previously used any of Lua’s OO capabilities.
• Lua 1-indexes everything (as does Octave).
• Lua does not have a continue keyword, so you have to use goto with a label. I am young enough that this maybe the third time I’ve ever written high-level code containing a goto.

Naturally, this code got me a result much quicker than my Love2D implementation.

Full code for part 1 on GitHub

The second part of the challenge comes totally out of left field: you have to find the smallest number of seconds it takes for the robots to arrange themselves in a Christmas tree pattern. I immediately had more questions, such as, should this be an actual tree or something vaguely in the shape of one? At any rate, solving this problem with my current implementation would require a function for visualising the map:

local function visualizeMap(guards, mapWidth, mapHeight)
    -- Initialize empty map
    local map = {}
    for y = 1, mapHeight do
        map[y] = {}
        for x = 1, mapWidth do
            map[y][x] = 0
        end
    end

    -- Count guards at each position
    for _, guard in ipairs(guards) do
        local x, y = math.floor(guard.x), math.floor(guard.y)
        map[y][x] = map[y][x] + 1
    end

    -- Create string representation
    local result = {}
    for y = 1, mapHeight do
        local row = {}
        for x = 1, mapWidth do
            row[x] = map[y][x] > 0 and tostring(map[y][x]) or "."
        end
        table.insert(result, table.concat(row))
    end

    return table.concat(result, "\n")
end

I didn’t have any idea what the eventual tree would look like, so I didn’t really want to try writing code to detect shapes in guard positions. Luckily, I still had my abandoned Love2D implementation, which I could start up and just watch for patterns.

I soon noticed that the guards would periodically swarm to the vertical or horizontal center line of the map. As these lines were left out of the safety factor calculation, this meant that such a swarm would have to coincide with a low safety factor. Also it would make sense for the Christmas tree to appear in the middle of the map.

Initially, I tried looking for the lowest possible safety factor in a hundred, then one thousand, then ten thousand seconds. Although I could lie to myself that some of these outputs looked vaguely like Christmas trees, none were the correct answer. So I loosened my threshold a bit, and looked for outputs with safety factors lower than the first one I found, at the first second I’d noticed the middle convergence.

A few results down, I saw this, right in the centre of the map:

1111111111111111111111111111111
1.............................1
1.............................1
1.............................1
1.............................1
1..............1..............1
1.............111.............1
1............11111............1
1...........1111111...........1
1..........111111111..........1
1............11111............1
1...........1111111...........1
1..........111111111..........1
1.........11111111111.........1
1........1111111111111........1
1..........111111111..........1
1.........11111111111.........1
1........1111111111111........1
1.......111111111111111.......1
1......11111111111111111......1
1........1111111111111........1
1.......111111111111111.......1
1......11111111111111111......1
1.....1111111111111111111.....1
1....111111111111111111111....1
1.............111.............1
1.............111.............1
1.............111.............1
1.............................1
1.............................1
1.............................1
1.............................1
1111111111111111111111111111111

As we can see, none of the guards overlap in this pattern. That would probably also be a good heuristic for finding the Christmas tree, but I haven’t implemented it.

Full code for part 2 on GitHub.

After implementing some time manipulation functionality in my Love2D code, I managed to snap a screenshot of it as well.

Full code for Love2D version on GitHub.

Closing thoughts: I think if I could get used to 1-indexing, I’d probably prefer it to 0-indexing. Sacrilege, I know. Lua is a great little language and I’m glad I used this opportunity to get a bit more experience with it and learn about things like its pattern-matching functionality.

Love2D is great fun, and I’m glad that my failed Love2D implementation of the first part of the challenge turned out to be useful for the second part.

# Day 15: JavaScript & KaPlay

Challenge: figure out where a malfunctioning robot will push boxes in a warehouse.

The challenge here was to build a self-playing sokoban game, making it the challenge most perfectly suited so far to a gamedev framework.¹

Initially, I thought about using PuzzleScript, a gamedev tool with a terse, rule-based language explicitly geared to the creation of sokoban-alikes. Half of the logic for the first part of this challenge is already implemented in the sample game, in a single line of code:

[ > Player | Crate ] -> [ > Player | > Crate ]

Translation: if player steps towards a crate, move both the player and the crate. To complete the logic, we just need to make crates push each other, which we can do with another very simple rule:

[ > Crate | Crate ] -> [ > Crate | > Crate ]

However, getting a result out of a PuzzleScript game would require some external method of:

1. Moving the player according to a preset list of moves.
2. Calculating and adding the positions of all the crates together.

This seemed like a lot more trouble than it was worth, even in the context of this self-imposed challenge. So I opted instead to write my self-playing sokoban game in JavaScript, using KaPlay, a lightweight and intuitive gamedev library I have a bit of prior experience with. KaPlay also happens to have functionality for storing levels as ASCII grids, making it well suited to AoC.

After creating a new project, loading up some sprites and making a sample level using 16x16 grid spaces – keeping them small to (semi-)accomodate the large challenge input – I got to work with my implementation. Initially, I wrote a bunch of code for predicting which object(s) the player would collide with when moving in some direction, converting between real positions and grid positions, but then I realised that at some point since I last used it, KaPlay had added the method level.getAt which did all of this for me. That allowed me to implemented the movement and crate-pushing code in a few recursive functions.

    // Base movement function
    const move = (obj, dir) => {
        if (dir.x == 1) obj.moveRight();
        if (dir.x == -1) obj.moveLeft();
        if (dir.y == 1) obj.moveDown();
        if (dir.y == -1) obj.moveUp();
    };

    // Crate movement
    const moveCrate = (crate, dir) => {
        const crateMoveTo = crate.tilePos.add(dir);
        const crateDisplaced = level.getAt(crateMoveTo)[0];
        // ^ multiple objects could occupy the same grid space
        // but that shouldn't happen in this game

        // Moving into empty space: success
        if (crateDisplaced === undefined) {
            move(crate, dir);
            return true;
        }

        // Moving into a wall: failure
        if (crateDisplaced.is("wall")) {
            return false;
        }

        // Moving into another crate: pass the buck
        if (crateDisplaced.is("crate")) {
            const nextCrate = crateDisplaced;
            if (moveCrate(nextCrate, dir)) {
                move(crate, dir);
                return true;
            }
            return false;
        }
    }

    // Player movement
    const movePlayer = (dir) => {
        const moveTo = player.tilePos.add(dir);
        const displaced = level.getAt(moveTo)[0];

        // Moving into empty space
        if (displaced === undefined) {
            move(player, dir);
            return;
        }

        // Moving into a wall, cancel movement
        if (displaced.is("wall")) {
            return;
        }

        // Moving into a crate, try to push the crate
        if (displaced.is("crate")) {
            const crate = displaced;
            if (!moveCrate(crate, dir)) {
                return;
            }
        }

        // If we haven't returned yet, we can move
        move(player, dir);
    };

For testing, and to make it a real game, I bound movement to the arrow keys. I then implemented autoplay in two ways. Press Space, and all moves will be processed at once, changing the map and producing the answer in the blink of an eye. Press Enter, and you can watch the robot go through the moves one at a time.

For the second part of the challenge, everything except the player/robot doubled in width, taking up two grid spaces. At this point, I regretted using GML back on day four, as GameMaker’s collision and grid functions are robust enough to handle this kind of thing with ease. Had I implemented part one in GameMaker, I would likely only have to have changed the width of the crates to get part two working as well.

However, I implemented it in KaPlay. And KaPlay’s level/tile system does not explicitly cater for double-wide objects. I would either have forgo a lot of the tile functionality or work with left and right crate halves, which would need to be manually kept together.

I chose to keep the very useful grid methods and represent each crate as left and right halves, which meant having to keep halves together. Due to the cascading push already implemented for the first part, horizontally pushing two separate crates positioned next to each other was functionally the same as pushing two linked crates. It was when crates had to be pushed vertically that I actually needed new code to keep halves together.

I tried a few different tweaks to my recursive code above, but couldn’t resolve this edge-case:

Annoyingly, this edge-case was not present in the example map, but did appear in my challenge input. All of the recursive methods I tried were just too eager to move boxes. I needed to change to something that would cancel the whole move as soon as one push failed.

So, taking a leaf from challenges 10 and 12, I rewrote the code to build up an array of things to move using a depth-first search.

    const movePlayer = (dir) => {
        const moveTo = player.tilePos.add(dir);
        let displaced = level.getAt(moveTo)[0];

        // empty space, go there
        if (displaced === undefined) {
            move(player, dir);
            return;
        }

        // wall, don't go there
        if (displaced.is("wall")) {
            return;
        }

        // not empty space or wall, must be a crate
        // let's build a stack of crates in our way
        let cratesToMove = new Set();
        let stack = [displaced];
        while(stack.length > 0) {
            let next = stack.pop();
            if (next) {
                if (next.is("wall")) return; // found a wall, cancel everything
                if (next.is("crate")) {
                    // add to crates to move
                    cratesToMove.add(next);
                    // add to displacement checking stack
                    stack.push(level.getAt(next.tilePos.add(dir))[0]);
                }
                if (dir.y != 0) { // special rules for vertical movement
                    // partner crate must also be able to move
                    if (next.is("left")) {
                        let partner = level.getAt(next.tilePos.add(vec2(1, 0)))[0]
                        cratesToMove.add(partner);
                        stack.push(level.getAt(partner.tilePos.add(dir))[0]);
                    }
                    if (next.is("right")) {
                        let partner = level.getAt(next.tilePos.add(vec2(-1, 0)))[0]
                        cratesToMove.add(partner);
                        stack.push(level.getAt(partner.tilePos.add(dir))[0]);
                    }
                }
            }
        }
        // move everything that needs to move
        for (const crate of cratesToMove) {
            move(crate, dir);
        }
        move(player, dir);
    };

What I’m happiest about with this code is that it works just as well for single and double-sized crates, and thus works as a solution for both parts of the challenge. It would also work on a map including a mix of single and double crates. To facilitate solving this part two, I added an upsize checkbox to the functionality that loads levels from files, and that’s all I needed.

Full code on GitHub

Closing thoughts: I have never been the biggest fan of JavaScript, but it’s one of those languages that you pretty much have no choice but to use in a lot of domains. As a result, I’m very comfortable with it, which has not been the case for most of what I’ve used for these challenges. KaPlay is a great little library and one I’d like to use for a proper game in the future.

As may be evident from the date of this compared to previous posts, I’ve slowed down with this project a little. Write-ups for the remaining ten days of AoC 2024 will be posted eventually, probably with some other posts in between. I feel like I played it quite safe with the language choices for this selection of challenges, so I’m looking forward to trying some weirder ones in the next post.

Reply via email