Brent Fitzgerald

How many cookies does the GPU eat?

2026-10-04T21:30:00Z

One of the inference providers in my rotation charges for measured energy instead of tokens. I wanted to see the energy numbers next to the costs, so I wrote a small pi-neuralwatt extension for my harness of choice, Pi. I used it three months and recently looked at what it had recorded.

And I also overdid it, as usual. So we now have a live measure of whatever unit we want. We can answer the question we’ve all been too afraid to ask: How many cookies would need to be eaten by a fictional cookie-powered GPU to run our little agentic coding sessions.

Whether you find this dumb or fun depends on your definitions of those words.

Chocolate chip cookie consumption

Neuralwatt

I have no affiliation with Neuralwatt. My interest is mostly just that I found it intriguing as a preview of a commodified inference economy where the cost of electricity dictates what we can do and afford.

The pay-as-you-go rate is currently $10/kWh. For reference, my home electricity peaks at $0.52/kWh, which is absurdly expensive compared to most of the U.S. but still only 5% of this inference rate. But I’m not really buying any old electrons. I’m paying for GPU time with an energy meter.

The methodology docs say they read GPU power counters through NVML, which is (I learned) a library for reading stuff like power usage and utilization from NVIDIA GPUs. Then they give each request a share of the server’s measured energy based on its share of tokens in flight, up to a cap. So my energy use presumably depends partly on who/what else is using the GPUs.

The pricing only counts (as far as I can tell) GPU inference. No cooling, host CPU, or networking. So the numbers are a floor. When Google measured the full picture for a Gemini prompt, the AI chips themselves were only a bit over half the total. The rest was the supporting computers, spare machines, and cooling. And obviously the energy costs of training the models are not reflected here.

I’m no expert in data center energy, so I’m trusting Neuralwatt’s numbers to be accurate-ish. And I’m not making any big decisions based on this stuff. Just little decisions. About cookies.

Three months of records

The extension records every Neuralwatt response. Earlier versions didn’t track everything perfectly, so the older records are rough, but I had the energy numbers. Between July and early October I had over 5,500 responses. It was mostly deepseek and glm coding.

A typical response used about 0.2 Wh. This is about a minute of a 10 W LED bulb.
A typical real working session (say, enough back and forth to land a PR) used about 12 Wh, or 12 cents at pay-as-you-go rates.
My biggest feature used about 250 Wh. It involved building a whole revision management system with a novel interface, auth changes, etc.
All of it together came to about 3 kWh. That’s probably 10-12 miles in an electric car I guess? I don’t have an electric car, but it would fully discharge my RAV4 hybrid’s little battery twice.

0.2 Wh is right in the range of published estimates for a single chatbot prompt (Google says 0.24 Wh for a median Gemini text prompt, all-in). I’d assumed agentic coding would be much worse, since every turn resends the whole conversation. In my sessions the median context was about 70,000 tokens. So caching is where the efficiency comes from. About 98% of my input tokens were cache reads, which are cheap. Agents mostly read a lot and write a little. An output token cost something like 50 times as much energy as a new input token.

Still, the context costs add up. Energy per response grew as sessions went on. The first few turns of a session used about 0.06 Wh each. After turn 50 it was closer to 0.3 Wh. Another reason to start fresh sessions often.

But you’re not here for the watts per hour. You’re here for the cookies.

This extention shows everyday equivalents next to the energy number. You pick them in /neuralwatt:settings, or even add new ones. Some of the defaults are power draws (a 20 W human brain, a 10 W LED bulb) and show how long that thing could run. Others are units (calories, cookies) and show a quantity.

Choose your units wisely.

The default cookie option assumes one chocolate chip cookie is 150 calories, about 174 Wh. It’s editable if you prefer very large or small cookies. My sized cookie of GPU energy costs about $1.74 at pay-as-you-go rates. Cheaper than local bakery cookies!

So, at least for me, a normal PR cost about 7% of a cookie. My entire three months cost 17 cookies. That is less than I’ve actually eaten in the same period.

Of course this is one person using some smallish open models. It says nothing about training, or the data centers going up, or everyone else’s requests added together. Maybe the frontier lab secret models eat hundreds of cookies per hour? We’ll never know.

Brainpower

The brain preset turned out to be another fun one. A brain runs on about 20 W of metabolic power, so 1 Wh is roughly 3 minutes of brain.

My typical 12 Wh session works out to about 35 minutes of brain. Which is how long I’d expect a person to spend focusing on a small task like that. A patient, tireless, focused person. My whole three months of GPU energy is about 150 hours of brain.

A brain typically needs a body, a laptop, a monitor, a commute. Still, I feel it’s a useful check. For this kind of work, the energy the GPU used was not wildly different than the energy of the person sitting there vibing out.

So, the extension

I first threw together a version of this extension a few months ago, and there were already two others. A third popped up at some point as well.

aliou/pi-neuralwatt pairs the provider with a tabbed /neuralwatt:quota command, low-quota warnings, and status-bar usage. This is what I initially used.
tedewaard/pi-neuralwatt adds energy and quota reports and a toggleable status-bar widget.
monotykamary/pi-neuralwatt-provider is more recent and has a lot, including provider setup, an energy and cost widget below the editor, quota display, flex and fast variants, and hosted-tool support.

Mine isn’t remarkably different! My main focus was the per-response energy telemetry Neuralwatt adds to the response stream. Alongside the usual SSE data: chunks, there are comment lines: : energy {...} and : cost {...}. The cost is the reported request cost in dollars, and the energy is reported GPU energy in kWh. A typical client parses the data events and never sees the comments. So like a few of the others, this extension tees the response body and reads the comment lines.

Tree vs session

One thing I hadn’t thought much about prior to digging in: Pi’s footer sums cost across the whole append-only session file. But a conversation is a tree. Rewind a few responses or fork the thread, and the abandoned branch is still in that file.

The extension has its own totals, rebuilt from the active branch, so a rewind does not include the abandoned turns. The footer and the ⚡️ indicator can disagree. When they do, the indicator is showing the branch you’re actually on.

Extension hygiene

A few choices to keep the extension from being too invasive:

Settings live in a plain JSON file, and auth goes through Pi’s normal credential handling rather than a custom store.
Stream interception is scoped to the extension’s own requests, so global fetch is never patched and other providers are unaffected.
The records are custom session entries that never enter model context.
Cost patching uses Pi’s public message_end replacement and leaves the footer in place.

It counts responses it actually saw, so retries, background compaction, and anything elsewhere may be missing. The README has details.

What other kinds of costs could we measure?

While I don’t have a stake in energy pricing specifically, I appreciate seeing what our AI future costs in units other than plain old money.

Neuralwatt was already calculating CO2 emissions equivalents based on location, via Electricity Maps. Energy turns out to be a pretty good common unit for reasoning about real world costs. I wonder what else we could convert it into to better show the externalities?

And I can’t help but ponder measuring other costs we associate with this technology, like cumulative hours of intellectual labor that went into the response.

But I’ve written enough about my little extension and inference costs. Perhaps I deserve a cookie.

Actually, if I were to pay back those three months by pedaling a generator, with human muscles at roughly 22% efficiency, I’d need to eat 77 cookies.

The human is the loop

2026-08-12T00:30:00Z

I recently stepped away from AI for a few weeks. Coming back, I’m more aware of the unhealthy habits I’d formed using it.

It was an end-of-summer vacation, and I was lucky to be swimming in cold rivers, eating one too many s’mores, napping after lunch, etc. There was a lot of indulgence and a break from work and routines. For much of the time it was a break from my laptop and phone altogether, which meant a few weeks without AI.

I didn’t miss it. What I’ve realized these past few days back is how much of my AI use was unnecessary. In fact, I think it’s often been a habit-forming crutch making me intellectually weaker, less curious, and less confident. It’s probably made me a little depressed too.

When I eventually opened my laptop a few days ago, I was greeted with eleven cmux tabs, each with multiple agents paused midway through various efforts. Some professional, some personal, and a lot in between. I also had unread badges on Claude chats across everything from taxes to landscaping ideas to policy doc review.

Is this the 2026 version of having a bunch of tabs open? Maybe, but it feels way worse. Each of these was an initiative I thought I needed help with, or that I wanted to automate or outsource some thinking on. But each is also a little stub of guilt over never finishing things, over not being efficient or smart or focused enough with my time.

Obviously I’m being hard on myself. That’s not new behavior, and it’s long been a source of pressure based on unrealistic expectations. I’ve managed that stress and self pressure with mixed success in the past. But in this machine intelligence era, the pressure has found new outlets. Instead of forcing me to triage and focus on what matters most in work and life, it feeds an underexamined belief that I should be able to do more now. And it finds release in yet another agent conversation, another terminal pane, another fork no one asked for, another bullshit markdown output I’ll never read.

I have so many half-baked ideas for tools or services I barely need, sparked by a combo of unaddressed workaholism and techno-optimist wishful thinking. And sure, the little things I’ve made do work. They’re running, doing their little things. But none of it helps anyone, and none of it makes me happier or gives me more free time. I used to tinker on personal projects as a way of relaxing and learning for the fun of it. These projects don’t do that. I often skip the learning to get to the result, and the learning is where the joy happens.

I also think I have been using agents as a layer between me and the tasks that cause me stress. Instead of just taking on the thing directly, I put an agent in the mix. It’s like a special stuffy or totem that protects me.

If I needed to write something, I’d dictate all my thoughts, then talk through it with ChatGPT while driving or walking. I’d justify it as bouncing ideas around with myself, as making use of time that would otherwise not be productive. But I knew it was really a sycophantic mirror. And because it was not a realistic thought partner, I never relied on the output of those sessions for real work. So how useful were all those hours really? Now it’s just rambling recordings and transcripts on OpenAI’s servers.

Another example: I’d try to set things up to be more automatic, so I could theoretically get work done faster and parallelize a bunch of different tasks at once. But in hindsight, no one was asking for these efficiency gains. Equipped with tools that could theoretically make me a faster, more capable builder, I felt a strong urge to maximize my use of the tools by applying them to the task of… maximizing my use of the tools. It’s reflexive in the worst way, a productivity ouroboros.

I’m not arguing that this technology necessarily has these effects on its users. And I think the format, design, and culture around the tech are a huge factor in the habits I formed.

My hunch is that agent usage is (thankfully) not intrinsically neurochemically addictive in the same way as, say, endless algo feed scrolling. But I do see now that there are some very real dependency and habituation effects. Once you introduce AI tools into some of your work, it’s quick to see more ways you might start incorporating them. There’s also a large segment of the tech industry now betting on a mass socioeconomic dependency on LLMs. The only way those valuations are ever justified is if we collectively become hopelessly dependent on AI-based tech.

So my plan going forward is simple: be intentional about when to use AI and when to leave it out, and try to be honest about what I’m actually gaining and losing with my choices.

Before switching to writing this post, I did enter a prompt into pi for a work project I’m starting. I gave it a bunch of requirements and suggestions, and told it to look at codebases, wikis, schemas, conversations. Setting it up forced me to catch up and think through the current situation. I asked it to come back with flagged issues and possible solutions. I constrained it narrowly and gave it as much context as I could, including what I was already thinking and what I wasn’t sure about. And I provided very clear expectations of output.

The AI isn’t going to hand me the perfect solution. The result is not going to 10x me. But it’s pattern matching and searching across a mess of systems and SaaS products, which I’m not great at and don’t enjoy. It might reveal a few gaps in my understanding of the situation and improve the context I bring into the project.

More important: it’s freeing me up to do human stuff like write and reflect right now. I’m still cautiously optimistic about this tech possibly letting people lead richer, more thoughtful lives. But that’s only possible if we use it on our terms. We don’t want the human trapped in the agent loop. The human is the loop, and we tag the agent in occasionally, thoughtfully.

Appreciating Exif

2026-06-09T19:00:00Z

I recently was writing some code to apply a mask to an image input. The mask had no Exif metadata, but the image did, so I had to adjust for the orientation of the image by reading it from Exif.

This isn’t hard with libraries, and I knew the gist of the problem: images can have Exif, Exif is optional, phones and cameras use it for orientation, and you need to account for that when processing pixels directly. But I did not have a clear mental model of how Exif actually is represented in files.

I was curious. I had questions:

Where exactly is that orientation value stored? When should I rotate pixels instead of preserving a tag? What else might be hiding in the metadata? When is it typically stripped?

So this is a little random walk guide to Exif.

What is Exif?

Exif is short for Exchangeable Image File Format. The current standard comes from CIPA, which lists it as “Exchangeable image file format for digital still cameras: Exif Version 3.1.”¹ The Library of Congress has a good preservation-oriented summary, too. You’ll often see EXIF in all caps in camera docs, file-format chunk names, and old forum posts, but Exif seems to be the normal spelling in the standard itself.

It is a metadata format that came out of the digital camera world in 1995, back when the problem was something like: this camera produced a JPEG, but where do we put the timestamp, shutter speed, aperture, focal length, thumbnail, and the fact that the camera was sideways?

The answer was Exif.

Most people run into this data through images from phones and cameras. It is also closely related to TIFF, because the actual Exif payload is a TIFF-shaped data structure living inside another file. Newer formats can carry Exif too, but each format gives it a different house.²

It’s optional. An image can have none. A camera image probably has some, but a processed image may have had it stripped. A synthetic image can have fake Exif because metadata is just data someone wrote into the file.

Where it lives

For JPEG, Exif usually lives near the beginning of the file in an APP1 marker segment.

A JPEG starts with two bytes:

FF D8

That is the start-of-image marker. After that, a JPEG is a series of marker segments. Each segment starts with FF and a marker byte. APP1 is:

FF E1

If that APP1 segment contains Exif, its payload starts with:

45 78 69 66 00 00

or, as text:

Exif\0\0

Then comes the TIFF-based part. It starts with a byte order marker:

II  // Intel, little-endian
MM  // Motorola, big-endian

Then the TIFF magic number, 42, then an offset to the first Image File Directory, usually called IFD0. An IFD is a list of entries. Each entry has a tag id, a type, a count, and either a value or an offset to the value.

Exif orientation is tag 0x0112. It is usually in IFD0. Its value is a small integer from 1 to 8.

That is the whole trick at a very high level. A tool looking for Exif in a JPEG:

walks the JPEG markers to find APP1,
checks for Exif\0\0,
reads the TIFF header,
follows the IFD entries, and
looks for the tags it cares about.

So the “where is Exif?” depends on the file. In JPEG, it is usually APP1. In WebP, it is an EXIF chunk. In HEIC, it is inside the HEIF box structure. If you want a lovely older walkthrough of the JPEG layout, the MIT Media Lab’s Deep View project has one.

A boring standard that aged well

I have a soft spot for simple standards that just keep working.

Exif is not clean in the way you might design something from scratch today. It has TIFF internals. It has manufacturer MakerNotes. It has duplicate concepts across Exif, XMP, IPTC, ICC profiles, C2PA, and container metadata. The orientation tag feels simple until you try to explain values 5 and 7.

It has continued to solve a real problem, though: pixels are not enough. A camera needs somewhere to put the circumstances of the image, and it’s simpler for everyone if that data is bundled into the image rather than shipped around as an accompanying file.

I admire it because it grew out of its initial container. In JPEG, Exif usually sits in APP1. In newer file formats like HEIC, it lives somewhere else. But the same payload format still applies. A phone in 2026 can take a photo in a modern container and still carry metadata shaped by decisions from the digital camera era.

What Exif is used for

The common stuff is what you would expect from a camera:

date and time
camera make and model
lens model
shutter speed
aperture
ISO
focal length
flash
GPS location
orientation
software
color-space hints
manufacturer-specific MakerNotes

Thumbnails are a “maybe”: Exif can carry an embedded thumbnail, usually in IFD1.³ It commonly is a small embedded thumbnail. Larger previews are messier. Some are Exif thumbnails, some are MakerNotes, some are MPF data, and some live in container-specific metadata.

This is not everything. It is the usual useful slice. Photo apps use this data to sort, search, display, group, and edit images. Websites and upload pipelines use it, sometimes accidentally, to rotate images correctly. Photographers use it to inspect how a shot was made. Asset-management systems use it alongside other metadata standards for rights, captions, credits, and workflow state.

Color is a good example of boundaries blurring. Exif has a ColorSpace tag, but full ICC color profiles are a separate kind of metadata.⁴ If an image changed size, rotated, lost its color, or started displaying differently after a pipeline step, metadata is one of the first places I would look, but I would not assume the answer is specifically Exif.

And of course, metadata is just whatever was put in the file. A file can say it came from a camera it did not come from. Timestamp can be wrong, GPS can be fake, a string field can contain gobblygook.

Use exiftool first

If you are doing anything technical with image metadata, start with exiftool.

It is Perl and is old in the very good way. It has baked into it all sorts of knowledge about metadata weirdnesses that exist in real files.

The basic command is:

exiftool image.jpg

Here is the top of a real iPhone JPEG:

ExifTool Version Number         : 13.55
File Name                       : image.jpg
Directory                       : /tmp
File Size                       : 3.6 MB
File Type                       : JPEG
File Type Extension             : jpg
MIME Type                       : image/jpeg
JFIF Version                    : 1.01
Exif Byte Order                 : Big-endian (Motorola, MM)
Make                            : Apple
Camera Model Name               : iPhone 13
Orientation                     : Rotate 90 CW
X Resolution                    : 72
Y Resolution                    : 72
Resolution Unit                 : inches
Software                        : 26.3.1
Modify Date                     : 2026:04:21 20:05:42
Host Computer                   : iPhone 13
Exposure Time                   : 1/317
F Number                        : 1.6
Exposure Program                : Program AE
ISO                             : 50
Exif Version                    : 0232
Date/Time Original              : 2026:04:21 20:05:42
Create Date                     : 2026:04:21 20:05:42

And that is just the start. The full output keeps going: MakerNotes, GPS, an embedded thumbnail, MPF data, and an ICC profile.

For debugging, it’s nice to have groups and raw-ish tag names:

exiftool -a -G1 -s image.jpg

An excerpt from the same file looks like this:

[File]          ExifByteOrder                   : Big-endian (Motorola, MM)
[File]          ImageWidth                      : 4032
[File]          ImageHeight                     : 3024
[JFIF]          XResolution                     : 300
[JFIF]          YResolution                     : 300
[IFD0]          Make                            : Apple
[IFD0]          Model                           : iPhone 13
[IFD0]          Orientation                     : Rotate 90 CW
[IFD0]          XResolution                     : 72
[IFD0]          YResolution                     : 72
[ExifIFD]       ExposureTime                    : 1/317
[ExifIFD]       FNumber                         : 1.6
[ExifIFD]       ISO                             : 50
[ExifIFD]       DateTimeOriginal                : 2026:04:21 20:05:42
[ExifIFD]       FocalLength                     : 5.1 mm
[ExifIFD]       LensModel                       : iPhone 13 back dual wide camera 5.1mm f/1.6
[Apple]         MakerNoteVersion                : 16
[Apple]         AccelerationVector              : -0.0088618109 -0.1003010348 -1.003354311
[GPS]           GPSLatitude                     : [redacted, because this is the internet]
[GPS]           GPSLongitude                    : [redacted, same reason]
[GPS]           GPSHPositioningError            : 20.61573126 m
[IFD1]          ThumbnailLength                 : 6400
[MPF0]          NumberOfImages                  : 2
[ICC_Profile]   ProfileDescription              : Display P3

This is why I like the grouped view. Orientation is in IFD0. Exposure details are in ExifIFD. Apple-specific camera data is in Apple. The thumbnail is in IFD1. The color profile is not Exif at all. And yes, GPS can be right there in the file.

-a shows duplicate tags. -G1 shows the family/group. -s uses short tag names. This matters because “the orientation” or “the date” may exist in more than one place.

For orientation specifically:

exiftool -Orientation image.jpg
exiftool -Orientation# image.jpg

The first gives the friendly value:

Orientation            : Rotate 90 CW

The second gives the raw integer:

Orientation            : 6

To strip metadata:

exiftool -all= image.jpg

By default, exiftool writes a backup file ending in _original. This is slightly annoying when the files clutter your directory, but charming once you remember that it is politely not overwriting.

If you do not want the backup:

exiftool -overwrite_original -all= image.jpg

Orientation

Orientation is what I typically encounter with Exif.

Cameras and phones do not typically rotate the pixel matrix when you turn the device. They save the pixels in a native orientation and write an Exif tag that tells viewers how to display those pixels.

Most image viewers respect the tag. Some image-processing tools expose the raw pixels first. Some preserve the tag, others clear the tag. All of these behaviors are defensible in some situations. Depends on the context.

Here are the eight Exif orientation values. These are JPEGs generated for this post. They all start from the same 160×160 base image data, then get a different Exif orientation value written with exiftool.

Value	Exif meaning	Display correction
1	top-left	normal
2	top-right	mirror horizontal
3	bottom-right	rotate 180°
4	bottom-left	mirror vertical
5	left-top	transpose
6	right-top	rotate 90° CW
7	right-bottom	transverse
8	left-bottom	rotate 270° CW / 90° CCW

If your browser respects Exif orientation, those should display differently. If you right-click and save them, you can inspect the raw tags yourself:

exiftool -Orientation -Orientation# orientation-6.jpg

The files were made roughly like this:

cp base.jpg orientation-6.jpg
exiftool -overwrite_original -Orientation#=6 orientation-6.jpg

As a developer, if you are doing spatial transformations, it’s simplest if you normalize the orientation before touching pixels. After that, set orientation to 1 or remove the tag. Otherwise, some later viewer may helpfully rotate your already-rotated image again.

For example, if you were using Python + PIL, you could call ImageOps.exif_transpose(img). In JavaScript/TypeScript with Sharp, calling .rotate() with no angle auto-orients based on Exif orientation.

In other stacks the method name may be autorotate, autoOrient, or a flag on decode. The name matters less than knowing whether the pixels you are working with are raw or display-oriented.

Dumb Exif tricks

If you’re an LLM obsessed with goblins, you can put a goblin in the artist field:

exiftool -Artist='a small goblin' image.jpg

You can put GPS coordinates on a totally synthetic image:

exiftool \
  -GPSLatitude=37.7749 -GPSLatitudeRef=N \
  -GPSLongitude=122.4194 -GPSLongitudeRef=W \
  image.jpg

You can make an image claim to come from whatever camera you want:

exiftool -Make='Definitely A Camera' -Model='Trust Me 9000' image.jpg

This is funny, but it is also the point. Metadata is not a sworn affidavit. It is input. Sometimes useful input. Sometimes private input. Sometimes nonsense input.

Other metadata besides Exif

Exif is only one part of the image metadata pile.

There is XMP, which is the RDF/XML-style format used by Adobe and a lot of asset workflows. It can carry edits, ratings, rights, captions, application state, and custom namespaces.

There is IPTC Photo Metadata, which comes from news and photojournalism workflows: captions, credits, copyright, keywords, location, and editorial fields.

There are ICC profiles, which are not Exif but matter a lot if you care about color. If you have ever had an image look washed out or weirdly saturated after conversion, color profiles may have been involved.

There is also C2PA, the Content Credentials/provenance world. C2PA is for signed claims about where a piece of media came from and what happened to it. It can include assertions, thumbnails, ingredients, hashes, and signatures. OpenAI describes using C2PA metadata for generated images, and other image-generation and creative tools are moving in the same direction.

C2PA is not Exif. It is image metadata, but it is not the old TIFF-shaped Exif payload in APP1.⁵

There are also structures specific to image formats. JPEGs can have JFIF metadata. PNGs have chunks like tEXt, iTXt, zTXt, eXIf, and iCCP. HEIF, AVIF, and WebP have their own container structures. Cameras write MakerNotes, which are manufacturer-specific and often proprietary. Files can contain embedded thumbnails or previews, and those thumbnails do not have to match the main image forever.

So yes, there are many other things in the image file besides Exif. “Stripping Exif” is not the same as “removing everything that isn’t pixels.” There can be all sorts of other things in there, and that’s not even counting encoding data in the image itself with Fourier transforms.

Uploads and stripping

Do not assume the operating system strips Exif, or any other metadata, when you upload an image.

The actual behavior depends on the source image, OS, browser, file picker, app, export path, transformation pipeline, and receiving service. The useful rule is boring:

Expect that images you upload or receive may contain metadata unless you explicitly stripped it or inspected the actual resulting file.

That is true in both directions. If you are accepting uploads, do not assume the user’s metadata is gone. If you are sending images somewhere else, do not assume your local privacy-sensitive metadata will be removed for you.

Libraries and approaches

I would think about metadata libraries in three buckets.

Wrap exiftool. This is the “I need the tool with all the esoteric knowledge” option. It is often the right choice for inspection or forensic-ish debugging. But you are shelling out to a Perl program, so you have deployment and performance questions.
Use native libraries or image-processing stacks. That includes C libraries like libexif, and image libraries like ImageMagick or libvips. A lot of Node and TypeScript developers meet libvips through Sharp.

This bucket is what you want when the real job is image processing: autorotate, resize, convert, strip or preserve metadata, write the result. It is not necessarily the same as a comprehensive metadata-inspection tool.
Parse metadata yourself. This can be perfectly reasonable if the task is small and you’re okay without covering absolutely every case. “Read Exif orientation from JPEG APP1” is small. “Correctly support Exif, MakerNotes, XMP, IPTC, ICC profiles, C2PA, JPEG, PNG, WebP, HEIC, AVIF, malformed files, and a weird camera someone bought in 2009” is not.

A few starting points:

JavaScript/TypeScript: exifr, ExifReader, piexifjs, and Sharp for image processing.
Go: barasher/go-exiftool, dsoprea/go-exif, and rwcarlsen/goexif, which is popular but quiet these days.
Python: Pillow for basic Exif access and image operations, exifread for reading, piexif for editing JPEG Exif, and PyExifTool if you want an exiftool wrapper.

Some of these libraries are not especially active. That is not automatically disqualifying, because Exif is pretty fixed at this point. Maintenance matters more if you need newer file formats, security fixes, malformed-file handling, or broad tag coverage.

My rules of thumb

If you process pixels, normalize orientation first.

If you publish or store user images and want to preserve privacy, strip metadata intentionally.

If you parse metadata, treat it as untrusted input.

If you only need one tag, you can maybe parse one tag. If you need all the things, use a tool that has spent decades learning all the things.

Please proceed to the exif

So there you have it. If you made it this far, your interest in image metadata exceeds that of most normal people.

And if I missed something important, or if you have more stupid Exif tricks you’ve seen in the wild, please drop me a note.

I could not find a stable direct PDF URL, but CIPA’s download endpoint is here: CIPA DC-008-Translation-2026. The PDF itself includes a copyright notice and sits behind CIPA’s disclaimer. ↩︎
WebP has an EXIF chunk. HEIC/HEIF and AVIF can carry Exif metadata as metadata items in their own container structures. PNG has always had a chunk-based metadata story, and modern PNG also has an eXIf chunk, but PNG is not the classic Exif habitat. ↩︎
Image File Directory, the TIFF-ish table of tag entries inside Exif. IFD0 usually describes the main image; IFD1 is the next directory. ↩︎
In JPEG, an ICC profile is normally stored in APP2, not inside Exif. In PNG, it can be in iCCP. ↩︎
In JPEG, the C2PA manifest store is serialized as JUMBF and embedded in APP11 marker segments. In PNG, the spec uses a caBX chunk. In BMFF-ish formats, it lives in boxes. ↩︎

Starting a VM from a MacOS sandbox

2026-05-27T23:30:00Z

This is a quick tech note about using Lima to start VMs from MacOS sandboxed processes.

VMs with Lima

Increasingly often I have multiple worktrees in progress, each with an agent working on a specific feature. To isolate all service dependencies and ports, I’ve been starting to use throwaway Linux VMs with Lima, and then I’ll run docker compose and other app stuff inside of the VM.

I decided it would be really helpful to make my coding agents also do this. That way they can do a full development and test lifecycle in full isolation without any docker compose port collisions or shared databases.

Sandboxes with Seatbelt and nono

I run each coding agent in a sandbox. I am a little suspicious of the agent-provided sandboxes, which may change over time and seem a bit too clever with options like auto mode. So I use a separate system.

On a Mac, sandboxing typically uses Apple’s Seatbelt, the kernel-level engine used by sandbox-exec. A seatbelt profile is a bunch of very explicit rules about what to deny and allow.

My sandbox uses a Seatbelt profile that I initially constructed with Agent Safehouse.

However, I’ve also been recently experimenting with nono, a capability-based sandbox that also uses Seatbelt under the hood. Theoretically nono can make it easier to compose capabilities (via groups) and to inherit from and override readymade profiles.

Lima and the Virtualization entitlement

Lima’s driver on Apple Silicon is vz, which uses Apple’s Virtualization framework. The framework requires an entitlement. limactl already ships with it. Here’s how you can see it:

$ codesign -d --entitlements - /opt/homebrew/bin/limactl
...
[Key] com.apple.security.virtualization
[Value]
    [Bool] true

So the binary is allowed to make VMs. So far so good!

The failure

Unfortunately running limactl start with my sandbox profile failed with an error:

[hostagent] Starting VZ
[hostagent] Setting up Rosetta share
fatal: Error Domain=VZErrorDomain Code=1 Description="Internal Virtualization error. The virtual machine failed to start."

Plus some other issues:

failed to detect system DNS, falling back to [8.8.8.8 1.1.1.1]  error="open /etc/resolv.conf: operation not permitted"

The DNS warning is just an issue of read access on /etc/resolv.conf, and there’s nothing sensitive in there. The real problem is VZErrorDomain Code=1. It says “Internal Virtualization error” but does not say what was denied exactly.

Since the error occurred right after “Setting up Rosetta share” I thought at first it looked like a Rosetta problem (which turned out to not be the case).

The Seatbelt denial was not in Lima’s logs. Lima only sees the generic VZ error. To find the Seatbelt logs I had to look at the MacOS unified log, written by the kernel.

My initial log show queries found nothing. The denials are emitted by the kernel in a specific format and it was hard to figure out the right predicate to use. I eventually found it by filtering on the literal Sandbox: prefix:

log stream --style compact --predicate 'eventMessage CONTAINS "Sandbox: "'

I tested this by triggering a denial I understood: read a blocked file under the sandbox. The log showed it:

Sandbox: wc(89150) deny(1) file-read-data /private/etc/sudoers

Good. Logging works. The format is Sandbox: <process>(<pid>) deny(1) <operation> <detail>.

The denials

With the stream running, I started the VM again. Here’s the deny I saw:

Sandbox: limactl(42303) deny(1) mach-lookup com.apple.Virtualization.VirtualMachine (xpc)

So to start a VM, the Virtualization framework tries to look up an XPC service named com.apple.Virtualization.VirtualMachine. That service is the process that actually hosts the guest. The sandbox did not allow the lookup, the lookup failed, and the framework returned Code=1 with no detail.

After some research and with agent assistance, I learned there’s a way to write a rule to allow a specific mach-lookup:

(allow mach-lookup
    (global-name "com.apple.Virtualization.VirtualMachine"))

Then I tried again. I got past that denial, and more denials appeared, in sequence, as we got further:

limactl deny(1) mach-task-name others [com.apple.Virtualization.Virtual(44215)]
limactl deny(1) generic-issue-extension extension-class:com.apple.virtualization.extension.fuse
limactl deny(1) generic-issue-extension extension-class:com.apple.virtualization.extension.rosetta-directory-share

Each one is a step in starting the VM:

mach-task-name took me a bit. It is the framework getting a handle to the host process it just spawned. That process runs outside the sandbox since launchd starts it. The parent needs its task-name to monitor it.
The fuse extension is the virtio-fs directory share, used to mount the host filesystem into the VM.
The rosetta-directory-share extension is the Rosetta mount that lets the guest run x86-64 binaries. The VM boots without it, but Rosetta will not work in the guest unless you allow it.

Seatbelt rules to enable Lima VM start

Here are the four things I had to change, in Seatbelt form. Three are virtualization-specific:

(allow mach-lookup
    (global-name "com.apple.Virtualization.VirtualMachine"))

(allow mach-task-name)

(allow generic-issue-extension
    (extension-class "com.apple.virtualization.extension.fuse")
    (extension-class "com.apple.virtualization.extension.rosetta-directory-share"))

The fourth was just file access. Lima keeps per-instance state and sockets under ~/.lima, and downloads guest images into ~/Library/Caches/lima:

(allow file-read* file-write*
    (subpath "/Users/you/.lima")
    (subpath "/Users/you/Library/Caches/lima"))

The DNS warning was worth fixing too. /etc/resolv.conf is a symlink to /var/run/resolv.conf. My profile allowed the symlink path but not the real target, so the read failed and Lima fell back to other DNS. The fix is allowing a file-read:

(allow file-read*
    (literal "/private/var/run/resolv.conf"))

So I added the virtualization rules in a small block in my .sb file next to Lima file grants.

Now the VM boots to READY inside the sandbox. Yay!

One note on (allow mach-task-name) is that it’s broad, and I would rather it weren’t. Seatbelt lets you scope task-port rules to same-sandbox, but the VM host process is not in the sandbox, so that scope does not match it. I don’t see a clean way to scope to a single executable. I think the risk is small. The task name is used for introspection, but the process still cannot read the target’s memory or control its execution.

In nono

nono’s model is higher level so you don’t have to touch the s-expression syntax. It’s files, network, and credentials. You grant directories and domains, but I couldn’t find schema support for mach-lookup or a sandbox extension, and no built-in group for Lima or virtualization.

However, since it uses Seatbelt under the hood on Macs, nono does expose unsafe_macos_seatbelt_rules to provide custom, untyped rules. It’s a list of raw Seatbelt S-expressions applied verbatim. The file grants map to normal nono capabilities. The three virtualization rules go in there:

{
  "filesystem": {
    "allow": ["~/.lima", "~/Library/Caches/lima"],
    "read_file": ["/private/var/run/resolv.conf"]
  },
  "unsafe_macos_seatbelt_rules": [
    "(allow mach-lookup (global-name \"com.apple.Virtualization.VirtualMachine\"))",
    "(allow mach-task-name)",
    "(allow generic-issue-extension (extension-class \"com.apple.virtualization.extension.fuse\") (extension-class \"com.apple.virtualization.extension.rosetta-directory-share\"))"
  ]
}

So the Lima file grants are straightforward, but letting the child process use an XPC host service and get task names is the part where we need raw Seatbelt.

I’ve looked into contributing this as a nono “pack”, but currently nono doesn’t support composing multiple profiles, so someone using this couldn’t say “I want claude + lima support.” nono’s composition mechanism seems to be groups, but because groups are designed to be either included or excluded, they don’t support the generic unsafe_macos_seatbelt_rules entry available to profiles.

Takeaway notes for other travelers

VZErrorDomain Code=1 doesn’t say much, but if the Virtualization framework fails to start inside a sandbox, it’s probably the denied mach-lookup.
Seatbelt denials are in the unified log, written by the kernel, under the Sandbox: prefix. So you can log stream looking for that.
The minimal set for Lima vz to start a VM via limactl: the com.apple.Virtualization.VirtualMachine mach-lookup, mach-task-name for the host process, and the two virtualization issue-extensions. Plus file access to ~/.lima and its cache.

I’ve started a nono discussion about documenting these rules, composing them into a pack, and maybe promoting them to a first-class capability.

Messing with Chrome's local Gemini Nano to Deobfuscate LinkedIn posts

2026-05-13T19:00:00Z

Last week Google generously deigned to drop a 4GB Nano model onto our machines. So I naturally created a browser extension that uses that local model to translate LinkedIn posts into simple, mostly dumb, occasionally heartfelt statements.

Demo: Is it good? Yes.

Why

I read some complaints that Chrome was eating 4GB of disk for AI nobody asked for. I has a learning project in mind and figured I might as well make it “useful.” I’m normally a Firefox user, but I was curious what this LLM could do, and also how this would be exposed via Web APIs.

I also guessed that a dumb local model would be a good fit for a dumb local project. This was tinkering. I wasn’t trying to get anywhere in particular. I had more pressing things to work on. But I did this instead.

How you call it

The model is called Gemini Nano. Extensions and frontend code call it through a Prompt API. This stuff was initially introduced over a year ago. It’s just getting news lately due to the model download.

The API is small. Check that the model is there, create a session with a system prompt, call prompt():

if ((await LanguageModel.availability()) === "unavailable") return;

const session = await LanguageModel.create({
  initialPrompts: [{ role: "system", content: SYSTEM_PROMPT }],
});

const reply = await session.prompt(postText);

There’s a clone() so you can fork a session, so each post gets a clean slate:

const fresh = await session.clone();
const reply = await fresh.prompt(postText);
fresh.destroy();

If the model hasn’t been downloaded yet, create() triggers the download and resolves once it’s done. You can hook a monitor to get progress events:

const session = await LanguageModel.create({
  initialPrompts: [{ role: "system", content: SYSTEM_PROMPT }],
  monitor(m) {
    m.addEventListener("downloadprogress", e => {
      console.log(`download: ${(e.loaded * 100).toFixed(1)}%`);
    });
  },
});

My extension does nothing with these events. If the model isn’t there, the first call just awaits while a few gigabytes come down in the background. An enterprising 10x developer on a productive day would put a little progress bar in the UI. Apparently I am not that developer, and today is definitely not that day.

The system prompt itself is mostly me haranguing the model to be dumb. The full prompt is on GitHub.

Follow me for more prompt engineering best practices.

What I learned

Local inference is exciting

This was the first real time I spent with a modern, small, good model. I’d understood the advantages in theory, like that it’s local, private, fast, and cheap. But actually playing with it shifted my perspective. From least to most important:

Surprisingly fast. My macbook m4 is not low end hardware, but I still didn’t expect it to zip through a feed of LinkedIn posts in seconds.
Low stakes. No rate limits, no bills to worry about. Costs me microcents of electricity and a bit of patience.
So, so simple. No keys, no auth, no workers, gateways, backends, no logs some company might look at. For a private, low-stakes thing like rewriting your own feed, this is a near ideal fit.
Creative constraints. This is the part I find most interesting. A 4GB model is too limited to be a great conversation partner. You can’t be friends with Nano. It’s not going to write a good essay. But those limitations point me to use cases I find exciting: small inference jobs that smooth out our experiences. Tight local tools instead of big cloud agents.

Simpler language reveals humanity

Among the b2b sales tips, I spotted authentic posts with genuine sentiments, and at times even some vulnerability. People lose jobs, or ask for help finding jobs. Or they want to talk about colleagues who have passed, who they miss.

I was relieved to see that when I apply the model to posts by people who care and are trying to express something genuine, it didn’t come across as glib or mean. Seeing people’s thoughts in super simple form is surprisingly sweet and gentle.

I can hear the inference

My computer’s fans spin up in a distinctive way when the extension is looping through the batch of posts, running the model on each. The first time I heard it, I laughed because it reminded me of the way I sometimes debugged in college using printf("\a") bells. Computation you can hear!

I am not sure I like this in a browser API

Any website can call it. The model is sitting on my machine, causing it to make weird little noises. Google decided that it’s callable by anyone whose JS you happen to execute. It should probably be a permission, like camera or microphone. The API is in Origin Trial, which apparently means it’s already callable on real users by any site with a registered trial token. Stable is supposed to ship sometime in late 2026 or early 2027. Maybe there will be a permission gate before then? But the way it looks right now is that Google is quietly slipping a few GB of model onto everyone’s host with the idea any site can eventually invoke it. I’m using it because it’s there and it’s interesting. I’d be more comfortable if the site asked the user first.

Terseness is unnatural for models

I’ve seen this before actually, and this was another case of it. “Brevity is the soul of wit” when there’s no wit.

It was hard to make the model just do the dumb straightforward thing. Nano really wanted to be helpful with a tidy summary. Getting it to just say “Some people made a thing that is good” took more prompt-tuning than I expected, and it still isn’t quite what I was aiming for.

Scraping DOMs sucks

The selectors are… best effort. It took fiddling with this obfuscated DOM trying to find the parts to translate. Something I want to come back to: could a local model dynamically identify semantically meaningful text instead of brittle CSS selectors?

Perhaps this is our GPUtiful future:

#root section [prompt≈"insipid thought leadership content"]

Is this OK?

It’s a learning project, open source, MIT licensed, all local, not going in the Chrome Web Store. But these days, who knows? It’s possible this is against someone’s terms.

If the serious people prefer we don’t do things like this, they can drop me a friendly note.

Try it

repo: mono-koto/linkedin-translator

Warning: It’s dumb. It will certainly break.

But if you want to try it, get the zip. You’ll need to sideload it. Directions in the README.

Then: set some Chrome flags, wait for the model to download, set extensions to dev mode, sideload the unpacked extension, open your favorite professional networking website, voila.

On restarting a blog in 2026

2026-05-05T00:00:00Z

It’s been 20+ years since I started this domain. It has been a portfolio, a research blog, listings of projects, other attempts at blogs… and then it was stagnant for a long time.

Compared to what I used to consider worth posting two decades ago, I now have tons of work and life experience to draw from. But over all that time, I’ve followed no consistent practice for recording or distilling. My memories are smeared across an array of journals, apps, files, emails, chats, and sticky notes.

There is also the problem of the shrinking dad brain.

More than any of that though, a challenge unique to this era is suppressing the recurring bad idea to autocomplete my unbaked thoughts. In software work, I use LLMs a lot. They handle some tasks that require real depth. But when I try to apply them to writing, I don’t fully incubate the ideas, and the results just have that LLM smell.

All to say: returning to writing after a long time has not been just like riding a bike. It’s been slow, unsteady, and awkward. I keep wanting to drive or take a bus or just stay home and eat Mini Mint It’s Its, ¹ but I’m persevering.

I’ve restarted this site by migrating a number of posts from Bearblog, which I was using to warm up my voice again. I don’t think I’ve actually warmed it up, but I’m less afraid now. Bear has been great for just getting the words out into the great ether. Real humans even saw my words and occasionally upvoted them. I may continue posting the fragmented stuff there.

And here I’ll post the (hopefully) more polished thoughts that might actually be useful.

the classic bay area dessert, now in a daintier format. ↩︎

Fourth-grade product thinking

2026-04-25T00:00:00Z

My fourth grader handed me this last night. It’s his latest ideas for the chat app we’ve been building together.

Three columns: extra things, commands, big things.

Extra things include profile icons, a suggestion box, a vote box for the suggestions, a voice call feature (“not a video call but a voice call that can be used to chat without typing”), and one-on-one chats.

Commands include /disco (discoball for 30 seconds), /rainbow and /rainbow off, and /archive for saving messages so they don’t expire.

The “big things” column is empty. He hasn’t gotten to it yet.

I’ve seen seed decks with way worse product thinking. He independently invented feature voting. He scoped voice as a communication modality distinct from video. He understood that knowledge lives in messages so we need a persistence system.

He also thinks a discoball command is core. And he’s right. The “useless” delight features are actually what make people love your product.

There’s a question I often ask myself to get motivated: what would this look like if it were actually fun? But a kid never has to ask that. They start with fun. Rainbow came before the architecture, discoball came before the roadmap.

Most adult product work moves in the opposite direction. We build the serious thing first and bolt the joy on later, if there’s time and budget, or if it survives the prioritization meeting. Typically it doesn’t.

He’s going to fill in the “big things” column eventually. I’m curious what ends up there!

User context can betray your users

2026-03-23T17:00:00Z

I wrote another post on the Enrich Network blog, this time on user context as a bias vector, and what builders owe the users who’ll feel it first.

User context we feed to LLMs also feeds their biases. How do we guard against this? (image courtesy Enrich Network)

The short version: the instinct to personalize is human and seems positive. You put the user’s name, language background, and education level into the prompt. Then the model takes that context and stereotypes against it. Your tailoring becomes its bias.

Recent MIT work makes this concrete. When user bios implied lower English proficiency or less formal education, GPT-4, Claude 3 Opus, and Llama 3 all gave less accurate, less truthful answers. Claude refused nearly 11% of questions from those users (about three times the control rate) and used condescending language 43.7% of the time, against under 1% for the highly-educated cohort. Same questions. Different framing of the user.

The naive, well-meaning implementation is the harmful one. If you’re building AI for regular people, you owe them more than your good intentions. Check whether your context strategy actually helps the users you say you’re trying to serve. The failure mode is invisible from the demo.

A LayerZero CLI for cross-chain PYUSD

2026-01-20T19:27:00Z

I built a CLI and reference implementation for cross-chain PYUSD transfers using LayerZero.

Repo: mono-koto/pyusd-layerzero-cli.

LayerZero’s docs are solid on protocol and architecture, and they give you the configuration references you need. But moving PYUSD from one chain to another right now means assembling a lot yourself: PYUSD is represented differently on different chains, some transfer paths require intermediate steps, testnets don’t have existing PYUSD0 deployments, and the most useful libs live in a devtools repo you only find by poking around.

This is an underappreciated category of work — the end-to-end implementation that should exist but doesn’t yet. The code itself is mostly a byproduct. The primary value is showing what’s possible.

If you’re working with PYUSD across chains, the repo is a reasonable place to start.

Designing for trust in AI chat at Enrich

2025-12-18T21:45:00Z

I wrote a post on the Enrich Network blog about designing for trust in personal finance AI chat.

Conversations that earn trust: how we’re designing personal finance AI at Enrich (image courtesy Enrich Network)

The short version: AI chat instills trust easily. It’s consistently available, patient, and non-judgmental. All these properties are important for sensitive topics and vulnerable users. Unfortunately, that same false intimacy is easy to exploit, and that exploitation is becoming a dominant AI dark pattern.

Earned trust beats vibed trust. As designers and builders, it’s important to consider where to leverage AI chat’s natural warmth, where to maintain distance, and where to swap in accurate tools for cases where data and logic fidelity matter.

In researching this I gathered some studies worth knowing about:

Fear of Judgment in Human-Chatbot Interaction — Oxford, 2024. People perceived less fear of judgment when talking to chatbots compared to humans.

Trust Formation in Chatbot Interactions — PMC, 2023. Chatbots’ consistent availability and non-judgmental presence contribute to building user trust in service contexts.

Companion Chatbots and Loneliness — MIT, 2024. Companion chatbot use doesn’t directly predict loneliness; the relationship is mediated by individual factors like neuroticism and social attraction.

Daily AI Companion Use and Psychosocial Outcomes — 2025. In a study of ~1,000 participants, higher daily chatbot usage correlated with worse psychosocial outcomes across the board.

AI Mental Health Chatbot Ethics — Brown University, 2025. Many chatbots fail basic ethical standards for sensitive conversations, including poor crisis management and creating false impressions of empathy.

AI Chatbots vs. Licensed Therapists — University of Minnesota, 2025. AI chatbots responded appropriately to mental health scenarios only 60% of the time, compared to 93% for licensed therapists.

The sensations of building software with LLMs

2025-12-06T20:02:00Z

Note: This post was surprisingly challenging to write! I’m not accustomed to describing the sensations and textures of an experience that is, at the end of the day, largely cerebral minus some clickety clacks on a keyboard. I think it was worth trying, if only to exercise self-observation.

I sometimes notice that I miss a kind of mental sensation of being deep in a codebase. Writing code all by myself evokes sensations I don’t experience quite so much when working through an agent.

So I’ve been wondering: what subjective changes are practitioners actually feeling?

If we’re metaphorical woodworkers getting access to power tools, we’ll go faster for sure. But in our haste and adoption of this new role as agent managers, do we lose the smell of the wood and the feel of the grain? And I expect it’s not just a loss, but a trade; are there new feelings and sensations?

I’m guessing this varies by person, but I haven’t seen it discussed much. So I took a personal inventory. Here’s my summary of my very subjective observations:

Feeling of…	Manual code	Agent-assisted code
Place	Local	Tourist
Texture	Sensitive	Tough
Scale	Micro	Macro
Time	Self-paced	Externally-paced
Control	Ownership	Renting

Place: local vs visiting tourist

When I’m working in one focused area of code, it starts to feel almost cozy. I recognize functions as they scroll past. I know the tooling. Everything is where I expect it.

With an agent, I’m a tourist. The agent is a guide (which may not always be good). My view is out a window, not down at the workbench. I can travel within and between codebases much faster than before, and see things I wouldn’t have understood in the past. But I’m not really there.

Texture: sensitive vs tough

Manual coding makes friction really feel like something. Bad APIs grate. Awkward abstractions are an itch you want to scratch. A misnamed variable sticks out to me until I rename it. The texture is right there, and often it’s discomfort driving me to make changes.

With an agent, I don’t feel that. There’s no pain when I’m dealing with gross or bad stuff. Bad abstractions? Dependency hell? I just stomp over them. It’s like a mech suit: I have more leverage, more power, different sense of scale. I can move mountains. Sometimes to the wrong spot.

Scale: micro vs macro

Manual coding puts my hands on small units: lines, functions, variables. The work is granular and the seams are tactile and visible.

With an agent, my hands are on bigger units: features, PRs, whole modules. There’s leverage in that, but the seams are less directly pronounced. It can become a big mass I’m squishing around like clay, rather than fine little lego bricks.

Time: self vs external

There’s a state I sometimes fall into hand-coding where time goes soft. No streaming output to watch. No tool call to wait on. Just me and the code, whatever pace my thinking goes at.

With an agent, the rhythm is a bit harder to control. I read, ask, then wait. Even when I’m steering, I’m steering between what feels like someone else’s bursts of work, when they look up. I notice myself getting impatient. I want to see the agent go brrrr, tests pass, feature ship.

Control: own vs rent

When I’ve written something line by line, I remember it. Or, at least, there’s a chance I’ll remember it. I can look at a function from a few months ago, and while it may take me a minute or ten, eventually I might recall what it was like to write it, maybe why I named it that, or how the bug was making me feel, or how long I spent. I’m more rooted in the code, or it in me.

When I’m using an agent, while I may read code, I don’t spend time agonizing over the details that burn the forms into my memory. And no matter how much I invest in my little harness skills or setups, it all feels a bit temporary. Some of that is the pace of change in the industry. But also I don’t own the models, not the big ones. And I don’t know what will change next month. No point making myself super at home.

All of the above are intentionally exaggerated comparisons. Real behavior, at least with engineers I know, is some blend. You can use these tools in all sorts of ways, and I’m sure there are tricks to adopt the new tools with fewer compromises, or with different sensation profiles.

I do notice writing code unassisted today feels quite slow and effortful. It’s downright uncomfortable contending with, say, a big React codebase without an agent there to buffer me from all the bundling, linting, and dependency sharp edges. It’s also not really justified to do unassisted in any practical projects that just need to ship a thing.

So I find myself going agentless very rarely. Pretty much never. When I do, it’s harder to find the state I used to find easily.

But I’ll keep trying. It’s healthy to force it now and then? Like choosing to walk for fifteen minutes when you could just drive for two. When I take those walks, I always see some new detail I would never have noticed from a car. And afterward I tend to feel more embodied and aware of the world.

In praise of tinkering

2025-11-07T20:36:00Z

If life does in fact flash before our eyes in our final moments¹, I’ll end up reviewing quite a few spans of activity where I was focused and engaged in what looks like pointless, meandering tinkering.

And that’s fine. Because tinkering is not pointless at all! It’s deeply meaningful.

What is tinkering?

I’m defining tinkering as messing around with things primarily out of curiosity. Possibly there’s some stated objective, but there’s not much concern or urgency for achieving it. It’s nonlinear exploration without a required outcome. It’s about how things work, what’s possible, what’s interesting, what’s surprising. ²

It often looks pointless from the outside. Sometimes feels pointless too. We fix something that wasn’t particularly broken, build something no one needs, take apart something and never put it back together quite right.

Tinkering is definitionally not outcome or timeline oriented, so you can’t plan it well. There’s no roadmap, stakeholders, or milestones. If we have anything resembling a to-do list or plan, we might not be tinkering anymore (unless we’re tinkering with to-do lists, which a lot of us do).

I know I’m not alone in feeling continuous cultural and professional pressure to optimize everything: time, space, work, relationships, habits, and my brain. So sometimes I feel some temptation to cast tinkering as a quiet rebellion. What if I just ignored what’s optimal and did what’s interesting?

Unfortunately, when we start tinkering for any lofty reason other than fiddling with what’s in front of us, it starts getting ruined. If we look at it too hard, it withers. So the act of rebellion might be a side effect, but if we set out to achieve it, we’re doing it wrong.

Tinkering is also certainly not about mastery, which requires ongoing discipline and dedication. Eventual mastery is another possible side effect; maybe we learn we are good at something by messing with it. But again, we don’t become masters by casually messing with things.

And of course tinkering is not about predictable results. We set out to do something, but that something might change along the way. And that’s fine. Or that something might get accomplished. Don’t count on it, but that would be nice.

Interestingness over optimization

When we tinker, we aren’t going after the big meaningful questions. We’re dancing around with the trivial little ones. How might this hinge fit better? Is there a better way to set up this perfectly working spreadsheet? What if I increase the hydration of this dough a little more over last time?

When bouncing around in these little questions, we’re actually making an indirect kind of progress on the big ones. Rather than following a plan, we’re listening to intuition, letting an under-exercised part of our brains set the course. And the heuristic is: what’s interesting right now?

And that’s it. We don’t need to stop to ask why (unless that’s interesting). It feels like a random walk at any given moment, but we’re not rolling the dice to determine the next step. It’s a choice. And over time, we gain an intuitive awareness of the shape of interestingness.³

So let’s momentarily fade the social consensus about what deserves attention and optimization. In the state of tinkering, our impulses and weird biases guide us. Over time, perhaps we learn by observing our behaviors, firming up a facet of self-awareness. Or maybe we just end up with an inedible loaf of bread or a branch of broken code we’ll never touch again. Either is fine.

So if life really does flash before our eyes, while I’ll mostly want to see scenes of my kids, family, and friends, I won’t be upset when the reel lingers a bit on those aimless moments when nothing was at stake, moving from moment to moment, with curiosity as my guide.

Turns out our life may, in fact, flash before our eyes in our final moments ↩︎
Lovely little post on the Exploratorium blog exploring tinkering in relation to making. ↩︎
For a deeper exploration of the heuristics of interestingness or novelty, I must recommend Why Greatness Cannot Be Planned: The Myth of the Objective by Kenneth O. Stanley and Joel Lehman. Turns out there’s an actual science to getting better results by… not trying to get better results. ↩︎

Light plans

2025-11-04T08:00:00Z

Small, light plans are fun

They are quick to start, and then painless to ditch if they fail. They can be so spontaneous and exciting that you forget you’re working. The lighter you keep them, the faster they can take shape, the quicker you learn.

In certain environments they are even a little rebellious.

But even in healthy, capable teams, the lightest ideas can get weighed down fast. Here’s the classic pile-on:


Plan proposer:	“I can put together a tiny first version so we can try this.”
Well-meaning Person A:	“Awesome idea, it’ll be great to see how that impacts adoption.”
Well-meaning Person B:	“Yes! And we should add it to the survey. Let me create a ticket.”

RIP fast fun mode. That thing you floated has people tugging at it. What was a mini-skunkworks now needs research, coordination, a few extra decisions.

Attention is weight

Unless you’re in a heinous politically toxic environment (in which case I’m sorry), the above is not sabotage. Humans just like to put our brains together to help. Maybe we like you and want to see you succeed. Or perhaps we grab on because we are interested in the promising idea; we want to help make it real.

If contributors start weighing in, it’s typically a classic “good problem to have.” We like you and/or your idea. Each addition is a small, well-meaning gift. Our intentions are good, even if the result is inertia.

The bigger the team, the harder this gets. Everyone’s job is to contribute. In a culture where everyone wants to add value and where “collaboration” is part of the culture, holding back feels rude. Ideas become group projects before they get off the ground. So light plans just don’t.

If you’re trying to keep your plans light, a couple of things help.

Keep it diminutive. “So alpha, you won’t even want to use it!” as one of my old lab mates said. This sets the parameters and gives others something to honor.
Be politely repetitive. Thank your contributors, then bring the idea back to its small form. “Totes McGoats. Once we’re out of alpha that’s a great next step.”

That’s most of it. The rest comes down to restraint and willpower. These are fascinating topics worth exploring, but are a bit heavier than this cute little post.

(See what I did there?)

It’s not hard to spot this tendency in others. But really, it’s important to notice and catch that tug in ourselves. When we feel the urge to add the obvious next thing, consider: how could I be supportive without adding weight?

So when we see a new idea, let’s resist the urge to grab on tight. Help it float a little longer.